----- Original Message ----
From: Marc Dirix marc@electronics-design.nl To: Lance Dillon riffraff169@yahoo.com Sent: Fri, September 10, 2010 4:25:37 PM Subject: Re: glade signals with user data
Thank you for your answer.
I think you miss the point here.
The glade, interface designer, has an option "User Data" which should be send along with the signal to the signal handler function. This is defined in the glade xml file as "object=" in the signal directive.
If I now create two different buttons with the same signal handler, but different "User Data" I can differentiate between the two buttons.
I see what you are talking about here. That is something different. That is for when you build a c, c++, or ada project by going to Project->Build. It outputs a bunch of files. In the src directory there is a file called interface.c that has the code for connecting the signal. If you look in interface.c, you will see this in there somewhere:
g_signal_connect_swapped ((gpointer) Home, "clicked", G_CALLBACK (Change_Location), GTK_OBJECT (Home));
That is the callback. That is something completely different from signal_autoconnect(). That is a pike function that calls
glade_xml_signal_autoconnect_full(GLADE_XML(THIS->obj),pgtk2__signal_connect,&args);
which itself ends up calling pgtk2__signal_connect (in GTK2/source/gladexml.pre), which itself calls g_signal-connect_data with the pgtk2_signal_func_wrapper (standard pike/GTK2 signal function) with the pike callback and the args (the passed in object from signal_autoconnect()).
Since the code is a little different, what I would do would be to create a mapping with a bunch of data to be used by multiple callbacks. Then you can say match the object with a key in the mapping for data to pass to the signal.
I should add set_data() and get_data() to gobject (in the inheritance tree of all the widgets) so we could attach arbitrary data to gtk2 objects. It could be used to get around this problem.
For other people who may or may not be paying attention to this thread, what do you think about adding the gobject set_data/get_data functions?
http://library.gnome.org/devel/gobject/stable/gobject-The-Base-Object-Type.h...
On 10-09-10 23:51, Lance Dillon wrote:
I see what you are talking about here. That is something different. That is for when you build a c, c++, or ada project by going to Project->Build. It outputs a bunch of files. In the src directory there is a file called interface.c that has the code for connecting the signal. If you look in interface.c, you will see this in there somewhere:
Isn't the pike module all about generating the code. And as such shouldn't it try to implement the same?
I have no idea how hard it is, but isn't it just adding this data to the "mixed data" which is called together with signal_auttoconnect for each handler?
Since the code is a little different, what I would do would be to create a mapping with a bunch of data to be used by multiple callbacks. Then you can say match the object with a key in the mapping for data to pass to the signal.
The goal is not to have data at hand, the goal was to differentiate between the objects sending the signal.
Maybe I'm doing something very uncommon in interface design? I have i.e. two buttons, which have the same signal handler, and in the signal handler I want to do two different things based on which of the two buttons is pressed.
What is normally done here? Do you use different signal handlers for each button, or is there a different way to determine which button is pressed? And what if the buttons are dynamically created, maybe even with the same name?
(mind I'm very new to GTK altogether).
I should add set_data() and get_data() to gobject (in the inheritance tree of all the widgets) so we could attach arbitrary data to gtk2 objects. It could be used to get around this problem.
This would work I think. Then I could add a variable to the button object.
Isn't the pike module all about generating the code. And as such shouldn't it try to implement the same?
I have no idea how hard it is, but isn't it just adding this data to the "mixed data" which is called together with signal_auttoconnect for each handler?
The difference in this case is that pike not generating code. It is using the gladexml bindings, which isn't quite the same as the code generated for signals in glade. glade actually goes through all the objects and signals in its xml file, and writes out signal connect code using g_signal_connect() for each widget. However, the glade bindings don't give you anyway to do that. The only way we would be able to do the same thing would be to load up the xml file manually, and parse it for widgets and signals and stuff, like glade does. glade only accepts a gobject also, so you can't connect a pike object to it. Basically, the User Data field in the glade interface designer is not used in pike, only in the bindings that glade provides (c, c++, ada).
I was looking and I can't find a way to get a list of children, though.
Since the code is a little different, what I would do would be to create a mapping with a bunch of data to be used by multiple callbacks. Then you can
say
match the object with a key in the mapping for data to pass to the signal.
The goal is not to have data at hand, the goal was to differentiate between the objects sending the signal.
Maybe I'm doing something very uncommon in interface design? I have i.e. two buttons, which have the same signal handler, and in the signal handler I want to do two different things based on which of the two buttons is pressed.
What is normally done here? Do you use different signal handlers for each button, or is there a different way to determine which button is pressed? And what if the buttons are dynamically created, maybe even with the same name?
(mind I'm very new to GTK altogether).
I should add set_data() and get_data() to gobject (in the inheritance tree
of
all the widgets) so we could attach arbitrary data to gtk2 objects. It
could be
used to get around this problem.
This would work I think. Then I could add a variable to the button object.
the g_object_set_data/g_object_get_data methods may be the easiest right now.
glade3/gtkbuilder provides the appropriate functionality though. We should implement a glade3 object. glade3 is able to use the new gtkbuilder functions which is provided with gtk2.12 and higher. It provides gtk_builder_get_objects(), which would let me run down the entire list of objects and add signal handlers, or gtk_builder_get_object() to get an individual widget, so then I would be able to implement something like that in pike code (c or pike level).
I will add set_data()/get_data(), and work on some glade3/gtkbuilder bindings.
On Sat, Sep 11, 2010 at 10:53:26AM +0200, Marc Dirix wrote:
Maybe I'm doing something very uncommon in interface design? I have i.e. two buttons, which have the same signal handler, and in the signal handler I want to do two different things based on which of the two buttons is pressed.
What is normally done here? Do you use different signal handlers for each button, or is there a different way to determine which button is pressed? And what if the buttons are dynamically created, maybe even with the same name?
two different signal handlers does not sound to bad. if you want a common functionto do allthe work then the signal handlers could be short wrapper functions:
signal_button_1(mixed ... args) { button_handler("button_1", @args); }
signal_button_2(mixed ... args) { button_handler("button_2", @args); }
you could even hide those with inline lambda, and autogeneration of such functions should also be possible (but not if they have the same name, unless you add more info)
greetings, martin.
You could also create signal handling objects, with whatever state you like:
class button_handler(string name) { void `()(mixed ... args) { /* ... */ } }
widget->signal_connect("pressed", button_handler("button 1"));
interesting. that is an object that works like a function because it overrides the () operator with `()
but this only works if the argument is not tested with functionp(). or can functionp() be tricked somehow?
greetings, martin.
callablep() is a better way to check if an argument can be called.
http://pike.ida.liu.se/generated/manual/modref/ex/predef_3A_3A/callablep.htm...
ah, i didn't notice callablep() yet, (most likely because callable is not a type).
though i'd still need to use function|object or better something like
class Callable() { mixed `()(){} }
and then use function|Callable in places where i want to accept a callable argument
greetings, martin.
A type "callable" would be cool, but really tricky to test for. We haven't even managed to complete callablep() yet...
can you elaborate on that please?
what else beyond somethig like typedef function|Callable callable; would be needed? (where Callable refers to the class example i made earlier)
do you mean it would not be easy to write tests for the implementation of a callable type? and what is incomplete about callablep()? also the tests?
or do you mean something else? (why should dificulty of writing tests prevent implementation of a feature?)
greetings, martin.
Every program without constructor can be called and will produce an object. Arrays containing callables are callable.
There is a FIXME in the code, so I assume the code isn't done.
No, that is not needed. An object which has a method `() of type function(a:b) is assignable to a variable/formal parameter of type function(a:b). So just "function" will do, although in general I'd recommend specifying the argument and return types as well, for better static typechecking.
pike-devel@lists.lysator.liu.se
-
Lance Dillon -
Marc Dirix -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum -
Martin Baehr -
Martin Bähr
-
Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum