[Kde-perl] no addItem in Layouts?

[Thomas Fjellstrom]

On January 4, 2004 05:03 pm, Germain Garand wrote:
> Le Dimanche 04 Janvier 2004 06:20, Thomas Fjellstrom a écrit :
> > On January 3, 2004 09:29 pm, Ashley Winters wrote:
> > > > I tried:
> > > > my $spacer = Qt::SpacerItem(1, 1, &Qt::SizePolicy::Maximum,
> > > > &Qt::SizePolicy::Maximum);
> > > > $ok_box->layout()->addItem($spacer);
> > >
> > > $ok_box->addItem($spacer);
> >
> > huh? Why was that done? the Qt docs mention nothing of a addItem method
> > in the HBox/VBox widgets, yet is in the base Layout classes... Also
> > didn't see any mention of it in the PerlQt docs ;)
>
> there seem to be some confusion here... since you did not tell what's
> inside $ok_box, it's hard to know what you mean.
>
> If $ok_box is holding a Qt::Widget and not a Qt::Layout of some kind, then
> your code is correct and you've most likely got a polymorphism problem.

sory ;) $ok_box is a Qt::HBox. the pointer returned from ->layout seems to 
just be a QLayout  "I Think".

I remember having this problem with other things, the class wasn't the right 
class, that is the base class.

(look down, I figured it out ;))

> PerlQt is not polymorphic strictly speaking, nor is Smoke. When you call
> addItem on an object that claims to be a Qt::Layout, then it will call
> Qt::Layout::addItem
> Since Qt::Layout::addItem is a pure virtual, that won't work.
>
> Ordinarily, when PerlQt already knows about an object, it will pre-cast it
> to the most accurate class, so the object you get will be e.g a
> Qt::GridLayout. And that will work fine.
>
> But if you get a pointer via Qt to an object that has never been seen
> before on the perl side,
> it will probably be of the lowest common denominator class (here: a
> Qt::Layout)

Ohhh... Now I see.

> This problem is alleviated in the upcoming PerlQt by making use of Qt's
> various RTTI mechanisms to pre-cast unknown objects, thanks to Richard
> Dale's work on this.
>
> But in PerlQt < 3.009, if the object has not the most accurate class, you
> need to
>
> CAST( $foo->layout(), "Qt::<the derived layout>")->addItem($bar)
>
> Beware that CAST is reblessing the object to the given class, so it's
> "sticky". Also: no checkings are performed.
>
> This is foreward compatible of course.

Ok... Messy, but I see why its currently nessesary.

> > > > I also have another question.. is it possible to access the
> > > > attributes of your
> > > > own subclasses, from outside those objects, besides through making
> > > > your own
> > > > accessor methods?
> > >
> > > If you want to break encapsulation, go for it; it's one of the joys of
> > > Perl. The attributes aren't hidden: $your_object->{foo} accesses the
> > > 'foo' attribute declared in $your_object's class.
> >
> > Very nice :) though, now that I think about it.. Its not that "brilliant"
> > of an idea... I just hope I never change the name of any accessed
> > attributes ;)
>
> did you intend that to be tactful? :-}

Which? accessing attributes? ;) no, not really...

> If you want to just _get_ the attributes, keeping the compile-time
> checking, then you can write
> object->the_attribute->foo()

ok.. Why didn't I ever try that? Maybe you can explain _that_ to me ;)

> if you want full get/set access without getters/setters methods, and
> including the "shoot-yourself-in-the-foot" option, then you must indeed use
> the object's hash and suffer the traditional lack of checking on perl
> objects. Isn't that a fair tradeoff?

Very.

With this knowlege I may be able to clean up some of my Pqt code ;)

So when will "the latest version" of PerlQt be available (when its ready? ;))

> G.
>
> _______________________________________________
> Kde-perl mailing list
> Kde-perl at kde.org
> https://mail.kde.org/mailman/listinfo/kde-perl

-- 
Thomas Fjellstrom
tfjellstrom at strangesoft.net
http://strangesoft.net