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 _______________________________________________ Glade-devel maillist - [email protected] http://lists.ximian.com/mailman/listinfo/glade-devel
