[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-perl
Subject:    Re: [Kde-perl] PerlQt-3.006
From:       Ashley Winters <jahqueel () yahoo ! com>
Date:       2003-02-14 19:47:37
[Download RAW message or body]

--- Germain Garand <germain@ebooksfrance.com> wrote:
> Le Vendredi 14 Février 2003 13:11, Stéphane Payrard a écrit :
> > Hi Germain.
> >
> > Great release.
> > I like very much pqtsh and pqtapi.
> 
> Thanks :)

Indeed! That's some handy stuff, Germain.

> > I find a drag to be obliged to explicitely derive classes for
> minimally
> > customized widgets.  Would it be possible to implicitely define a
> > class per instance when using the following syntax to add signals,
> slots
> > and attributes for that instance?
> >
> > this->signal(    changeIt   => ['int', 'int'] );
> > this->slots(     wasCLicked => [ [], sub { }] );
> > this->attributes qw( more attributes );
> >
> > I have not sufficient understanding of the internals to know if it
> is
> > possible. Also I am not sure what 'ref' should return when applied
> to
> > such an object.
> 
> That would be possible, but I really doubt it could be a good
> thing...
> It's clearly a big breach in object orientation (giving an anonymous
> sub{} as 
> argument to a new slot, that's just returning to the painful mess of 
> callbacks)

Well...................

Truth to tell, I've always had a fancy for having callbacks, but not in
the signal/slot declarations themselves.

$app->connect('quit()' => sub {
    # do stuff here.
});

The only problem with that is 'this' would normally be invalid for that
sub (likely, it would be a Qt::Application). To do it the
<em>right</em> way, the slot info would have to keep a weak reference
to 'this' at the point the slot was created, and restore it when the
slot is called. That way, all the non-lexical attributes (and 'this')
remain valid along with the lexical variables (thanks to Perl's
closure).

Yes, that proposal would mean things like this become legal:

$app->connect('quit()' => \&closeAllWindows);

> As for adding new signals/slots/attributes to subclassed widgets at
> runtime, I 
> added
>    eval "use Qt::slots foo=>[]" 
> and the like...
> I"m very reluctant to go any further and make it part of the API...

I don't like extending APIs at runtime. Make the easy things easy, and
the hard things possible...

Ashley Winters


__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
_______________________________________________
Kde-perl mailing list
Kde-perl@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-perl
[prev in list] [next in list] [prev in thread] [next in thread]