I'd like to see the Gtkmm work moved into the main branch. Just get it in there as the separate program it is. The classes and GUI elements can be tacked in as you go. For example, we already have co-existing dialogs, etc. The major changes will still be major, but at least the surrounding code work will already be done for it.

I'll be honest here and say there's a lot I still don't know about the legacy code. But from what I've seen so far, and especially from my work in helping to flesh out the Gtkmm stuff, a number of the required changes/cleanups will run pretty deep. And unless Bryce has some particularly powerful magic up his sleeve, I don't see how we'll be able to have both codebases in a single tree. (I could very well be wrong, and would love to be shown otherwise.)

If we try to put them both in a single tree, many files will be duplicated as work progresses, so we'll have an effect similar to working on separate trees. Because many files will have to be dramatically edited (in most cases, removing a lot of cruft along with a fair bit of reorganizing), we'll end up with two different copies of the same (or similar) files. And if you want to fix a bug or add a feature in one, you'll have to check both. Very similar to working with two separate trees.

I was trying to describe something more along the lines of a "mostly stable" tree and a "definitely devel" tree. On a low level, their code will be identical, so as low level things get copied from "mostly stable" into the "definitely devel" branch, patches from the lower levels of stable should cleanly apply to devel. However, things that are just below the surface of the new UI will require radical changes as they're fitted to the new UI and modern GTK+ 2.4/2.6 ways of doing things. So either way we go, we'll have, as I see it, the same amount of duplicity to wrangle with.

You brought up the issue of the dialogs in the Gtkmm code. That actually helps to illustrate my point. There's almost no way to migrate the new dialogs and dialog manager down into the legacy codebase. We could certainly put that work in some subdirectory of the main tree, and have configure/compile options to use the new stuff instead of the old. But within that single tree, we'd then have two dialogs for everything until the old dialogs were entirely ripped out and the compile options for the old stuff were removed. So developers would still have the problem of having to edit two separate dialogs in two separate locations just to uniformly add a checkbox to "Align and Distribute".

But, anyways, I'm still young and dumb and have a lot to learn. I'm probably seeing this all wrong, and I hope it ends up all fitting together much easier than I imagine it might.

Peace out,

Derek

PS: I don't mean to scare up any FUD by introducing this thread. I don't think we have to worry much about a "divergence" between the two codebases or other such concerns that have come up with regard to the Gtkmm work.

Right now we have a big problem of work being done in normal HEAD not getting picked up in the other tree.

This is entirely false. If anything, it's the other way around, work being done in Gtkmm is not getting picked up in HEAD.

As it stands, the "other tree" is only cloning the UI and implementing it much more cleanly. As for any changes going on in HEAD, those will be picked up by the "other tree" when the "other tree" either imports those things or is put on top of those things.

I promise you, there is absolutely nothing in HEAD that the Gtkmm code will be missing out on.

Well, as I noted it's already a problem...

You didn't note anything, you simply said something which was false. :)

On Mon, 2005-01-03 at 19:17 -0500, MenTaLguY wrote:

What about some of the recent units work, for example? (no, duplicated work doesn't count as being picked up)

I think we got that one sorted pretty quickly, but as more work is done it's only going to get harder.

Units work is still unfinished, and Bryce will hopefully have things pretty solid in another week or so.

Actually, what likely happened is that the Gtkmm codebase didn't "pick up" the bugs that bbyak was having to fix in SPUnits. (Gtkmm Units never relied on the 0.8 factor, etc.)

In the end, there isn't yet enough in the Gtkmm codebase to "pick everything up", or to even "pick half of something up" as people are worried about. We're still finalizing too many framework-oriented things to worry about picking stuff up from 0.40cvs. And the framework oriented stuff we're working on now doesn't really overlap with the vast majority of work being done on 0.40.

On Tue, 4 Jan 2005, bulia byak wrote:

On Tue, 04 Jan 2005 13:09:18 -0600, Derek P. Moore <derekm@...606...> wrote:

...

Actually, what likely happened is that the Gtkmm codebase didn't "pick up" the bugs that bbyak was having to fix in SPUnits. (Gtkmm Units never relied on the 0.8 factor, etc.)

Wow. What do they rely on instead? What is the px/pt ratio in your code?

Actually, it does use the 0.80 factor, but in its inverted fashion (1.25). However I chose to make px the primary unit so the conversion factors are expressed as functions of px's rather than pt's. I may not have gotten everything right yet, but it should be fairly easy to fix, because all of the unit definitions are loaded from an external file. If expressing things as px's is a bad assumption, it can be fixed by editing the .txt file.

I am trying not to have the 0.8 factor show up in the codebase itself; at least, not in the gtkmm frontend. The hope is that by collecting all the unit factors, types, names, etc. in a single location, it should make it easier to maintain and augment in the future.

Like Derek says, it's still a work in progress, so if you're curious please check out the code and take a look, and if something's wrong let us know or send in a patch.

Bryce

On Tue, 4 Jan 2005, bulia byak wrote:

On Tue, 4 Jan 2005 13:26:56 -0800 (PST), Bryce Harrington <bryce@...260...> wrote:

...

Actually, it does use the 0.80 factor, but in its inverted fashion (1.25). However I chose to make px the primary unit so the conversion factors are expressed as functions of px's rather than pt's.

This sounds good. I just did mostly the same, now there's only one 0.8 defined in one place.

Actually what I need from SPUnit is this:

sp_pixels_from_units, sp_units_from_pixels

SP_PX_TO_METRIC_STRING (currently it's in SPMetrics, but this class is redundant, it should be merged with SPUnit)

Okay, I'll make sure equivalents for those are there. This is good to know, because there's a lot of routines in there that I wonder whether they may not be needed.

Do you want to have wrapper functions by those exact names to hook to those, or do you just want a routine that provides the equivalent functionality? (I've dropped the sp prefix for this code and have been implementing routines as class members, but wrappers could probably be created if needed.)

functions to get ratios to and from px for all units (to replace the defines from unit-constants.h)

All of the linear document units are based on px as the primary unit so trivially these can be obtained via `u.factor` in the Unit structure.

For the unit widget I also added a convenience function for getting the conversion factor from whatever the user's selected to a different unit:

double getConversion(Glib::ustring const &new_unit_abbr) const;

Basically this just returns old_unit.factor / new_unit.factor but also does some checking that new_unit_abbr exists, and checks that neither factor is ~ zero. Possibly we could promote this convenience function up higher if other areas of the codebase also need to do similar conversions.

sp_get/set_value_in_pixels for an adjustment with a unit menu

Derek and I have crafted a new compound widget called ScalarUnit, which incorporates this functionality a bit more conveniently, and handles the Adjustments internally. To set the value/units for this unit, this function is provided:

void setValue(double number, Glib::ustring const &units);

(I am assuming the performance cost of specifying units as a string will be negligible; I think that's a pretty safe assumption, but if not, we can gain back most of the performance by using Quarks.)

In addition, if you wish to flip the units, this function can be used:

bool setUnit(Glib::ustring const &units);

This will also recalculate the value so it "means" the same thing in the new units.

There will also be signal handlers for unit system changes. That is, if the user changes preferences regarding their units (such as switching the default unit for the document), a signal can be issued and all unit widgets will update accordingly.

If you provide this in your implementation of SPUnit, it will be almost a drop-in replacement. Just please don't touch any unit stuff outside of SPUnit and SPMetrics and SPUnitMenu, because there were tons of changes and fixes recently, throughout the codebase, caused by the removal of 0.8 and the change in base zoom. Please just provide the above API and it should be easy to merge.

Alright, will do. Like I mentioned earlier, the only place this is hooked into right now is the Transformation dialog. We'll take care to not hook it in anywhere else for the time being.

Bryce

On Tue, 2005-01-04 at 15:15 -0400, bulia byak wrote:

Wow. What do they rely on instead? What is the px/pt ratio in your code?

That's really a question for Bryce. I'm trying to learn as much as I can about units and conversions along the way, but I've mostly been focusing on other areas of the code.

On Mon, Jan 03, 2005 at 05:03:38AM -0600, Derek P. Moore wrote:

You brought up the issue of the dialogs in the Gtkmm code. That actually helps to illustrate my point. There's almost no way to migrate the new dialogs and dialog manager down into the legacy codebase. We could certainly put that work in some subdirectory of the main tree, and have configure/compile options to use the new stuff instead of the old. But within that single tree, we'd then have two dialogs for everything until the old dialogs were entirely ripped out and the compile options for the old stuff were removed. So developers would still have the problem of having to edit two separate dialogs in two separate locations just to uniformly add a checkbox to "Align and Distribute".

As mental said, having the files near eachother helps reduce divergance. It's doesn't solve it, but I'd say it's better than two separate trees.

As far as deep changes, I think that's okay and good. One deep change at a time is better than many deep changes at once. (Although I still haven't done the giant white-space replacement I had threatened to do so long ago...) :)

PS: I don't mean to scare up any FUD by introducing this thread. I don't think we have to worry much about a "divergence" between the two codebases or other such concerns that have come up with regard to the Gtkmm work.

That's cool; I think it's a valid discussion. And I think it's potentially a religious issue. More of the devels on Inkscape are comfortable with a single tree, which means your idea is met with resistance. I think either way will work, but my suspicion is that a merge now will save time in the long run (based on my estimations of the skills and attitudes of the other developers). So, speaking for myself obviously, my recommendation isn't based on the merit of "all coding must be in HEAD", but rather "inkscape developers seem to work best when all coding is done in HEAD".

On Mon, 03 Jan 2005 10:14:42 -0600, Bob Jamison <rjamison@...357...> wrote:

Now that we have developed some scar tissue, Gtkmm-ification all at once would definitely be a survivable battle. IMHO, I think that if the cvs HEAD didn't work for a few weeks while we converted, it would be OK. And it would be incentive for all of us to contribute, to get it done as soon as possible.

I agree. Different branches that are supposed to be worked on in parallel are certainly not a good idea. Please try to think up ways to merge gtkmm in stages, gradually, but please merge what you have anyway right after 0.41, otherwise it risks becoming too out of sync and the merge will be getting more and more difficult as time goes.

I'm coming in a bit late in this thread, but let me reiterate the plan, and address some of the issues that were raised.

* If you have strong feelings for how/when the gtkmm code is integrated, you are welcomed to get involved with working on the code.

* The inkscape_gtkmm code will be merged immediately after 0.41 is released. Remember, we were going to do this for 0.40 but people wished to squeeze out one more release before then.

* I do not think we can wait any longer than that, though, because while the code is not diverged yet, there is less and less we can do without having the full codebase behind it.

* If you've been refusing to help on the gtkmm work in order to boycott it into getting merged, I think you're a twit. ;-)

* I would like to continue with the current numbering scheme, and not jump to 0.50. As others point out, this is not the first big change brought to Inkscape.

Several people have suggested that a refactoring-in-place would have been a better approach. I had thought so too, but consider: That was already being done BEFORE I started on my side work. Honestly, I entirely expected that most of the gtkmm work would be done before I'd ever get anywhere with my codebase; after all, I'm one of the least prolific coders in this project!

Yet consider what actually happened: Different people each worked on different dialogs; each person's gtkmm implementation is different. There is now a lot of inconsistency between the dialogs, much more than when Inkscape started. Several of these dialogs were only partly finished before the coder became inactive or switched to other things. In several cases of Gtkmm conversion there was functionality lost, which some found particularly consternating due to the absence of the implementor. Clearly refactoring-in-place is not without a few risks.

Meanwhile, I've found working in a distinct codebase for the early portion of the development to be quite effective for me. With less total code to deal with, I found it easier to keep track of everything. It was faster to compile, easier to rip things out and do wholesale rewrites, and simpler to enforce code style and write documentation for it. On more than one occasion as I've learned new gtkmm tricks, I've realized I was a complete idiot; I was able to chuck the code out and start again, no harm no foul. The upside to having few people working on it, is that I've been able to keep the whole reasonably internally consistent.

But (thankfully) the code's been growing quickly. The simpleminded build system is now more hinderance than help, and we need Autoconf. Wholesale rewrites are much rarer now, and I think the framework is fairly solid now. I think that with this conceptually-unified structure, it will help address and avoid the inconsistencies that were such a problem before. Yet it's still young and pliable enough that it won't be very painful to change it where needed.

I've dug through the main codebase, and I've got a strategy for how to merge this into there, that I've talked about before. I'm fairly certain it can be done without too much trouble (magic shouldn't be required), however there are several things I'm concerned about:

* We need to be careful about things becoming highly inconsistent again. Don't Rush.

* The code is far from ready to be used right now. I don't think it is practical to replace the current ui with it; it has to be kept off to the side at least for a little while, until it's ready to go.

* The new ui code will almost surely have some (many?) aspects that won't be as good as the current codebase. Be Patient.

Bryce

On Fri, 7 Jan 2005, Felix Rabe wrote:

...

But (thankfully) the code's been growing quickly. The simpleminded build system is now more hinderance than help, and we need Autoconf.

Well - new framework, new build system? There was a discussion in August, the following two projects come to my mind here: Blender which uses Scons.

Actually, I believe we did make adjustments to the build system at that time (still using autoconf/make, but in a slightly tweaked way.) I think we also noticed that changing the build system did not solve the underlying problem that had prompted the discussion in the first place.

One of the main problems that precipitated the earlier discussions about other build systems was that we notice that seemingly minor changes can prevoke entire-codebase rebuilds. This is because of rampant header inclusion. One of the changes we're experimenting with in the new gtkmm codebase is 'implementation hiding'. This is a technique where a main header is kept extremely terse using forward declarations of classes instead of having to include the respective header, and by moving private details of a global class out into an 'Impl' object (see the Inkscape::Application class in inkscape_gtkmm for an example). Another example is the Dialog::Manager class, that lets you invoke and show dialogs without needing to know anything about the implementation of the given dialog.

I believe techniques like these will help us slice through the header inclusion problem. If we do indeed notice the benefits of this approach for the UI code, I hope we can replicate the approach through other areas of the code and eventually solve the compilation issues for real.

Bryce

On Fri, 2005-01-07 at 21:55, Bob Jamison wrote:

Bryce Harrington wrote:

...

This is a technique where a main header is kept extremely terse using forward declarations of classes instead of having to include the respective header, and by moving private details of a global class out into an 'Impl' object (see the Inkscape::Application class in inkscape_gtkmm for an example).

I would like to amplify that, going so far as saying that any major API item should be separated into interfaces and implementations; the interfaces being pure virtual with -NO- link dependencies.

Indeed. I think this should go in our coding style document (there should of course be exceptions for things like certain types of simple utility classes or generic algorithms).

One other thing to consider is that once you're doing this, you need not have a 1:1 Interface:Implementation mapping. Often you can share a single interface among several related classes.

For example, instead of having SPReprElement, SPReprElementImpl, SPReprComment and SPReprCommentImpl, SPRepr would simply become an interface that SPReprElement and SPReprComment would implement (and the latter two would not really be public outside the XML subtree). All the sp_repr_* functions would become methods on that interface.

At least on the large scale[1], inheritance should be used to specify interfaces, NOT to share implementations. Use composition for implementation sharing[2].

-mental

[1] On fairly small scales, implementation hiding does become counterproductive in C++.

[2] One exception might be where you have a large interface, and have one or more base classes that provide convenient default implementations for many of its methods. But it's still probably a good idea to "compose in" much of its functionality.

Bob Jamison wrote:

I would like to amplify that, going so far as saying that any major API item should be separated into interfaces and implementations; the interfaces being pure virtual with -NO- link dependencies. This is help in:

o Reducing compile times o Alleviating cascading link dependencies o Scripting (binding a scripted object to an interface) o Allow clean exporting of an Inkscape API.

I'd also want to push for everyone doing any of this to keep the 'standards' in mind.

That is, reference all the DOM specs and their friends.

DOM Level 2 Core Java binding http://www.w3.org/TR/DOM-Level-2-Core/java-binding.html DOM Level 2 Core ECMAScript binding http://www.w3.org/TR/DOM-Level-2-Core/ecma-script-binding.html

DOM Level 2 Events Java binding http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/java-binding.html DOM Level 2 Events ECMAScript binding http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/ecma-script-bindin...

DOM Level 3 Events Java binding http://www.w3.org/TR/DOM-Level-3-Events/java-binding.html DOM Level 3 Events Java binding http://www.w3.org/TR/DOM-Level-3-Events/ecma-script-binding.html

SVG Animation DOM interfaces http://www.w3.org/TR/SVG/animate.html#DOMInterfaces

XForms http://www.w3.org/TR/2003/REC-xforms-20031014/ http://xformsinstitute.com/essentials/

etc.