On Sun, 2005-05-08 at 13:33 -0700, Bryce Harrington wrote:
Hi all,
Recently I've been appraising how much work it's going to take to achieve the goal we set for 0.42 to get converted to gtkmm.
The choice to switch to gtkmm was made at the very start of the project, so it's always been one of our biggest goals. Several actions we took in our earlier releases were geared towards this end. In fact, we've been planning to convert to gtkmm for several releases now.
And its a great goal...
Of course, this is not a trivial undertaking. Initially we approached doing it piecemeal, one dialog at a time. Several dialogs got converted, but we noticed that each dialog turned out surprisingly different than the others. This is where I got involved - to try to help establish some common practices for implementing dialogs. I also figured that even though I had other stuff I wanted to work on (i.e. markers and extensions), for project priorities it was probably more valuable to pitch in with getting progress on the gtkmm stuff.
Today I think the new dialog code is pretty good. There is a base class we can use for dialogs, that provides the common behaviors, and a DialogManager to better track their memory and instantiation. The individual dialogs still need to all be converted over, but we've already got a handful converted, and there's another handful that are already in gtkmm but just need to be restyled to work with the new code. So now, the rest of the dialog conversion work *can* be done piece by piece, without risking problematic inconsistencies.
Did you use my new generic map structure implementation for managing dialogs??? I would like to get that in place soon... ;)
However, converting to gtkmm means much more than just converting each dialog; the main interface (toolbars, buttons, canvas, etc.) also needs to be turned into gtkmm code. This requires conversion of SPView, SPSvgView, SPDesktop, and SPDesktopView. SPDesktop alone is a pretty big project; I've been hammering at it bit by bit for the past few months but feel like I've barely made a dent. It's pretty frustrating; I feel like I'm pulling the proverbial thread from the sweater.
Anyway, given what it looks like needs to be done, I don't really have the time/patience/energy to see the View/Desktop work through to completion by myself. There are other things I want to do for Inkscape and Open Clip Art that are higher priority to me. If someone else wants to work on it, I can share what I've learned and explain what it looks like needs to be done.
Finally, given this, I see no point in continuing with the goal of completing gtkmm for 0.42. It's just too much effort, compared with the number of people committed to working on it. I hate the idea of having to yet again bump it to the next release, though. If it couldn't be achieved for 0.39, 0.40, 0.41, and 0.42, why would we think it could be done for 0.43? I think that given the lack of activity, the most logical thing is to just postpone it indefinitely. The work just seems to get in the way of making releases, and given that people are more interested in working on misc. individual things rather than gtkmm, anyway, there's little value in setting it as a goal; it just sets up expectations that are proving unachievable. The desire for a release is clearly much higher than the desire to finish implementing gtkmm at this time.
I think that slow refactoring is key, but more importantly we decided that no more of the interface will be coded in GTK+, but gtkmm. I think if we decided this much much more will happen. Maybe it is not so realistic to force conversion from the pure top down effort, but if we set some simple rules, like WE NOW PREFER GTKMM, I think we will reach our goal quicker.
Thus, I would like to propose we scrap the remaining plans for 0.42 in the roadmap, and go ahead and start the 0.42 release process.
Opinions?
I think the sooner the better. I feel the attn. span slowing on Inkscape, which is okay, but I think better to stay in the news and to keep feeding users new features, rather than keep them with the old copy of Inkscape...our quicker releases is one of our advantages...
Jon