This is just for the gtkmm branch.

On Wed, 29 Dec 2004, bulia byak wrote:

On Wed, 29 Dec 2004 10:54:13 -0800 (PST), Bryce Harrington wrote

...

I'll also add a 'preferred units' capability so the user can flag what default unit of measurement to display. That shouldn't be too hard...

Hey, I already added this a few days ago. Did you read my announcement here? Or is your system an addition to mine? Or are you developing a different system in your gtkmm branch? If so, why duplicate the functionality?

Once again: Go to document prefs and set "document units". This sets units for ruler, statusbar, and all unit selectors. This is in CVS.

On Wed, 29 Dec 2004, bulia byak wrote:

On Wed, 29 Dec 2004 11:28:35 -0800 (PST), Bryce Harrington <bryce@...260...> wrote:

...

This is just for the gtkmm branch.

Can you then re-sync with the main branch on this?

The main codebase is C, whereas this is a C++ class. How do you propose this be done? If you can describe the specific features you want available in the new code I will get them coded into C++ for you.

This is functionality that, for the most part, does not depend on the widgets library, so it makes no sense to reimplement it separately. At

I'm rather irked that you say "it makes no sense", and would ask how you arrived at that conclusion? I spent about a month fussing with the unit-widget, unit-menu and helper/unit.* code as I attempted to port the transformation dialog, which was a challenge due to the lack of documentation. The unit code was especially difficult because it has so little documentation, but I think I understand it well enough now to say it *does* need reimplementation. It provides no mechanism for adding new types of units at runtime because the units are represented as enums. Furthermore, there is no mechanism for converting arbitrary user-defined units ('miles', 'km', etc.) into valid SVG-units. There is no mechanism for selecting 'unit systems' (i.e., so widgets display only S.I. or only Imperial units). The code is not encapsulated well, with the result that unit conversion code is peppered through the codebase instead of managed in a central location. I also am skeptical about whether the unit-base design is the right design approach.

I know that my current implementation does not solve all those needs now, and since it's still fairly new it certainly lacks functionality that is in the current system right now, but I would definitely argue that we need to reimplement this code, and that since there is so much to change that it makes sense to do it separately so it does not degrade the current codebase. So I won't accept the argument that it "makes no sense to change" without a lot of backup evidence of how the current system can be made to work, and is something we can grow to solve new needs. I do think it makes sense to change.

least you should take the namedview support for document units, desktop accessor method, and the many fixes in SPUnit and rulers that I did. It would not be nice to lose all this when we switch to gtkmm branch.

Note that because of how far-reaching an interface redesign can be, there is almost certainly going to be feature differences. I would love to be able to promise that every existing feature will be preserved, but that would be a completely unrealistic promise. I can say that a lot of the current functionality will be preserved, and that hopefully we'll have many compelling new features. However, the ONLY WAY we can ensure that features people care about are preserved, is to have people get involved and participate in porting those features over into the new codebase. (What I would hate is for us to have to continually postpone adoption of the new code over worry of one lost feature or another).

Fortunately, there is plenty of time before we have to switch over. In fact I am arguing in favor of a very gradual process - when we merge, the new gtkmm interface would be provided only as an option for experimental usage, and only when we hit a threshhold where the new interface has more capability than the old would we make the new interface the default. And even at that point I would want to keep the old C-based interface around for a while as an option for those who dislike change. My hope is that the new interface will be signficantly better, and everyone will want to switch over to it, but realistically there are going to be feature differences so a gradual conversion will be least painful for people.

I have been attempting to put the new code into subdirs and/or new names that can be 'overlayed' into the existing codebase without having to replace any files.

For those who care deeply about existing functionality being preserved, it would be extremely wise to start gaining familiarity with the new code now, so that you'll be prepared for helping with preserving those features.

Also, be aware that while the gtkmm conversion still has a long way to go, as we make progress on converting code over, there will be a risk of divergence. If you make a change to a dialog in the main codebase that has already been converted to the new, ideally it would be nice to make those same changes in the new; more realistically, please at least document those changes very well so that someone else can easily replicate them in the new.

Bryce

On Wed, 29 Dec 2004, bulia byak wrote:

My "makes no sense to reimplement" referred only to the setting of default per-document units. This is done via SPNamedview and SPDesktop, and I see no need to reimplement it (unless you're reimplementing the entire namedview thing).

Ah, gotcha. No, I hadn't even run across anything related to namedview. I don't see a mention of 'namedview' in helper/units.*, so possibly this is completely orthogonal.

The SPUnit class itself can of course be improved, though personally I don't perceive this as a priority. What seriously annoyed me was the inability to set document units, and I addressed that. Now I have other urgent needs to address, i.e. I don't plan to work on units anymore. If you are working on them, this is excellent, I only want my fixes and additions not to be lost.

Okay, great. Yes I plan to give a lot of attention to the units code. This is an area that has been a sore thumb for me for many years. I think one of my earliest feature requests to Sodipodi was to provide better units handling. I got into Sodipodi for doing maps, and wished to measure things in km or mi's. I also used Sodipodi for my backyard landscaping design, and having to measure everything in inches was a pain in the ass. I will try to make sure your fixes and additions are not lost, but you may have to doublecheck them later on to make sure.

Summarizing, all these are good features, and I'm glad you're working on them, I'm just worried by your being unaware of my recent changes in this area and wanted to point them out so that they are not lost.

Thanks. Actually, I have been working (off and on) on the units code for a couple months now, but still consider it far from done. I did notice your initial email about your work on the units code, and since I am still referring back to the units.* stuff regularly I'm sure your changes to those files won't be forgotten.

...

I know that my current implementation does not solve all those needs now, and since it's still fairly new it certainly lacks functionality that is in the current system right now, but I would definitely argue that we need to reimplement this code, and that since there is so much to change that it makes sense to do it separately so it does not degrade the current codebase.

OK, you should really just have announced, "don't touch units code because I'm working on it in the branch." I thought you were only working on dialogs and widgets. If I knew about that I would not touch it. But now that I touched it, I don't want my changes to be lost.

Well, I do not want people to stop touching code just because it's getting converted... Obviously fixes to the existing interface should continue to be made while the new one is still under development. I actually really appreciate that you fixed up the existing units code because correct code is much easier to convert than code that is buggy. The main thing I want is that people not get worried if we get a little out of sync here and there. I'm confident we can work through these issues given time.

It's correct that by and large I'm only working on the dialogs and widgets. For doing the Transformation dialog, though, I just couldn't resist the urge to experiment with redoing the units code, to see if I could come up with something better. I suspect there may be other such "one step removed" code that will get touched. For instance, there is a notable overlap between Inkscape's verbs and Gtkmm's Action system, and I think it may be possible that the latter replace large parts of the former.

Also, I should mention that in addition to the dialogs and the widgets, we are providing a Gtkmmified Inkscape::Application class. This includes the toolbars and menus. It will also include the statusbar and rulers, however those have not been touched yet. The intent is that these changes will preserve the existing look & feel and behavior, and will add some new capabilities.

I have created stubs for Desktop and Selection, however I currently only consider these placeholders; I don't know if we'll go ahead and fully convert those, or just stick with the current C-based implementations. I don't think it'd be hard to convert them, but I'm leaning toward the latter since we have to draw the line somewhere. ;-)

I understand this, and I wonder why we have this branch at all. I hate branches. Was it impossible to do this incrementally in the mainline? If so why? I would not object to losing _some_ features for _some_ periods of time if work is being actively done in the mainline. For example, as you know two of our dialogs are partly gtkmmified and miss some functionality. Why not work closely on fixing them, and when done, spread gtkmmfication on other dialogs? What I observe is that no one is working on them, and hearing that your gtkmm branch is not going to be merged any time soon, I'm naturally worried by these partly-broken dialogs.

Technically, it's not a branch, perhaps there is some confusion there. It is *only* the ui elements, so is just a shell. I.e., there is nothing in the 'canvas' area.

The reason it was done outside the branch is because this evolved from some sample code I was working with in my experimental directory. When I was finally ready to add it to the main codebase, we were in a feature freeze or something, and I've just never gotten around to putting it in.

Regarding fixing the existing dialogs, in fact you may recall that I helped with the object properties and rename layers dialogs this last release, and have helped with fixing bugs in other Gtkmm dialogs. I've found this quite useful in testing out approaches for the gtkmm codebase. In fact, I debated over Christmas about porting in the Dialog and Dialog-Manager classes from the gtkmm codebase to help address some of those other shortcomings in the Gtkmm dialogs, but I'm worried it would introduce too much instability and might not preserve all of the existing features. I still haven't gotten sp_transient 100% converted to Gtkmm yet for example.

...

Fortunately, there is plenty of time before we have to switch over. In fact I am arguing in favor of a very gradual process - when we merge, the new gtkmm interface would be provided only as an option for experimental usage, and only when we hit a threshhold where the new interface has more capability than the old would we make the new interface the default.

Must it be switched over entirely, or can we switch some aspects only as soon as they are ready?

Possibly. Some of the simpler dialogs will be ready sooner than the more complex ones like the XML or gradient editor, however converting to them may not buy us much...

I would love to see us switch over to Inkscape::Application early, since that's the piece most likely to exhibit divergence. However, that's also the piece that will be the hardest to integrate since it touches such wide areas of the codebase.

Anyway, the plan had been to merge everything in this after the 0.40 release (i.e., now), but since we decided to do an accelerated 0.41 release, that precludes a merge at this time (it would introduce instability to the codebase, and then immediately tie our hands with a feature freeze). However I definitely want it in as soon as 0.41 is out the door.

...

For those who care deeply about existing functionality being preserved, it would be extremely wise to start gaining familiarity with the new code now, so that you'll be prepared for helping with preserving those features.

OK, I'll have a look, though honestly implementing new features and bugfixing in the mainline are a higher priority for me. I'm not good at rearchitecturing existing stuff, neither does it interest me much. I appreciate when others do it, but it's just not my thing.

That's fine, and in fact I am very glad you give priority there. I just worry that the change may feel threatening for folks who do not have familiarity with it.

...

Also, be aware that while the gtkmm conversion still has a long way to go, as we make progress on converting code over, there will be a risk of divergence. If you make a change to a dialog in the main codebase that has already been converted to the new, ideally it would be nice to make those same changes in the new; more realistically, please at least document those changes very well so that someone else can easily replicate them in the new.

Ouch. That's why I hate branches. I think branches really only work for drop-in replacements, i.e. completely new code that can be enabled by a trivial change of some function calls etc. If you are actually going through all the dialogs and recoding all the existing widgets and stuff, this should be done incrementally in the mainline because otherwise the divergence will be too bad.

Yes, I know and agree. That's why I have been trying to force it into as much of a 'drop-in' as possible. For example, I have tried to confine development focus to low level architecture and to a minimum number of dialogs. I chose to focus work on the Transformation dialog because it is one that seems to change very rarely, thus hopefully minimizing the amount of conflicts that will occur. Also, it has been sufficient to help me in developing underlying architecture (Dialog and Dialog-Manager), which we'll be able to introduce to other dialogs as we go. There's still some structural work to do (such as Gtkmmifying sp_transientize) but we're at a point where work can proceed with the remaining dialogs generally, so a merge (immediately after the 0.41 release) would be a wise idea.

Bryce