---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/4796/#review6748
---
> I understand it in principle, but would like to know which specific
On July 30, 2010, Marco Martin wrote:
> SVN commit 1157180 by mart:
>
> support load by plugin from AbstractToolBox
it's missing a static KPluginInfo::List listToolBoxInfo(const QString
&parentApp = QString()) method, to follow the pattern of the others.
> could be the case to add it to PluginL
SVN commit 1157190 by mart:
new property:
preferredToolBoxPlugin(Containment::Type)
used to decide what toolbox plugin dynamically load, only corona
implementations can decide this.
api review anyone? ;)
CCMAIL:plasma-devel@kde.org
M +12 -0 corona.cpp
M +17 -0 corona.h
--- tr
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/4796/#review6747
---
I understand it in principle, but would like to know which specific ca
SVN commit 1157180 by mart:
support load by plugin from AbstractToolBox
what stinks is the both support direct creation -and- plugin loading,
but has to be BC
could be the case to add it to PluginLoader? don't see big use cases
CCMAIL:plasma-devel@kde.org
M +1 -0 CMakeLists.txt
M +3
On July 29, 2010, Will Stephenson wrote:
> I think it would be simpler for wallpaper plugin writers if they
> did not have to consider this case.
it would be nicer, but most wallpapers only have one mode (so for those ones
it's a non-issue) and automating it would mean having a way to mark which
---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/4796/
---
Review request for Plasma.
Summary
---
Currently we always display one brig
