toolbox (and applethandle?) architecture rewamp

[Aaron J. Seigo]

On July 31, 2010, Giulio Camuffo wrote:
> 1) We could modify the handle constructor to let it pass a QGraphicsWidget
> instead of an Applet and then check things like
> hasConfigurationInterface() using the property() method. Still it would

hm, too many assumptions and too many code paths.

stepping back from this,
 we want:

* different applet handle implementations that get replaced at run time by
the shell, so they are sharable between all items that should have a handle
 (i'm not sure they need to be pluggable, even; just run-time definable)

* different kinds of objects that the handle can be used in conjunction
with. the lowest common denominator is that it must be a QGraphicsWidget (or
 maybe a QGraphicsObject?)

so ... how about this as an idea straight off the top of my head, which is
 all about stealing the ideas from the Qt elements idea:

* 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.

this approach would allow for everything that has been requested in this
thread as far as i can see. it's also more complex and would require some
 class design work.

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?

Marco could continue to concentrate on an AbstractHandle class that
 way.

thoughts?

-- 
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/20100731/3fa5f594/attachment.sig