Re: Re: ext/libglade complete?

That email was too long, I missed 4 and 5 :) 4. I'd dispute that. It's useful to people like Christian (who in fact asked for it), because his code is primarily object oriented. Look at zend_is_callable_ex() in the Zend Engine (you probably wrote it) - it checks for static calls. It also checks specifically for self:: and parent::. 5. What else has static methods that we're likely to want to use in a callback? ----- 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: [PHP-GTK-DEV] 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 - > > ;ÃFÕ:C‡¶ > > …Û)oÌŸÌ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 >