I had a closer look at this.

>  First of all, signals are assigned globally for a gtype.  Right now  
>  php classes that extend a php-gtk gtype aren't creating their own  
>  gtype but just using their parents.  Why is this bad? Well if you  
>  extend gtkwindow and add a custom signal...the signal is added to  
>  gtkwindow (and by default also to your extended class) which may  
>  not be the intended behavior.  Now, it is possible to create new  
>  gtypes that extend a parent gtype so I know HOW to fix the problem,  
>  however I don't know WHERE that code needs to go.  Any suggestions?

I've started work on registering custom gtypes (from PHP classes).  
It's quite involved and I'll probably commit a big chunk once it's  
working.

>  The second problem is I'd like to allow custom signals to be  
>  created using just a class name and not an object instance.  I can  
>  grab the zend_class_entry but right now the gtype is NOT stored in  
>  it.  You can get the class entry from the gtype...but not the other  
>  way around.  Any suggestions for fixing that problem?

There is phpg_gtype_from_class(), but if you think it's useful to  
specify gtype via class name, then we should just add that to  
phpg_gtype_from_zval().

As for the patch.. Why do you think it's better to specify the class  
closure explicitly rather than rely on a standard, like  
"do_<signal_name> " or something similar?

Also, I'm thinking about moving all signal/type related methods and  
constants to GObject. Currently we have a few in Gtk:: class, but on  
reflection, I don't think it's the right place for it. I'd rather  
move it before the beta release. Any disagreements?

-Andrei

-- 
PHP-GTK Development Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php