the color properties are remotely useful only when used from QML
and risk to explode in number in the future,
it's not a good thing for a public c++ api.
Also, they will become kinda deprecated as in largely replaced by
the ColorRole api. Too late to remove those properties completely,
but still last days to move them at least out of c++ api.
(and in qml they could be removed in the future in a 2.1 version
of the import while still being present in 2.0 if needed)
This moves the color properties is a theme subclass available only from QML
REVIEW:118972
it's an import in core, and advertises itself as an "attached property"
with this we can:
say that all its chidren are of a certain context, like "button" or
"complementary"
then anywhere there will be available an attached property, as ColorScope,
so like:
PlasmaCore.ColorScope {
group: PlasmaCore.Theme.Complementary
PlasmaComponents.Label {
text: "foo"
color: ColorScope.textColor
}
}
for areas intended to have independent background and text color than
all the rest, like the Logout dialog
if Colors:Complementary is not present in the theme, it falls back to
normal colors
The used corona is either the containment's parent or, in case the parent
is an applet, it's containment's corona. With this change we ensure the
proper corona is always found.
This change requires screenContainment to be able to walk through the
object tree in case it's not a containment directly managed by it.
BUG: 334500
experiment in dynamic repacement of Text and Background
colors, in order to be able to generate icons of different colors
based on where they are (for instance if the normal background
is dark and the button background is light
at the moment supported an option to invert colors, one
to use the "highlight" color (if we want colored icons
on mouse over)
It doesn't make sense to try to give hints at what it will be given that
we don't know.
For example, see how we're defining ::numScreens as 1 on the other method
as well.
newly created containments may have some default entries like plugin
or formfactor written in the config group, but not in keyList()
they have to be explicitly removed because wouldn't be removed in
deleteGroup
BUG:335792
since it is now possible to have different svg/framesvg with
different themes, s_sharedFrames must be indexed by theme first
what it's really the identifying thing is ThemePrivate, so it's indexed by that
this fixes a crash that occurs the second thime the theme gets changed
BUG:335472
now is actually possible to obtain a startup with zero svg renderers
* svg::isValid will create a renderer only if really nevessary
* the rects cache is ensured to be written on disk
* fixed the check on the theme metadata age
* rect cache is shared between all applications
Many classes from QtGui are specified in the header files, this alone is
enough reason to make it a public dependency. (QGuiApplication, QFont,
QPixmap are some examples).
This also pulls QtCore (e.g. QString, QRect, QUrl), which also is, of
course.
CCMAIL: plasma-devel@kde.org
