Bryce Harrington wrote:
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.
Actually, I did read it, and understood it fairly well.
The problem is that I'm viewing things with a slightly different skew. I'm afraid that in order to convey things best I'll probably have to just code things up, but then again that's a good thing code-wise. Being tied up with work kept me from looking at things sooner, but now I should have enough time to at least be able to anylize things better.
In any case, I offered that implementation approach just as a suggestion. Whomever implements it can do it differently if they wish.
Yes. A very key point. All you presented was very good, and quite helpful to people actually looking to implement.
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.
Well... that is a good thing to suspect and then eliminate. Yes, I am aware of that, but I do believe that it's not really a factor here. It's more a point of trying to separate the information from the presentation. Or to split the model from the view. Etc.
I think much of it can be thought of as trying to separate the abstract concepts in play from the implementation and presentation of those concepts.
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.
Oh, yes. Getting rid of that hardcoding is a good thing, and also what I was promoting (I was not pushing that other method that you mentioned).
However... in this precise case, do we really *need* to end up showing a dialog? Or can it just flash a border in the UI where that control already is visible?
In one case "showDialog()" can lead to a certain set of expectations, while "showUI()" or some such can help separate the mixed concepts.
The subtle shift in viewing things is much like the difference in coding with the assumption that a byte is a character. Far less work to code it with explicitly separated concepts to begin with than to go in later and try to split them in a refactoring. Initially things might resolve with one byte each in most cases, but the first time you start to run up against cases where a char is more than one byte, ouch.
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". ;-)
Well... could be... But then if the effort is chaning things that will have to be undone later, then it's a bit of 'wandering' effort. Minimizing the ammount of work that will just need to be undone in the immediate future is often a good thing. Leaving work for refactoring is good, but it's easy to cross the point where too much needs to be un-done instead of re-done.
Till now the Dialog stuff has been changing in areas that have been independent from other areas. Now, though, it's a good time to make sure we keep things going in good directions. We are now hitting the area of overlap. I'll try to get it all mapped out well
Also... if some things are cleaned up before dialogs are converted, then we'll end up with a lot fewer lines of code to muck about with. I know much of this seems like pedantic nit-picking, but over many years, with many languages and with many toolkits, I've gained a good feel for things that can slow overall development, and things that can speed it.