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

List:       kde-panel-devel
Subject:    Re: Extender api review.
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2008-07-27 15:36:08
Message-ID: 200807270936.08526.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sunday 27 July 2008, Rob Scheepmaker wrote:
> On Saturday 26 July 2008 23:45:32 Aaron J. Seigo wrote:
> > > > * createDetachableWidget (createExtenderItem?) should probably do the
> > > > actual creation and call a virtual protected method that only needs
> > > > to do the applet specific stuff (QGraphicsView
> > > > *initExtenderItem(name, config))
> > >
> > > Not a bad idea to split this up, but I don't get the QGraphicsView *...
> >
> > should have been QGraphicsItem * ... sorry.
>
> In this function the developer should however also be able to add qactions
> to the extender item. So the developer should have an ExtenderItem
> available. So what about:
>
> QGraphicsItem *initExtenderItem(ExtenderItem*)
>
> The developer can obtain name and config through the extender item.

sounds good; initExtenderItem should return void, though.

> > > > * setSupportDetachables -> this would be implied by having a Extender
> > > > associated with the Applet, and so could be completely internal. in
> > > > any case, adding a layout to an applet sounds dangerous. in fact, it
> > > > would seem to imply that it would be impossible to have self-hosted
> > > > content in an applet (e.g. a clock) *and* extenders. the Extender
> > > > should be completely external to the Applet, unless purposefully
> > > > embedded.
> > >
> > > So the applet itself could place an extenderitem in a layout in
> > > attachedEvent()? not a bad idea.. gives some more flexibility to
> > > applets.
> >
> > the default attachedEvent should do this for them i think (and that
> > should be documented in the apidox). this way the default behaviour is
> > maintained, but it is overrideable if desired.
>
> currently spacer are being inserted in the layout when hovering over an
> applet with an extenderitem. This is currently private, but when applets
> can choose not to use a layout, then insertSpacer(QPointF, QSizeF) and
> removeSpacer() should probably be virtual protected functions right? I
> don't like that very much, are there other ways to handle spacers?

hm.. perhaps we're not on exactly the same page here. what i'm saying is that 
ExtenderItems and Extender should *never* touch the Applet or its children 
directly. it is up to the Applet whether or not the Extender should be shown 
(and where). the Extender should simply be available to be shown, the 
ExtenderItems should exist inside the Extender and that's all.

we can provide some standardized mechanisms for showing the Extender from an 
applet, but these will need to be customizable. still, Extenders should never 
touch layouts or children of the Applet directly.

> > > The problem is, that event->scenePos works while within one view, but
> > > when you move to another view, event->scenePos still assumes you are
> > > still in that view. I think it is unavoidable.
> >
> > which event are you using this with, and with what object (QGraphicsView?
> > QGraphicsItem? some other QWidget class?)
>
> I use this in mouseMoveEvent and mouseReleaseEvent in the ExtenderItem
> (QGraphicsWidget).

ok, so scenePos should *always* be in scene coordinates, no matter what view 
is being used. are you sure you are using scenePos and note screenPos?

> > show its tweets, and i have two Twitter widgets with different accounts,
> > it dosn't make sense at all. similarly for clocks where there are
> > different time zones associated with each ... i just don't think this
> > heuristic fits well.
>
> Hmm, never thought of it that way... it kinda depends if the applet is
> normally unique (like notify or kuiserver), because for unique applets it
> makes sense.

nitpick: it's not the applet that's unique, but the data. (an important 
distinction, because all applets should be able to have multiple instances of 
themselves and still work; one more way the systray spec is broken)

> > > > * extenderContainment: i imagine this a Containment subclass internal
> > > > to Corona? why is it needed outside of Corona at all?
> > >
> > > Hmm, currently applet uses it to point it's toplevel view on that
> > > containment (applet::view needs an containment in it's constructor).
> > > But that could probably move to pimpl
> >
> > ah, i see. there's one containment per Extender then?
>
> Ehmn, no actually there's one extenderContainment currently and it has a
> gridlayout where extenders are put in.

ok, i suppose that works as well. and this is kept in (-x, -y) coords?

-- 
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


["signature.asc" (application/pgp-signature)]

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


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