This is an automatically generated e-mail. To reply, visit: http://svn.reviewb= oard.kde.org/r/5495/

On September 30th, 2010, 1:10 p.m., Marco M= artin wrote:

still not=
 completely happy having to keep a separate xml dom, however, there are pro=
bably not going to be other ways for a while and the implementation seems p=
retty good, so modulo those little things it could go in

If QXmlStre=
amReader::parse() would be virtual, we could create a stream reader, that r=
eplaces this on the fly. But for now I see no other way of doing this. The =
only idea that could work is: Create a QIODevice that reads from another QI=
ODevice with help of QXmlStreamReader and writes the data again with QXmlSt=
reamWriter... But this would be much more code and I don't think that t=
his would be faster at all.

On September 30th, 2010, 1:10 p.m., Marco M= artin wrote:
= = =
/trunk/KDE/kdelib= s/plasma/svg.cpp (Diff revision 1)
bool SharedSvgRenderer::load(const QByteArray &contents, const =
QString &styleSheet)
103
        QDomElement <=
span class=3D"n">colorScheme =3D svg.createElement=
("style"=
);
a check e=
lements with the same id aren't existing should be done

/trunk/KDE/kdelib= s/plasma/svg.cpp (Diff revision 1)
	bool SharedSvgRenderer::load(const QByteArray &contents, const = QString &styleSheet)
		103	QDomElement <= span class=3D"n">colorScheme =3D svg.createElement= ("style"= );

You are right. But this would add more clutter. Maybe it is better t=
o just leave the id as is. So no hint-uses-color-scheme but only current-co=
lor-scheme.

On September 30th, 2010, 1:10 p.m., Marco M= artin wrote:

= = =

/trunk/KDE/kdelib= s/plasma/svg.cpp (Diff revision 1)
class SvgPrivate
385	applyColors =3D elementRect("hin= t-apply-color-scheme").isValid();	437	if (elementRect("hint-apply-color-scheme").isValid()<= span class=3D"hl">) {

so the co=
loring of the pixmap is still kept as retrocompatibility?

I don't want to break existing themes ;)

On September 30th, 2010, 1:10 p.m., Marco M= artin wrote:
= = =
/trunk/KDE/kdelib= s/plasma/theme.cpp (Diff revision 1)
void ThemePrivate::colorsChanged()
320
        if(stylesheet.isEmpty()) {
i wonder =
how much is the benefit vs cost of caching this?

/trunk/KDE/kdelib= s/plasma/theme.cpp (Diff revision 1)
void ThemePrivate::colorsChanged()
		320	if(stylesheet.isEmpty()) {

Both is quite low. ;) But as this stylesheet has to be generated for=
 every Plasma::Svg object, which is 259 times for a start of plasma with th=
e default setup + analog clock + calculator, it feels wrong to regenerate i=
t that often.

On September 30th, 2010, 1:10 p.m., Marco M= artin wrote:
= = =
/trunk/KDE/kdelib= s/plasma/theme.cpp (Diff revision 1)
KSharedConfigPtr Theme::colorScheme() const
785
        case ButtonHoverColor:
the butto=
n widget should be modified if this will start to be used

/trunk/KDE/kdelib= s/plasma/theme.cpp (Diff revision 1)
KSharedConfigPtr Theme::colorScheme() const
		785	case ButtonHoverColor:

For what reason?

- Manuel

On September 30th, 2010, 11:41 a.m., Manuel Mommertz wrote:

Review request for Plasma.

By Manuel Mommertz.

Updated 2010-09-30 11:41:09

Descripti= on

With this patch applied SVGs can put a style-element with id=
 'current-system-colors' in it, which gets replaced by a style with=
 the current systemcolors. This allows SVGs to use colors like background c=
olor and text color from the system palette. Giving themes much more possib=
ilitys then just coloring the resulting pixmap.

Testing <= /h1>

Changing theme, changing colorscheme

Diffs=

/trunk/KDE/kdelibs/plasma/theme.h (1180314= )
/trunk/KDE/kdelibs/plasma/theme.cpp (11803= 14)
/trunk/KDE/kdelibs/plasma/svg.cpp (1180314= )

View Diff