[Kde-perl] Signals & Slots

[Germain Garand]

Le Mercredi 04 Juin 2003 08:27, Ashley Winters a écrit :
> Umm... Request For Comments? I've been thinking about how to come up
> with a real syntax (as opposed to the current kludge) for
> signals/slots. Here goes:
>
> sub foo : signal( foo(int) );   # no body!
>
> sub hitButton : slot( hitButton(QWidget*, const QString &) ) {
>     my $w = shift;
>     my $str = shift;
>     # ...
> }
>
> And, when PerlKDE gets released:
>
> sub doSomething : dcop( doSomething(const QString &) ) {
>     my $thing = shift;
>     # ...
> }
>

Ashley, I simply _love_ it!
It's much more informative and clean.
Besides, that's exactly what the Designer plugin will need to get rid of the
hideous "# SLOT: () " markers hack.


> Everyone agree that Perl sub attributes are the way to go? Yes? Anyone
> want to submit a patch that makes this happen? :)
>

Done, I couldn't resist! 

I implemented 
   sub foo : signal( int )
rather than
   sub foo : signal( foo( int ) )
as it looked a tad confusing to me ( but looking at the regex below, I think 
that's what you meant anyway)

> It's a PerlQt/KDE attribute if /^ (signal|slot|dcop) \( .* \) $/x
>
> Beware of trivial argument parsing... split "," will not do what you
> want (think: "slot( foo(QClass<int,int>, QString&) )"). Consider using
> (??{}) recursiveness.
>

 out of laziness, I just robbed your nice kdocUtil::splitUnnested and tweaked 
it a bit :-)

> To be honest, I can't think of a simple way to go from CODE->GLOB->name
> from within Perl without using some B:: goodies, so some XS may be
> required to tuit the name of the sub the attribute is being applied to.
> Then again, perhaps future versions of PerlQt will allow slots to be
> directed to anonymous subs. :)
>

I found the nice Peek::Devel::CvGV( cv ) which does exactly what we need.
The tough part is that at MODIFY_CODE_ATTRIBUTES time, the GV isn't even 
set...
So eventually, I put the final metaobject initialisation stuff at the very 
beginning of the Qt::Application constructor.
Not pretty, but should work in any case...


> I'm also thinking about plugging PerlQt into POE. Seems interesting.
> Later, though.

Ah, I remember reading the kernel hooks of the Tk and Gtk backends, back when 
Stephane Payrad wanted to use it with PerlQt.
I was so scared I ran away :)
It seems to require a tight control of the eventLoop, and that's not really 
easy nor documented...

Cheers,
Germain