On Tue, May 10, 2005 at 07:49:46PM -0700, Jon A. Cruz wrote:
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.
Yep, I think that's the right course to take. I think everyone pretty much thinks its a good idea, it's just a matter of coding time.
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?
Until panels are implemented, yes it needs to end up showing a dialog. When panels are implemented, then it should either show a dialog or panel.
Note that this will need to be configurable, as some users may want to force the panes to always show up as panels, others as dialogs. Also, I can easily imagine someone wishing to have some as panels (heavily used ones), but the rest as dialogs. There's going to be a good bit of logic implemented there to store the preferences and to present the user with an intuitive interface for selecting which to do as dialogs and which to do as panels. Hopefully you've already got ideas in mind for how to do it.
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.
DialogManager is all of about 500 lines, and half of those will go away once the generalized functions are finished. This is not very much code that we're talking about, and refactoring later on will not be a very difficult task. My guess is that the work is mostly going to be renaming a few things here and there, and maybe adjusting some calling syntax.
Also, don't dismiss refactoring too readily. Consider that as a general rule, while open source projects can often be weak at documenting, design, etc. they definitely have a big strength in tweaking code. It may seem that it would take less time to create a complete, complex solution from whole cloth, but often it's better to just make something simple that solves *today's* needs, and evolve it to do more, later. For many people, coding is the *fun* part. ;-)
In fact, I had a long discussion with mental regarding refactoring last weekend, as pertains to gtkmm. I've always been a believer in refactoring, but after speaking with him I'm even moreso. Open Source is all about evolution, and works best when the code is active. While I think it was useful for me to work on the gtkmm code separately, it needs to be "in the way" to get enough developer attention / participation. It may seem like it'd be less time to code something from scratch, but as mental pointed out, sometimes when you consider the whole thing end to end, the refactoring approach can be the more efficient way to go.
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
Well, dialogs don't overlap with very much. Most dialog headers are only included by a few .cpp's. Pick a dialog header and do a grep -sr.
The same is going to be true for the dialog manager; its header is only needed in a few places, and longer term will be used in even fewer.
The area that will be complicated for panels is the sp-desktop code, but like I mentioned the other day, I decided not to gtkmmify that.
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.
I also have more than a few languages and projects under my belt. ;-)
But the fundamental issue here is pretty simple - the code just needs to be written. You're the guy that cares the most about it, so the ball's yours. Whether you want to start with the DialogManager, or clean up dialogs, or whatever is up to you. Personally, if I were you I'd start by getting the panels to dock into SPDesktop; that seems to be where the crux of the task is, the rest of this that we've discussed is just tangential to that.
Obviously, you'll need to do some hoisting to turn Inkscape::UI::Dialog::Dialog into Inkscape::UI::Dialog::Pane, and add some logic to allow it to operate in either panel or dialog mode. That is probably doable in a few evening's work.
The changes you'll need to do in DialogManager are pretty trivial, probably just requiring a few lines in verbs.cpp and an evening's work with search-and-replace.
Bryce