You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently Pyface has non-optional dependencies on TraitsUI. After some work, these have been reduced down to:
pyface.dock - this is Wx-only, but is core to the TraitsUI View implementation for that toolkit, and is also used substantially in the Workbench implementation.
pyface.workbench - this is cross-backend, and is used by Mayavi and Envisage, but not by TraitsUI.
But these dependencies are fairly substantial (eg. things like menu handling, building complex dialogs, etc.), old, not actively developed, and seem like they would be non-trivial to resolve within the Pyface codebase alone.
Proposal:
we move pyface.dock to traitsui.wx.dock (or maybe somewhere else in TraitsUI, if we need to avoid circular imports). This makes the situation with pyface.workbench no worse, but there is no known use of pyface.dock outside of the Wx backend of Workbench and TraitsUI (and if there is, they can just adjust imports as needed, since they will already depend on TraitsUI). This change will require adjusting imports, but should otherwise be transparent.
we move pyface.workbench to apptools.workbench. This seems reasonable, since Apptools already has substantial dependencies on TraitsUI, and Workbench is precisely the sort of thing that Apptools is supposed to contain - libraries for supporting substantial GUI applications.
The text was updated successfully, but these errors were encountered:
Currently Pyface has non-optional dependencies on TraitsUI. After some work, these have been reduced down to:
pyface.dock
- this is Wx-only, but is core to the TraitsUI View implementation for that toolkit, and is also used substantially in the Workbench implementation.pyface.workbench
- this is cross-backend, and is used by Mayavi and Envisage, but not by TraitsUI.But these dependencies are fairly substantial (eg. things like menu handling, building complex dialogs, etc.), old, not actively developed, and seem like they would be non-trivial to resolve within the Pyface codebase alone.
Proposal:
pyface.dock
totraitsui.wx.dock
(or maybe somewhere else in TraitsUI, if we need to avoid circular imports). This makes the situation withpyface.workbench
no worse, but there is no known use ofpyface.dock
outside of the Wx backend of Workbench and TraitsUI (and if there is, they can just adjust imports as needed, since they will already depend on TraitsUI). This change will require adjusting imports, but should otherwise be transparent.pyface.workbench
toapptools.workbench
. This seems reasonable, since Apptools already has substantial dependencies on TraitsUI, and Workbench is precisely the sort of thing that Apptools is supposed to contain - libraries for supporting substantial GUI applications.The text was updated successfully, but these errors were encountered: