Created attachment 155266 [details] [review]
gtk_builder_expose_symbol

Created attachment 155267 [details]
Demo showing how to use gtk_builder_expose_symbol

The attached patch adds gtk_builder_expose_symbol. It is a little modification of the gtk_builder interface. A new flag "external" should be added to the glade file.

I was thinking about how to make some "real" programs using glade and GtkBuilder and using "signal autoconnection".

The most clearly visible problem with "signal autoconnection" with gtkbuilder is: if you want to send data for a callback, you are only able to send a widget (or component) defined on the .glade (or .ui) file as user_data. So, I was thinking about how to overcome this limitation.

The point is, if you want to make some data available to some callback you should have to explicit it. So, instead of doing:

    gtk_builder_connect_signals (builder, NULL);

to autoconnect all the signals, the code should be turned to:

    gtk_builder_expose_symbol (builder, "program_state", &state);
    gtk_builder_expose_symbol (builder, "foo", &bar);
    gtk_builder_connect_signals (builder, NULL);

The feature that sould be added now is: if the .glade file has the "external" flag set and "program_state" set as the user_data for a callback, then &state should be sent to such callback as user_data. The same with "foo" and bar.

The attached program is a demo on how it can be used.

I really would like to see this merged.

I wanted Marco to post the patch so we could boil down a good api
and get the kinks out (thanks).

Now that I look at the bug more closely (and read the attached emails)
I see the initially proposed feature was different, but goes hand in 
hand IMO.

So, first an obvious problem to note with this implementation is that
it treats the exposed symbol as gpointer and connects specifically
with connect_data() instead of connect_object(), which means we couldnt
use the api to pass an external object into the parse for signal
connections and have it safely referenced by the connections.

Second it bypasses the external connect function, which is not implementable
for pointers (implementors expect a GObject).

So I have some thoughts on how to tackle that:

  - Short term: Make gtk_builder_expose_object instead and only allow
    the exposing of external objects the the builder parse, this allows
    us to maximize on the feature without changing any api or heaps of
    internal code.

  - Long term: Possibly we could do an api like this:
    
       gtk_builder_expose_variable(GtkBuilder *, GType, ...);
    
       And extend the builder format like this:

       <signal id="foo" ...
               data-type="gchararray/gint/GtkSourceView..." 
               data-source="internal/external"
               data="external: the name of the external variable
                     internal: a fundamental value or object reference"
               swapped= ... after=... />

       As was mentioned in the mailing thread, that can internally
       be implemented by adding api to GObject:

         g_object_set_[float/int64/...]_qdata() 

       because it would mean tying the signal data memory to the life
       cycle of the receiver at least when the type doesnt fit a pointer
       (actually tying the life cycle to the actual signal connection would 
       be better...)

       Finally, I dont see how we can get around deprecating the current
       form of GtkBuilderConnectFunc and continuing to call it in the case
       of object data types, the policy would have to be: users of the
       new GtkBuilder features must be using the newer form of connect
       func, i.e. instead of taking a GObject * user data, it should probably
       take a GValue * for that.

All that said, I think that we can gain alot from at least allowing
people to expose an external object to the builder file without having
to add support for raw pointers right away.

But Im eager to hear what the GTK+ maintainers think about it ;-)

Created attachment 155372 [details]
gtk_builder_expose_object

Created attachment 155373 [details]
Demo showing how to use gtk_builder_expose_object

Recent attachements implement the short term plan as proposed by Tristan Van Berkom. The program attached show how to use it.

I'm curious to know gtk-devs opinion on this.

Created attachment 155380 [details] [review]
updta on gtk_builder_expose_object

Created attachment 155381 [details]
Update on demo showing how to use gtk_builder_expose_object

Just updated patch and demo program.

Comments welcome!

I created a new bug to track a couple of new GtkBuilder features that includes a revamped version of gtk_builder_expose_object()

*** This bug has been marked as a duplicate of bug 688205 ***