[Glade-devel] Signal editor rework

[jhs at jsschmid.de (Johannes Schmid)]

Hi!

Code: http://git.gnome.org/browse/glade3/log/?h=signal-tree-model

Interesting parts:
*
http://git.gnome.org/browse/glade3/tree/gladeui/glade-signal-editor.c?h=signal-tree-model
*
http://git.gnome.org/browse/glade3/tree/gladeui/glade-signal-model.c?h=signal-tree-model

Why?

My starting idea was to be able to drag signal handlers from glade into
anjuta and automatically creating the prototypes. Some may have seen my
GUADEC lightning talk on that issue.

So I looked at the SignalEditor and that was a big monolitic block with
many custom cell rendering methods with a backend based on a GtkTreeStore.
The GtkTreeStore meant that updating things was rather painful and that
the data structure of the GladeWidget was duplicated and had to be kept up
to date with the widget.

So my idea was to use a custom GtkTreeModel instead that would use the
signal structure of the GladeWidget directly. I though about implementing
directly in glade-widget.c but realized pretty soon that this would bloat
that file two much and that it wouldn't be obvious that a GladeWidget
implements a GtkTreeModel.

As such, I started on GladeSignalModel which is basically initialised
using a GladeWidget and displays it's data. In the model/view-concept this
holds the signal data which is taken from the GladeWidget directly without
duplicating it.

This model implements the drag and drop stuff based on GtkTreeDragSource.
The most complicated thing in the tree model is that we need to take care
of dummy nodes that a used to enable the user to add new signals.

The implementation of the GladeSignalEditor on top of that was trivial then.

Status

Everything is feature complete compared to the old GladeSignalEditor,
minus the deprecation warnings and the devhelp button. These are both not
difficult to add I just didn't come to it, yet.

What needs to be improved?

I don't like the way the GtkCellRendererCombo works for the object
selection with a real tree (not a list). I think that isn't convenient yet
and needs a better solution.

Some horizontal space could be saved by using the "Name" column for both,
object names and signal-names instead of a additional "Handler" column.
This is quite easy to do.

Conclusion:
While I didn't save as much code as I wanted to (mainly because of the
GObject template code necessary) I think the implementation is much
cleaner than the code before.

Regards,
Johannes