Difference between revisions of "DialogReplacement"

From Inkscape Wiki
Jump to navigation Jump to search
m (link fix)
Line 6: Line 6:




Basically, instead of subclassing Dialog, we'd subclass panel instead. We'd have a class that keeps track of the control panels, and is in charge of viewing them. When you'd want the FillAndStroke control panel, for example, the manager would check to see if an instance is around. If not, it would create the panel and then plop it in the proper container. By default that could be the dumb Dialog class that only holds things, however it could easily put it in a different part of the UI. Swatches, for example, could go in a panel in the bottom of the window instead of popping up in a dialog, etc.
Basically, instead of subclassing Dialog, we'd subclass panel instead. We'd have a class that keeps track of the control panels, and is in charge of viewing them. When you'd want the [[FillAndStroke]] control panel, for example, the manager would check to see if an instance is around. If not, it would create the panel and then plop it in the proper container. By default that could be the dumb Dialog class that only holds things, however it could easily put it in a different part of the UI. Swatches, for example, could go in a panel in the bottom of the window instead of popping up in a dialog, etc.




Panel implements the 'Dockable' interface. Anything that might hold one would implement the 'DockFillable' interface.
Panel implements the 'Dockable' interface. Anything that might hold one would implement the '[[DockFillable]]' interface.


And... instead of a dialog holding a single item, a notebook could hold several panels in different tabs.
And... instead of a dialog holding a single item, a notebook could hold several panels in different tabs.

Revision as of 02:32, 22 January 2006

Starting a bit of scratch-pad for the new way of getting away from subclassing Dialog

Here's a rough plan

upload:Panels.png


Basically, instead of subclassing Dialog, we'd subclass panel instead. We'd have a class that keeps track of the control panels, and is in charge of viewing them. When you'd want the FillAndStroke control panel, for example, the manager would check to see if an instance is around. If not, it would create the panel and then plop it in the proper container. By default that could be the dumb Dialog class that only holds things, however it could easily put it in a different part of the UI. Swatches, for example, could go in a panel in the bottom of the window instead of popping up in a dialog, etc.


Panel implements the 'Dockable' interface. Anything that might hold one would implement the 'DockFillable' interface.

And... instead of a dialog holding a single item, a notebook could hold several panels in different tabs.