Hi all,

We had identified the primary goal for this next release, 0.40, to be the conversion of Inkscape's user interface from Gtk+ to Gtkmm.

To date we've been attacking this both from a bottom-up perspective, by working on converting individual dialogs to Gtkmm, as well as a top-down perspective, by starting from the top level Inkscape::Application object and working down.

This latter top-down approach is what I've been working on the past few weeks. Here's a summary of where this work is at.

The Inkscape::Application class is the top level manager of the main window. It creates and provides the callbacks for the GUI elements such as menus, toolbars, the main canvas, the statusbar, etc. One day, once this is merged into the main Inkscape codebase, it will also own things like the user preferences and the document model itself.

You'll notice that the application.h file is pretty terse. This is because nearly all of the Inkscape::Application internals are hidden in a subclass called Inkscape::ApplicationImplementation. This means that the application.h is kept very lightweight, and other parts of the program can include it without including the whole world (only gtkmm/window.h).

Inkscape::Dialog is a new abstract class. This provides a general purpose interface that Inkscape::Application can use for interacting with any of the dialogs. If there are stylistic or behavioral aspects that we want to apply to all dialogs in Inkscape, this is where we would do it. For instance, this class will provide common routines for saving the position and size of dialogs in the user's preferences, as well as the transient behavior. If you recall the trouble we had implementing those in each dialog independently under Gtk+, you can imagine how this will help centralize the behavior to one easily maintained place.

Inkscape::DialogManager is another new class. This is basically just a container of all the dialogs in Inkscape, that allows us to construct them lazily - instead of creating them all at program startup, we construct them right before they're first used, then cache the dialog until DialogManager gets destructed. DialogManager also provides a set of signals that can be issued to all Inkscape dialogs, such as to show/hide all dialogs. DialogManager hooks these signals to each dialog as it creates them.

One of the nifty things about Gtkmm is that it makes it quite easy to create new widgets, and we're taking advantage of this by creating "compound widgets" for sets of widgets that get reused throughout the application. For instance, most of our dialogs are implemented as Notebooks with pages that contain labeled frames within them and a table within that; the Inkscape::NotebookPage widget provides a convenient way to build a dialog using this scheme. LabelledSpinbutton, created by Carl, provides a combination of a label and a spinbutton entry, which is used repeatedly on the preferences dialog. ScalarWidget provides a widget for entering numbers associated with units, such as appears heavily on the transformation dialog and in general throughout the application.

Using these widgets, Carl and I have roughed out much of the transformation and application preferences dialogs (although none of the widgets are hooked to anything internally yet).

In general, what we can expect from Gtkmm is a) flexibility, and b) reduced linecount. It uses the exact same widgetset underneath, so by and large Inkscape will *look & feel* the same, and there's no plans to redesign the layout of anything (although we may do some small tweaks where it makes things easier). But this will let us do the same stuff in a fraction of the number of lines of code; this will make it easier to maintain and enhance Inkscape's look and feel in the future.

This top-down gtkmm work is available in Inkscape's 'experimental' CVS module, in experimental/bryce/inkscape_gtkmm. A simple makefile is included if you'd like to fire it up and try it.

If you're interested in working on something related to this Gtkmm work, you'll find this top-down codebase pretty easy to get up to speed on, since there's only about a dozen files of significance. There are examples of both widgets and dialogs, that you can use as guides in developing your own widgets and dialogs. Inkscape::Application has many of the stubs in place for adding menus, toolbars, the statusbar, and the canvas, so if you're interested in working on any of those, the hooks are there for it.

If you've never done Gtkmm development, you'll find the tutorial at gtkmm.org to be quite handy - took me only a couple evenings to work through enough of the examples to feel comfortable with it. If you're not sure about your C++ skills, don't worry - gtkmm is designed in a way that allows this work to be done using really basic C++ features, so as long as you're familiar with inheritance, constructors/destructors, and public/protected/private, you should find it pretty clear. Knowledge of templates is helpful, since they're used in various places, but not required - you can learn as you go.

There is a PLAN file with some todo's I've identified for myself to work on. At the end of that file, I've also written up some little projects (like implementing the Statusbar or developing Accelerators) that need doing. You're welcome to commit work into this package, although I appreciate hearing what you plan to work on so we can coordinate efforts.

The big picture plan for this is to get the structural aspects figured out and examples put in place, then move it into the main Inkscape codebase for further development, with a cmdline flag to indicate which interface to use. I'd like to have at least two dialogs at 100% (including docs!), half a dozen compound widgets fleshed out, some of the canvas integration code stubbed out, so it'll be clear how to plug in the canvas when we get to that point.

Bryce