Created attachment 113585 [details] [review]
Patch

Created attachment 113700 [details] [review]
Patch for the previous patch

I found that I removed is_void_user_data call without providing an equivalent. Fixed by this patch.

Could you give some more information about what this patch changes and what the benefit is?

Thanks!

Im not against the idea of allowing custom derived editor widgets
per se, Im not sure how they would integrate with the treeview...
but I think if there are things that are lacking in the editor,
we would rather see it implemented in glade.

care to attach a patch just for the bug you fixed ?

Note: The signal editor widget is admittedly a mess, and needs
work (gtkbuilder specific support for possible builder features
such as string int and enum user datas etc, the string boldness
and italicness is also broken...).

Created attachment 114122 [details] [review]
Bugfix

Is it what you asked for?

I want to create own signal editor in anjuta because I need to set new construction-only properties, like column, renderer and completion store. Those properties and new signals, that I can connect to in anjuta, allow me to perform different operations with source code. As far as glade's signal editor uses only model I think it's ok to modify columns and renderers.
I can't see any problems with gtkbuilder specific support. I noticed that at least boldness doesn't work, but I thought it's not a significant bug.
Summary of my changes:
- signal editor became a gobject class
- new signals added and old handlers became default handlers for those signals
- new construction-only properties
- fixed bug when removing a row
- some other little changes.

Created attachment 114341 [details] [review]
I forgot about glade-window.c

oops marked wrong bug sorry

Created attachment 126380 [details] [review]
Improving GladeSignalEditor, second try

This patch does the same as previous one (I mean three obsoleted patches) plus boldness and italicness fixed.
The only purpose of creating custom signal editor is setting contruction-only properties for creating custom completion stores (e.g it can be filled with project symbols) and column renderers (e.g. highlighting symbols).
Unfortunately I know nothing about int and enum user datas, though possibility of custom userdata completion store was made "for symmetry".

Unfortunately this patch wont work well for your purposes, simply 
because the signal editor gets instantiated in more places - 
there is a signal editor in the treeview/menu editor, and also the 
"edit separately" context menu item allows you to spawn an editor 
for a single widget at will.

I already plan to split out the frontend editors from the core, so
my solution will probably be to use a factory interface recognized by the
core and implemented by frontend gtk+ specific implementation lib; where you
could more easily implement the signal editor creating code.

If you want we can integrate something like your patch here - to
get the features in gnome 2.26, I will probably end up switching the
api after - but your patch should take custom editors 
(gladeui/glade-base-editor.c particularly) and independantly created 
editors into account.

Suggestion: maybe add something like glade_app_set_signal_editor_type();
and a GladeApp::signal-editor-created signal, that passes the newly created
editor as an argument (to let the frontend connect the signals)... that
could work until we have a proper "editor widget factory" in place.

For now I need four things:
- being able to create a custom handler completion store;
- receive a signal about creating a new handler for creating a handler stub;
- receive row-activate signal for the same.
- to know what signal editor and its row is active, so the handler stub can be created after entering the handler into the signal editor.
I don't know how much will the new editor differs from the current one (and my patch does slight changes to its functionality), but anyway I'm going to complete the solution without that new editor and I hope there will not be many problems while migrating to the new api.

these requirements are fairly straightforward, and I guess pretty
portable (i.e. an iface would generally have the same 
properties/signals).

Also, if and when I manage the whole refactoring/split, I hope
to offer the same editor widgets as seemlessly as possible,
maybe in a gtk+ specific frontend lib, or directly implemented
from the base gtk+ catalog (i.e. old editors implement new interfaces
and just integrate with the core a little differently) - I also
hope to offer a more project based api which may result in the
loss of the whole "active project" idea, which can be buggy
when trying to handle multiple projects and copy/paste otherwise.
if it poses real changes I'll include updating the anjuta plugin
as part of the task and offer to do the porting work myself.

Created attachment 126805 [details] [review]
Improving GladeSignalEditor, third try

I've made a new signal GladeApp::signal-editor-created for setting up every signal editor, but the first (main) signal editor is created too early (in the glade_app_init()), so I kept glade_editor_set_signal_editor() for recreating it.

Patch commited in trunk