toolbox (and applethandle?) architecture rewamp

[Aaron J. Seigo]

On August 9, 2010, Giulio Camuffo wrote:
> In data domenica 01 agosto 2010 23:11:36, Aaron J. Seigo ha scritto:
> > On August 1, 2010, Giulio Camuffo wrote:
> > > Interesting approach, i like it.
> > > There's just a thing i'm not sure i understood well. You said to check
> > > if there is the controlElement property. Do you mean having a property
> > > for each control element the widget accepts?
> > 
> > no, something like:
> > 
> > Q_PROPERTY(QList<Plasma::ControlElement>
> > 
> >  controlElements READ controlElements)
> > 
> > the elements themselves would know how to deal with the input events and
> > 
> >  either modify the widget or relay the information on to the widget.
> 
> ok, back home for 2-3 days, there are still two things to deal with:
> 1) now when the AppletHandle moves an Applet it emits the applet's signal
> appletTransformedByUser. It can emit it because it is a friend of Applet,
> but now we need to find an other way to allow every subclass of
> AbstractHandle to emit it.

under the design i suggested, this wouldn't be necessary because the control
element would come from, and be owned by, the Applet. the handle wouldn't
need to do anything. the Applet could connect a signal from the control
 element it creates to its appletTransformedByUser signal.
 
> 2) What should the ControlElement class be? A QGraphicsObject or maybe a
> simple QObject with some mousePress() method called by the handle when it
> wants to pass the input to the right element?

a simple QObject should do. that way the handle can decide how to present
 them.

as for the event model .. the simple approach is just to pass on the mouse
events. it may be more interesting to allow elements that are just
"activatable" (such as the configuration button, which only cares that its
been activated so it can launch a config dialog) as well as elements that
 need pointer tracking (so ... a start point, movement, end).

i think it might make the most sense to start this off as an internal,
non-exported class (so we can change it more easily in the meantime) and
port all of the existing actions to this mechanism. we can then see exactly
 what kind of interaction information we want to pass on to them.

what do you think?

-- 
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 Qt Development Frameworks

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