> > * ControlElement: a class that implements the idea of a control element. > each subclass would implement something like "launch configuration" or > "rotate". subclasses would be tagged with a semantic enum much as we have > in > AbstractToolBox::ToolType. ControlElement would accept input events. > > * AbstractHandle: a class that would paint and manage a handle along with > zero or more ControlElements > > then ... an AbstractHandle (or a subclass of it, really) would be assigned > a > QGraphicsWidget(/Object?). when being shown, it would check to see if the > controlElement property exists on the object. if it does, it would request > those ControlElements and use them to figure out which ones to show (e.g. > it > might avoid geometry changing elements) and pass on input events to those > elements as appropriate. >
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? > Giulio: since you are the one most affected by the "usable with any > QGraphicsWidget/Object" issue, would you be interested in taking on the > design of ControlElement? > Tomorrow i'll go away for something like three weeks, so I won't be able to do anything until the end of august, but after that i'm certainly interested in doing this. Cheers, Giulio
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
