I'm unfamiliar with how libgdl in Inkscape differs from upstream libgdl, but I hope we can get rid of the one currently in Inkscape, or at least clarify how inkscape's use needs to differ so that we can minimize differences from upstream. Last I looked, the libgdl had several problems, but one doesn't really want to work on Inkscape's copy without knowing what the plan for using upstream is.

pjrm.

On Sun, 22 Feb 2009 00:18:01 +0000 Joel Holdsworth wrote:

Hi All,

[...]

Hi Joel, (and hello again list :)

I notice that Inkscape uses it's own forked version of GDL. I don't know who's maintaining that code, but can I suggest that someone take some time to try and move over to using the shared library? The Anjuta guys are very helpful, and seem happy to accept all kinds of patches, including feature additions, so there shouldn't be too many political problems in merging.

I forked of GDL and introduced it in the tree about 1 1/2 years ago for implementing the dockable dialogs. I then maintained it for a while until I took a break from Inkscape development.

The main reasons for forking it back then were (IIRC):

Dependencies ------------ As I remember it, the availability of recent releases of GDL was pretty poor among the common Linux distributions, but I guess things have improved since.

GDL, in turn, depends on libglade2 for saving a dock layout to XML and I stripped out that part to avoid the extra dependency. libglade2 would not be a problem on linux (given that GDL is available), but for Win32 (and Mac OS X?) we would have to bundle it (not sure how much it weighs). Modifying GDL upstream to allow it to be built with/without libglade2 (serialization support) is another possibility, and that would likely be easy. Support for saving saving a dock layout in Inkscape is, on the other hand, a much requested feature...

Modifications ------------- To make dock items behave more like (and work better with) our existing dialogs I made some more or less intrusive changes:

* I added an option to let dock items expand their container dock objects. This was needed in order to allow the user to always expand a dialog in the dock by pulling it's bottom handle downwards. In turn, the reason for wanting this was based on the chosen design where the dock can hold an unlimited amount of content (i.e. it should always grow on the height).

This fix was more of a hack and I wouldn't propose pushing it upstream (it most certainly breaks some fundamental design ideas of GDL ;). Anyhow, it's committed in revision 16337 in trunk (src/libgdl).

I would rather "fix" this in Inkscape by using GDL in a more normal way. In practice this would mean that the dock should always use the available display height but no more (i.e. no scroll bar). This is how it works in Anjuta and also in SWT (used by Eclipse) and I believe Adobe Photoshop/Illustrator/etc. CS>2.

An effect of this solution is that if the user opens a single dialog in the dock it will be stretched to the full height of the dock. This looks pretty weird for a good deal of our dialogs (e.g. the Align dialog and the Transform dialog), so they would have to be changed. This approach probably works better for dialogs that have their own scroll bars (like the Layers dialog and the Undo history dialog) as they can be shrunken.

* Allowed dock items to gain focus. This means they can catch key presses like Ctrl+w (to close a dialog). Focus is indicated by drawing the dock item's grip bar in a darker color. I also implemented support for letting a dock object pass focus to its children. That allows the user to "jump" between the widgets in a dialog by pressing Tab by using the arrow keys.

Revision 16035 and 16088 in trunk (src/libgdl) contains most of this. It could probably go upstream in some form if it's made optional. (Might break other applications otherwise?)

* A crude implementation of the behaviors GDL_DOCK_ITEM_BEH_CANT_DOCK_{BOTTOM,CENTER,LEFT,RIGHT,TOP}. They are defined in gdl-dock-item.h upstream, but were never used as far as I know. I implemented because I needed an option to prevent center docking (i.e. tabbing) as some users found it confusing. Some more familiar with GDL's internals should probably decide what's a reasonable implementation of those behaviors.

* Other peoples fixes after me... (I haven't kept up to date with trunk :)

So to sum it up: I think it's possible to switch to using upstream GDL with some pretty small changes to GDL and some redesign of Inkscape's current dock behavior (and dialogs). Unfortunately I don't have the time as of today to carry out such a project as I'm working full time and try to finish my master thesis in my spare time. So unless someone else is up for the job, I'm afraid it could take a couple of months before any progress would be made.

If you can merge over, then Inkscape, Anjuta, and Lumiera will all benefit from shared maintenance of the code. The flip side is that I'm squashing bugs, and I'd like Inkscape to benefit from my work!

I'm all for using shared libraries and I agree we all could benefit from it! It's therefore pleasing to hear that you and the Anjuta people are actively working on GDL -- it provides GTK applications with an important set of functionality that GTK unfortunately lacks. I really hope that GDL will merge into GTK one day...

Best regards,