Difference between revisions of "DialogReplacement"
m |
|||
| Line 3: | Line 3: | ||
Here's a rough plan | Here's a rough plan | ||
upload:Panels.png | <center>upload:Panels.png</center> | ||
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. | |||
Revision as of 04:27, 7 April 2005
Starting a bit of scratch-pad for the new way of getting away from subclassing Dialog
Here's a rough plan
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.