Fw: [PHP-GTK-DEV] Fw: [PHP-GTK] ext/libglade complete?

OK, so there's no way to pass arbitrary data from within glade files. Groovy. I've been looking at other languages to see how they've resolved the signal_autoconnect() problem, and they _all_ have different ways. Perl's version has three separate functions for signal_autoconnect(), two of which are 'convenience functions'.... heck, even libglade only has two... We've the choice of implementing signal_autoconnect_full() (which is libglade's own solution to the dilemma) or else doing more or less as you did before. I really don't like this array('gladefile_callback' => array('php_callback', $data)...) set-up - my initial instinct was to kill that 'php_callback', but then Christian won't get his $this. It'd be nice to make that 'php_callback' element an optional array - it shouldn't ever be used unless it _is_ an array, if that were the case. Thoughts? /me gets on with it ----- Original Message ----- From: "Steph Fox" <steph@zend.com> To: "Andrei" <andrei@gravitonic.com> Cc: "PHP-GTK dev" <php-gtk-dev@lists.php.net> Sent: Sunday, October 30, 2005 5:09 PM Subject: [PHP-GTK-DEV] Fw: [PHP-GTK] ext/libglade complete? > OK, I see what you mean now. It's ugly, though - it makes a lot of > unnecessary work, mapping every callback manually. The whole point of > signal_autoconnect() is supposed to be that you don't need to do that. From > source: > > /* > * use gmodule to connect signals automatically. Basically a symbol with > * the name of the signal handler is searched for, and that is connected to > * the associated symbols. So setting gtk_main_quit as a signal handler > * for the destroy signal of a window will do what you expect. > */ > void glade_xml_signal_autoconnect (GladeXML *self); > > /* if the gtk_signal_connect_object behaviour is required, connect_object > * will point to the object, otherwise it will be NULL. > > > I'll see if I can find a nicer way around it than we had in PHP-GTK 1 and > keep to the spirit of the original. The marshal appears to allow user data > to be passed, but I need to figure out how user data is specified in Glade. > > - Steph > > ----- Original Message ----- > From: "Steph Fox" <steph@zend.com> > To: "Andrei Zmievski" <andrei@gravitonic.com> > Cc: "PHP-GTK dev" <php-gtk-dev@lists.php.net> > Sent: Sunday, October 30, 2005 4:08 PM > Subject: Re: [PHP-GTK] ext/libglade complete? > > > > Andrei, hi, > > > > 1. Thanks :) I really couldn't see how that was supposed to work. > > 2. signal_autoconnect() will take an object instance specified via Glade > > (e.g. 'button3'). It calls connect_object() for those calls, and > connect() > > for the rest. Same goes for *_after(). We don't need it to do any more > > than that. Glade 2 itself doesn't offer further connect_* alternatives, > so > > to offer anything further would lead to users having to alter the XML file > > manually. > > 3. I'm not 100% certain what you mean here, but I'll look into it. > > > > Thanks for reviewing the code, > > > > - Steph > > > > ----- Original Message ----- > > From: "Andrei Zmievski" <andrei@gravitonic.com> > > To: "Steph Fox" <steph@zend.com> > > Cc: "PHP-GTK dev" <php-gtk-dev@lists.php.net> > > Sent: Sunday, October 30, 2005 12:57 AM > > Subject: Re: [PHP-GTK] ext/libglade complete? > > > > > > > Hi, > > > > > > I sat down and looked at the libglade extension implementation, > > > especially the signal connection functions. I have a few comments. > > > > > > 1. I'll take care of custom widget handlers. It requires implementing > > > our own GObject subclass. > > > 2. It will be useful to have a signal_autoconnect_object() method > > > that can take an object instance and auto-connect the glade handlers > > > to the methods of the class. > > > 3. The current implementation of signal_autoconnect() supposedly > > > takes additional user data to pass to callbacks, but it passes the > > > *same* data to every callback. If you look at how it worked in PHP- > > > GTK-1, you will see that it was a lot more flexible: > > > > > > http://gtk.php.net/manual/en/ > > > glade.gladexml.method.signal_autoconnect.php > > > > > > 4. I am not sure how useful it is to be able to supply callbacks in > > > the "class::method" form. It only allows you to invoke static methods > > > of the class. Working with an object instance is a lot more useful > > > (see comment #2). > > > > > > 5. Why do we have this: > > > > > > if (strcmp(php_class, "gtk") == 0 || strcmp(php_class, > > > "gdk") == 0) { > > > gtk_flag = 1; > > > } > > > > > > Assuming we want to keep the "class::method" callback > > > functionality, why do we need to explicitly check for 'gtk' and > > > 'gdk'? What about 'pango', 'atk', and everything else? > > > > > > That's it so far. > > > > > > -Andrei > > > > > > > > > On Oct 21, 2005, at 7:20 AM, Steph Fox wrote: > > > > > > > Hi all, > > > > > > > > I think I just finished work on the libglade extension. > > > > > > > > There are two functions I don't know whether to implement. > > > > > > > > One is GladeXML::new_from_buffer(), which replaces Glade 1's > > > > new_from_memory(). Does anyone (or _has_ anyone) actually tried > > > > using this? > > > > If there's any demand for it at all, I'll need a test script > > > > demonstrating > > > > its usage. It doesn't need to be written in PHP. > > > > > > > > The other is glade::set_custom_handler(). This appears to be > > > > intended for > > > > advance usage, and I'm not sure how useful it is outside C, but > > > > again - if > > > > anyone's used it in any language _other_ than C, I'll implement it if > > > > there's a) demand and b) a test script available demonstrating the > > > > way in > > > > which it is used. > > > > > > > > Four functions will never be implemented. These are > > > > GladeXML::signal_connect_data() because we don't need it, the > > > > *_connect_full() methods aren't intended for use other than > > > > internally, and > > > > the GladeXML::construct() method - a hangover from GtkObject - > > > > isn't useful > > > > other than internally. > > > > > > > > Everything else should work as advertised - please test! Bug > > > > reports to > > > > http://bugs.php.net in the PHP-GTK section. > > > > > > > > Thanks, > > > > > > > > - Steph > > > > > > > > ps win32 implementation and short test script - > > > > > > > > http://ftp.emini.dk/pub/php/win32/gtk2/php-gtk2-patched.zip > > > > > > > > -- > > > > PHP-GTK General Mailing List (http://gtk.php.net/) > > > > To unsubscribe, visit: > > > > http://www.php.net/unsub.php > > > > > > > > > > > -- > PHP-GTK Development Mailing List (http://gtk.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php >