toolbox (and applethandle?) architecture rewamp

[Giulio Camuffo]

>
> * 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20100801/03492d68/attachment.htm