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

List:       kde-panel-devel
Subject:    Re: Extender api review.
From:       Rob Scheepmaker <r.scheepmaker () student ! utwente ! nl>
Date:       2008-07-27 16:44:57
Message-ID: 200807271844.57562.r.scheepmaker () student ! utwente ! nl
[Download RAW message or body]

This is going to be quite some overhaul ;) Anyway, let's see if I understand you correctly. Talking 
about the same thing can be tricky... ;)

On Sunday 27 July 2008 17:36:08 Aaron J. Seigo wrote:
> > > > > * 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.

Ok, I get that... applets can implement the attached/detached events to do something custom with the 
extender items placement. How can we handle inserting spacers (when wanted of course) though? 
ExtenderItem handles the dragging around and should let the applet know it is hovering over the applet 
somehow.
And about making the extender a popup when in panel, should that be approached something like this:
the default implementation of the attached/detached events creates an new applet outside the view, a 
view aimed at it, and adds the extenderitems to that applet.... but only if Extender->isPopup() is set 
to true. When isPopup is changed, Extender invokes those events again to let the applet move the 
extender items from/to it's popup applet? This way, all presentation is handled and overridable by 
applet and we have sane default behavior. Maybe add a convenience function to Extender to quickly create 
an applet, a view on it, and place it in the extenderContainment...
hmm, wait, what if the attached event get's a pointer to the applet that it should populate (which could 
be 'this', or the popup applet sitting in the extenderContainment. Would make the code in that event a 
bit cleaner.
I'm still not entirely sure how to do this part elegantly.

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

Well, of course event->scenePos() returns a position in scene coordinates. However, when we have say one 
view hovering on top of the main plasma view which is aimed at, say, an applet which is at -400,-400 in 
scene coordinates. This view is at 800x800 screen coordinates and your main plasma desktop view is from 
0, 0, 1280x1024. event->scenePos() returns the desired coordinates while within your main view (if thats 
where you're dragging an extender item around). But when you move over the popup view, it doesn't 
suddenly return some negative scene coordinates... it assumes you wish to move the extender item behind 
that top level view. Which is not the desired behavior in our case. We always have to know which view is 
on top (which is probably the one the users interested in), so we can calculate the scene coordinates 
where we are actually interested in.

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

yes it is...
_______________________________________________
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]