On Sun, Sep 16, 2007 at 06:44:53PM -0700, Jon A. Cruz wrote:
On Sep 16, 2007, at 8:48 AM, Gustav Broberg wrote:
- Manage the Swatches dialog with the dialog manager, like any other dialog.
I think this one pulls up a key issue.
We want to get away from the concept of "Dialogs" since we really are trying not to have them.
Instead we have "panels" that might be embedded or might be floated in a dialog. That's why the swatches dialog was using that instead of hooking directly into dialog widgets. The idea is to encapsulate things so that they are container agnostic. If something is needed to function properly, it can just be added to the Panel API.
That also will get a lot of common code moved into a single Dialog-that-holds-a-Panel class, and remove a lot of redundancy.
I like that plan, let's go ahead with it.
So basically, the current "dialogs" will subclass Panel instead. All code in the "dialogs", now panels, that assumes a Gtk::Dialog like base class will be rewritten (or Panel will be extended to satisfy their needs when it makes sense).
The Dialog-that-holds-a-Panel class would replace the current Dialog class, i.e. be just like Dialog but get its content by adding a Panel (?). The DialogManager would handle the new Dialogs in the same way as it handles the current ones. This design would also allow Dialog to be rewritten as template class with its behavior as argument, as opposed to the current clunky one-behavior-instance-per-dialog solution (which also gives lots of duplicated API:s).
My only concern is the possibility of squeezing this in before the upcoming release, I think my current to do list will take pretty much all of my available time :/
-- Gustav