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