There is a bug in the tool button and button components resulting in
layout breakage if one clears and sets the text property of the
component when not visible, see the attached screenshot.
I have tried to solve the issue without changing the existing
anchoring system, but without success. The only working solution
was to put the icon and the label item into Row item. That way I was
able to fix the bug and even get rid of the ugly explicit
non-declarative anchor assignments.
I have also removed the preferredWidth property of the label item,
that one always evaluated to paintedWidth, anyway.
REVIEW: 107813
Scrollbars can only be anchored to the associated flickable if it is
their parent or they share the same parent. The plausibility check
for this condition had a bug exluding also the latter case. That's fixed
now.
Dialogs are always plasma-themed, and if possible are inline.
only if there is not enough space (like in a panel) they get moved in a separate window
this removes quite some c++ usage and hopefully solves some layouting problems in dialogs
make scrollbar anchor to root, so the binding doesn't break at the moment of creation when they are parentless for a moment
also, clip the flickable, not the scrollares
Any qml object that will be calles as an enum value, like Planar {} Application{}
etc will make enums inaccessible.
maintain them global, for retrocompatibility, but register them also under plasmoid
This adds the necessary bits, actions handling, showing / hiding of
toolbox and a hooks for config interface and add widgets.
The interesting bits:
Toolbox separate on the scene
For declarative containments, we add a declarativewidget on top of the
view which loads the "org.kde.toolbox" package. The toolbox can differ
per platform, layout of toolbox and containment can not "leak" into each
other.
ToolBox import
The most important and interesting bit is the list of actions the
ToolBox exposes, it's collected from corona, containment. The latter is
actually problematic, since we don't get access to the actions
internally provided by Containment
(ContainmentPrivate::addDefaultActions).
Containment::setToolBox(AbstractToolBox) being protected, we cannot
register our declarative ToolBoxProxy implementation to the containment,
so we have to wire up settings and addwidgets separately. Sorting of the
actions is "random", and expected to be done by the QML toolbox
implementation, based on objectName strings.
REVIEW:107232
