A Canvas Based Property Editor

Rationale

The last obviously annoying part of the Glade UI is the property editor, we have at least last summer added good api giving the plugin widget adaptors control on how the editors are layed out on a per class level - but it still needs to be more visually pleasing and less demanding in terms of screen real estate.

Implementation

Ultimately I would like for Glade to actually use a state of the art canvas library like hippo-canvas, which would be particularly useful for formatting dynamic text, like our translatable property names (truthfully we put off the work while Vincent Geddes was redoing the palette and the new workspace widget, at the time we were expecting GTK+ to choose and include a canvas widget), but at the same time I dont want to depend on a completely new library, so what I would propose is we just either chose and copy the implementation of a canvas widget into Glade (ala libegg), or just write our own canvas from scratch and reuse GTK+ widgets inside it everywhere possible (something like a glorified GtkLayout with GnomeCanvas like features).

So realistically the switch would be:

• Find/Write new simple canvas (one canvas widget, few items)

• Make GladeEditable widgets derive from the canvas

• Make GladeEditorProperty a canvas item

• Rework custom editors (that would be the treeviews editor liststore columns and data, the icon factory editor etc, they could just be embedded into the canvas inline as GtkWidgets since they dont already hog too much space).

Why A Canvas ?

The Canvas vs. Tree View discussion has been a popular one, so I'll just try to make my reasoning clear.

Glade needs the capacity to format the editor on a widget class basis, in a bit more depth that means that when you implement the GTK+ plugin you get to define property editor layouts for any given widget class (you can already tell Glade makes heavy use of this in GtkLabel, GtkButton, GtkImage and a few more).

Glade also needs to capacity to cascade editors, for instance; the Tree View editor includes a Tree Model editor within itself inline if there is a tree model set (with no tree model then a label is shown instead).

These are the features that make a Interface Designer useful, the more the property editor can be customized for a class, the less the user has to think about to customize an instance of that class in their project.

Basically my thoughts are that writing a Tree View to cover the above requirements will be bending the treeview code to our will, the treeview comes with its whole MVC package but then it would become an additional task to mold it into Glade, since Glade is already MVC by design internally.

On the other hand I view the Canvas as a thin drawing layer to be added on top of our already functional MVC data model, allowing the code that drives the drawing to do much more dynamic and fancy things.