On Tue, May 10, 2005 at 12:33:13PM -0400, jon@...18... wrote:
Quoting Bryce Harrington <bryce@...260...>:
A good technique for providing this capability is to implement Factory methods (see a Design Patterns book for detail).
This probably means we will need to have each dialog include a create() function that returns a new'd Dialog* of its class, and then build a hash of GQuarks to create() function pointers. We would then also need a registration function to add new create() functions to the hash.
And this is where I think it veers a bit off course.
I'll have to get up to speed on the overal state of things, but requiring a create() function on the dialog classes might be restrictive. Instead we might want to have a collection of Factories there, and let them have a create() method. Then the DialogManager would be a Facade in front of the Factories (and maybe even multiple inheritance could be used to have create() on some dialog classes themselves).
If you re-read what I wrote, you'll notice you just restarted what I was saying. ;-) So if I've veered off course, you're right there with me. Factory methods, create() routines somewhere, and DialogManager as a front end.
In any case, I offered that implementation approach just as a suggestion. Whomever implements it can do it differently if they wish.
However... the big picture is what we might need to look at here. In this case, we're getting tripped up by tricky implementation details, but if it's for something we don't need to be doing in the first place, then we can avoid a lot of the complexity and trickiness.
I'm sorry that you're getting confused so easily. ;-)
Honestly, this is not that tricky. The mechanisms here are also general enough that you could probably reuse them fairly easily for panels.
I suspect your intolerance for dialogs is getting in your way. I think instead of jumping up and down whenever someone mentions the word 'dialog' you should try to understand what is being worked on and how it can be adapted to be used for panels.
The thing that trips my radar is the getDialog() method. Instead of jumping straight down into "how can we code this method", let's back up and say "*why* are we coding this method?" That in general, and in this case specifically, can lead to clarity and reduction of problems.
:-)
So... one question is "why do other parts of the code *need* to get a dialog?" Do they really care that much about the details of how some UI is being presented? If not, then I say we should get rid of that method altogether.
I know that the point you've been trying to make is that instead of getDialog, you want to see something that does a get-dialog-or-panel.
But consider this: The work of modifying DialogManager into a PanelManager is trivial compared with the work of implementing the logic for doing panels, coordinating whether to show a dialog or a panel, adapting the GUI framework to allow fitting panels in, etc. etc. You're trying to wag the dog by the tail. ;-)
Don't worry about the DialogManager/PanelManager stuff. That is going to be the EASY part. Get the panels themselves working, and the code for letting the user select whether to do it as a dialog or a panel, first.
And I'll assert that were we to try to alter the DialogManager design right now to fit in a panel notion, to "save time", it won't. We don't know what the panel system looks like so would only be making guesses; chances are we'd have to reimplement it anyway. Better to keep DialogManager simple now, and wait on refactoring it until we know how it will need to be changed to handle panels.
I have been thinking of your panel idea for a while, and the way we're adapting DialogManager to generalize its functions moves it in a direction that will be suitable for managing panels as well. It will take more work to complete it, but I don't think it's worth worrying about until the panels are further along.
From the dialog side of things, there is still a lot of work to do to
clean things up. There are many Gtk+ dialogs that need converted, other gtkmm dialogs that need to be brought into the manager, etc. The work to square these things up and unify implementation at the dialog level will make it easier to convert them to panels later. So I think it would be better for you to _encourage_ this work rather than rant "die die die". ;-)
Then the using code would no longer need to duplicate the functionality of asking for a given dialog and then showing it. So duplicate code would be refactored out to a common function. Additionally, in the cases where no Dialog itself were involved, the using code would neither know or care, and things would just work. And... if using dialogs or not were to be changed in any given cases, changes would be limited and kept away from the other parts of the code that were calling it.
Okay, now you're veering off course. ;-)
I don't think you understand what the goal here is. You're not incorrect that we want a common function for showing a dialog, however the real objective is to generalize.
Currently, in verbs.cpp you see switches like this:
switch (reinterpret_caststd::size_t(data)) { case SP_VERB_DIALOG_DISPLAY: sp_display_dialog (); break; case SP_VERB_DIALOG_NAMEDVIEW: sp_desktop_dialog (); break;
Your suggestion would be to simply replace sp_desktop_dialog() with something like, dlg_mgr->showDisplay().
The problem with this, though, is that it leaves the dialog identity hardcoded in verbs. What I would like to do is eliminate the switch entirely, and encapsulate it entirely within DialogManager:
dlg_mgr->showDialog(reinterpret_caststd::size_t(data));
This means that the showDialog() calss would need to translate the 'SP_VERB_DIALOG_DISPLAY' into the appropriate GQuark, use getDialog() to retrieve the corresponding dialog, and show it. It's not clear how to do the 'translate' part yet, though, so we've not bothered trying to create that common function. However, we can kind of morph the switch statement in verbs.cpp in that direction for now.
Of course, in all of the above, s/dialog/panel/i if you prefer. Exactly the same situation.
In essence, I'm not suggesting trashing the existing stuff as much as A) adding a layer of abstraction and B) shifting our focus away from presentation and onto information.
Well, feel free to patch. ;-) Myself, though, I think you need to get the panel stuff functioning before it's worth worrying about abstracting DialogManager and stuff. Adapting all of this to do panels seems pretty minor in comparison, so doesn't seem worth worrying about yet. Also, I think getting the transient and preferences stuff working is higher priority for DialogManager than implementing panel support.
Bryce