After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 447972 - Add a way to specify user_data sent to signals
Add a way to specify user_data sent to signals
Status: RESOLVED DUPLICATE of bug 688205
Product: gtk+
Classification: Platform
Component: Class: GtkBuilder
unspecified
Other All
: Normal enhancement
: ---
Assigned To: GtkBuilder maintainers
GtkBuilder maintainers
Depends on:
Blocks:
 
 
Reported: 2007-06-15 18:18 UTC by Johan (not receiving bugmail) Dahlin
Modified: 2012-11-12 20:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gtk_builder_expose_symbol (6.39 KB, patch)
2010-03-04 22:37 UTC, Marco Diego Aurélio Mesquita
none Details | Review
Demo showing how to use gtk_builder_expose_symbol (302.68 KB, application/x-gzip)
2010-03-04 22:47 UTC, Marco Diego Aurélio Mesquita
  Details
gtk_builder_expose_object (6.25 KB, application/octet-stream)
2010-03-05 22:31 UTC, Marco Diego Aurélio Mesquita
  Details
Demo showing how to use gtk_builder_expose_object (302.98 KB, application/x-gzip)
2010-03-05 22:32 UTC, Marco Diego Aurélio Mesquita
  Details
updta on gtk_builder_expose_object (5.28 KB, patch)
2010-03-05 23:08 UTC, Marco Diego Aurélio Mesquita
none Details | Review
Update on demo showing how to use gtk_builder_expose_object (302.99 KB, application/x-gzip)
2010-03-05 23:08 UTC, Marco Diego Aurélio Mesquita
  Details

Description Johan (not receiving bugmail) Dahlin 2007-06-15 18:18:02 UTC
It'd be useful to have a way of specify the user_data sent to a signal.

It was discussed on gtk-devel;

http://mail.gnome.org/archives/gtk-devel-list/2007-June/msg00178.html

http://mail.gnome.org/archives/gtk-devel-list/2007-June/msg00213.html

It can either be done by passing in the values as pointers or add a new API to gobject which allows you to treat qdata in a data type specific way.
Comment 1 Marco Diego Aurélio Mesquita 2010-03-04 22:37:43 UTC
Created attachment 155266 [details] [review]
gtk_builder_expose_symbol
Comment 2 Marco Diego Aurélio Mesquita 2010-03-04 22:47:01 UTC
Created attachment 155267 [details]
Demo showing how to use gtk_builder_expose_symbol
Comment 3 Marco Diego Aurélio Mesquita 2010-03-04 22:48:08 UTC
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.
Comment 4 Tristan Van Berkom 2010-03-05 04:35:31 UTC
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 ;-)
Comment 5 Marco Diego Aurélio Mesquita 2010-03-05 22:31:58 UTC
Created attachment 155372 [details]
gtk_builder_expose_object
Comment 6 Marco Diego Aurélio Mesquita 2010-03-05 22:32:32 UTC
Created attachment 155373 [details]
Demo showing how to use gtk_builder_expose_object
Comment 7 Marco Diego Aurélio Mesquita 2010-03-05 22:34:18 UTC
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.
Comment 8 Marco Diego Aurélio Mesquita 2010-03-05 23:08:02 UTC
Created attachment 155380 [details] [review]
updta on gtk_builder_expose_object
Comment 9 Marco Diego Aurélio Mesquita 2010-03-05 23:08:48 UTC
Created attachment 155381 [details]
Update on demo showing how to use gtk_builder_expose_object
Comment 10 Marco Diego Aurélio Mesquita 2010-03-05 23:09:21 UTC
Just updated patch and demo program.

Comments welcome!
Comment 11 Juan Pablo Ugarte 2012-11-12 20:13:04 UTC
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 ***