Re: ext/libglade complete?

On Oct 30, 2005, at 11:36 AM, Steph Fox wrote:

Thing 1, which you won't know yet because you don't have the code handy, is there is no such thing as signal_autoconnect_object() in libglade now. signal_autoconnect() does it all.

<groan> Of course there is no such API in Glade. I just sat on my ass, stared at the ceiling tiles for a bit, and invented it. Is that so wrong? Besides, signal_autoconnect() in Glade is C, which means that it only looks at the C level functions.

Thing 2 is that there's already a way to achieve this. I don't see what's so problematic about having a callback in the Glade file called 'MyApp::on_ok_clicked'... if you have some issue with the callbacks being public you can just move the whole lot, including the call to gtk::main(), inside the class and use self:: instead. What am I missing here?

The issue with 'MyApp::on_ok_clicked' is that you are required to know the name of the implementing class in PHP during implementation of your Glade interface. That sucks. The issue with self::, well, I still need to see what self:: resolves to during signal_autoconnect() call. I'm building Glade2 right now so I can try it out.

Thing 3 is that there's no precedent for that syntax. Doesn't mean it couldn't be done, but _should_ it be done? - personally I think not, given that you were right about the need for the optional array parameter to pass data. The main problems with the signal_autoconnect() function are the ones I'm working on addressing now.

Is there precedence for 'MyApp::callback' syntax? If you are not happy about having a separate signal_autoconnect_object() method, it wouldn't be that hard to modify signal_autoconnect() to check whether it got an object instance as the first parameter, and if so, hook up the callbacks to it. I prefer to have a separate function because it's cleaner. - Andrei