Extender api review, round 2

Aaron J. Seigo aseigo at kde.org
Wed Jul 30 21:18:06 CEST 2008


On Wednesday 30 July 2008, Rob Scheepmaker wrote:
> Thanks for the suggestions :)
>
> On Wednesday 30 July 2008 19:26:26 Kevin Ottens wrote:
> > Le Tuesday 29 July 2008, Rob Scheepmaker a écrit :
> >
> > So this property probably needs a rename altogether... I'll be cheating
> > for a minute and look at the apidox of the relevant methods: "takes care
> > of placing itself", "out of ordinary view" (odd term btw "ordinary
> > view"). I guess it's used to change the state of the extender if it's
> > inside the applet, or above the view in its own toplevel widget (or
> > something like this... somehow referring to the "PopupApplet" class).
>
> Actually it moves the extender to somewhere in the topleft quadrant of the
> scene (negative coordinates). However, I'm actually thinking now that
> PopupApplet should handle this.

that probably makes sense; or rather, Corona shold support a way to do this 
easily, which is used by things that would benefit from it such as PopupApplet.

> > >             void setWidget(QGraphicsWidget *widget);
> > >             QGraphicsWidget *widget() const;
> >
> > Why QGraphicsWidget only? Why not it's parent class QGraphicsItem?
>
> Hmm, that's actually a very good point. Currently I actually check the size
> hints of the widget though. to set sane size hints for the extender item.
> maybe I should try to cast the widget to QGW, use the sizehints in that
> case, and assume a minimumsize of the current size if its a QGI? Supporting
> QGI would be more flexible...

if it's workable, that'd be great. note that there is a bool 
QGraphicsItem::isWidget() that makes detecting items-that-are-widgets 
easy/faster.

> > >             void setExtender(Extender *extender);
> > >             Extender *extender() const;
> >
> > Ah, now I'm confused... How is that different from the mandatory extender
> > provided in the ctor?
>
> This way the item can be moved between extenders... I'm not entirely sure
> if there are cases where that is useful though.

does that happen when an item is moved between applets? or is a whole new 
ExtenderItem created (would seem a bit wasteful?)

> I guess it's only needed if
> we're going to support multiple extenders/applet... which I think we'll
> eventually want.

what are the use cases for this? i've been trying to think of them, and i'm 
really not doing a great job of it ;)

> > >         public Q_SLOTS:
> > >             void destroy();
> >
> > Hmmm, how is that different from "delete item"? Is it "only" to get the
> > convenience of doing it via a slot? Or it's trying to workaround some
> > limitation in QGV?
>
> No, the actual reason is that destroy also removes the item's configuration
> data. That's not something that you want to happen when you quit plasma ;).
> But maybe I should rename this function to delete?

no; it's not deleting it, it's destroying it. deleting has a meaning in C++ 
already. destroy is also what we use in other classes in Plasma such as 
Applet, so the concept should be kept consistent.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20080730/7e96d598/attachment-0001.pgp 


More information about the Plasma-devel mailing list