Review Request: custom toolbox support

[Aaron Seigo]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1861/#review2669
-----------------------------------------------------------


the internal toolbox should just move to the properties system as well, and then we don't need two pointers, two code paths, etc.

the only trick will be hooking up "addToolBoxAction" properly. options are: we export a basic ToolBox class (which probably makes sense), do something like use invokeMethod (ugh!) or keep the multiple code paths.

i don't like how this new method makes some things (e.g. addToolBoxAction) not work as expected .. so .. maybe it's time for a really simple ToolBox QGraphicsWidget? :)

perhaps a setToolBoxWidget(Plasma::ToolBox *) and a corresponding toolBoxWidget()? toolBoxItem would then be deprecated and return the widget (which would get demoted to a QGraphicsItem * in the process, but whatever :)

thoughts?

- Aaron


On 2009-10-16 14:01:57, Marco Martin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1861/
> -----------------------------------------------------------
> 
> (Updated 2009-10-16 14:01:57)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> -------
> 
> this adds a setToolboxItem function.
> it makes possible for the openToolBox() function to work if the containment totally manages the toolbox by itself.
> it uses a "showing" property that custom toolboxes should implement to show/hide the toolbox
> 
> 
> Diffs
> -----
> 
>   /trunk/KDE/kdelibs/plasma/private/containment_p.h 1036057 
>   /trunk/KDE/kdelibs/plasma/containment.h 1036057 
>   /trunk/KDE/kdelibs/plasma/containment.cpp 1036057 
> 
> Diff: http://reviewboard.kde.org/r/1861/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Marco
> 
>