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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
