Trucking along...

Removing all the references (and comments referring to) DEFINE-DYLAN-CLASS has now been completed. There were more of them than I remembered (even with a revision control system I tend to prefer to comment things out rather than remove them altogether), but there are a lot of classes defined by DUIM. At least they're gone now.

Defining :default-initargs properly resolved a few issues with the scrolling; in the hopes that the lack of scrolling was preventing tree + graph controls from being displayed (they're both displayed in scrollers) I added a <gtk-viewport> type built on GtkLayout to contain the scrolled sheet. Now this is in place, scrolling "seems" to behave itself, more or less. is a little like a cross between a <gtk-fixed> in that in can contain child widgets, and <gtk-drawing-area> in that it provides a drawable surface. It offers a couple of other facilities too (like being able to attach scroll bars to it) but for now I'm going to punt and let DUIM deal with all of that.

Unfortunately fixing scrolling didn't help with tree + graph controls, which still weren't being displayed. After much fun and games, it turns out that these controls end up drawing to the "wrong" drawable. The issue here is that when mediums are attached to sheets, those sheets are not yet mapped and there are no (x) drawables so the code ends up associated a null drawable to the medium. Whenever an attempt is made to draw to the medium the code checks that the drawable is non-null and if it is null, again attempts to set the drawable for the medium.
The problem in all this is two-fold:

• The sheet being drawn to is not necessarily the one that the medium was initially attached to (child sheets can use the medium of a parent, and DUIM rebinds the medium-sheet to be the sheet where drawing "should go" so that transforms etc. don't lose)
• The drawable for everything comes from the GTK widget->window pointer, except for GtkLayout where it comes from layout->bin_window instead.

In most cases (because the same X window is referred to by widget->window) it doesn't matter which sheet's drawable gets hooked up to the medium. In the case of GtkLayout though, it does matter because the widget->window value of the sheet that is contained in the layout does not match layout->bin_window and the code ends up attempting to draw onto a drawable which is obscured by the layout->bin_window drawable.
At the point we first have a non-null native drawable, we've very possibly lost the reference to the sheet to which the medium was attached (i.e. we are drawing to a child sheet of the sheet the medium was attached to). In the case of viewports the drawable needs to come from the original sheet.
I've fixed this by keeping track of the sheet the medium is attached to in a slot in <gtk-medium>, but I don't really like the solution. I'll try to come up with a better one.

With all that done, tree and graph controls appear on screen, at last:


Hrm. There's still a few issues with tree + graph drawing, apparently... I'm pretty sure what the problem is with the control-buttons, and that is the pixmaps that they are drawn into are created on the "wrong" drawable which at least should now be relatively easy to fix (that is, it's the same problem I've already solved for viewport children).

At least I have some clear problems to overcome now with these controls, and a couple more issues can be knocked off the "major stuff to do" list and be moved onto the "stuff that really needs cleaning up" list.