On Wed, 29 Dec 2004 12:30:22 -0800 (PST), Bryce Harrington <bryce@...260...> wrote:
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.
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). 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.
It provides no mechanism for adding new types of units at runtime because the units are represented as enums.
Agree, that would be nice to have
Furthermore, there is no mechanism for converting arbitrary user-defined units ('miles', 'km', etc.) into valid SVG-units.
same
There is no mechanism for selecting 'unit systems' (i.e., so widgets display only S.I. or only Imperial units).
same
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.
pjrm and me have addressed this somewhat, though of course further improvement is possible
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.
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.
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).
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.
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?
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.
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. We are a very active project, with big and small changes made all the time by lots of people, all over the codebase. In such a project, a branch which lasts longer than a few weeks is hardly survivable (unless it's a drop-in thing). That's how I see it, though I may of course be wrong.