Re: default plasma theme and fallback
On Friday 26 June 2009, Aaron J. Seigo wrote: On Thursday 25 June 2009, Marco Martin wrote: b)mantain oxygen as default and just load air instead of oxygen at kde startup and how will that work for krunner? kwin? put this in every application that should be using the global setting? that doesn't seem like a good idea. it also means we have to keep Oxygen up to date with all items we create (otherwise there will be no fallback). c)have a fallbackTo=foo entry in themes desktop files making possible for themes to fallback to a desired theme (maybe kinda overkill and what happens when a 3rd party theme falls back to another 3rd party theme? or what happens when a theme falls back to an incomplete theme?) this probably makes sense, but could be combined with: d) in Plasma::Theme, make the fallback separate from the default theme. this way Oxygen could be the fallback, Air the default. we could also cover our bases and have it a cascading list of fallbacks, with Oxygen as the first fallback and Air the last so if an element appears in Air (our default) that doesn't appear in Oxygen, then we're still good. this will also preserve things for widgets that put their widgets in default/ (aka Air) see attached patch. looks good, i wonder if we could limit this to themes shipped in runtime, specifying one looks quite overkill (would introduce the concept of dependency between themes, that could be bad or could be good, just to be tough carefully:) anyways to me looks good and is a thing to be backported, at least part of it soo, if we just make the default as air every time the default theme will change the same pain will repeat, if we keep oxygen as the fallback theme we are condemned to keep it complete for ever (that sounds sensible anyways) but will be less painful for old themes even if someday another new default theme will be provided... personally i think that themes that rely on a certain subset of elements in the fallback theme remaining consistent are operating on a delusion. in future, they can use FallbackTheme= if that's what they assume. and we need a techbase article on this :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: default plasma theme and fallback
Just another thing. The problem mainly arose from the fact that we use the /name/ of the directory as an identifier which decides whether the theme is the default one. So, we would still have this problem after this patch (which still gets +1 from me even with this problem). How to make a theme that is based on Air? If you put FallbackTheme=default - you have done nothing. If the default theme changes (again), it will lead to breakage yet again. With icons, we use symbolic link default - oxygen (or default.kde4 - oxygen). What about using something similar here? Cheerio ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: default plasma theme and fallback
see attached patch. +1 personally i think that themes that rely on a certain subset of elements in the fallback theme remaining consistent are operating on a delusion. It is not just that. The biggest problem I've had was that I had (per your suggestion) trimmed down Lancelot's themes to share as much elements as possible, so to reduce the number of SVGZs. Since most shipping-with-plasma themes are dark, and the default one was too, I removed all the elements from the other dark themes relying on the fact that those from the oxygen will be used. The renaming default-oxygen and air-default screwed all that up. in future, they can use FallbackTheme= if that's what they assume. and we need a techbase article on this :) This would be a great solution for my case ;) As for limiting the fallbacks to shipping-with-plasma themes, I don't really thing it is necessary, but it should be mentioned in the techbase article that we provide no mechanism of ensuring that the fallback theme exists, and that only the s-w-p ones should be used. Cheerio. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: default plasma theme and fallback
On Friday 26 June 2009, Ivan Čukić wrote: With icons, we use symbolic link default - oxygen (or default.kde4 - oxygen). What about using something similar here? sure, a symlink would work fine here. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: default plasma theme and fallback
A Thursday 25 June 2009 13:21:22, Marco Martin escreveu: My vote goes for b) most themes around are very incomplete. Hi all, as i was talking today with Ivan on irc, there could be a problem in having air as default theme now, since is the fallback theme too, many existing (and incomplete) themes that relied on many elements to be the fallback ones now have the air elements, a thing that could quite break their look. there are few possible solutions: a) not caring, be a bad boys and just require the themes to be complete (ok, not a solution this one :p) b)mantain oxygen as default and just load air instead of oxygen at kde startup c)have a fallbackTo=foo entry in themes desktop files making possible for themes to fallback to a desired theme (maybe kinda overkill and what happens when a 3rd party theme falls back to another 3rd party theme? or what happens when a theme falls back to an incomplete theme?) soo, if we just make the default as air every time the default theme will change the same pain will repeat, if we keep oxygen as the fallback theme we are condemned to keep it complete for ever (that sounds sensible anyways) but will be less painful for old themes even if someday another new default theme will be provided... Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Oxygen coordinator ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: default plasma theme and fallback
2009/6/25 Nuno Pinheiro n...@oxygen-icons.org A Thursday 25 June 2009 13:21:22, Marco Martin escreveu: My vote goes for b) most themes around are very incomplete. Hi all, as i was talking today with Ivan on irc, there could be a problem in having air as default theme now, since is the fallback theme too, many existing (and incomplete) themes that relied on many elements to be the fallback ones now have the air elements, a thing that could quite break their look. there are few possible solutions: a) not caring, be a bad boys and just require the themes to be complete (ok, not a solution this one :p) b)mantain oxygen as default and just load air instead of oxygen at kde startup c)have a fallbackTo=foo entry in themes desktop files making possible for themes to fallback to a desired theme (maybe kinda overkill and what happens when a 3rd party theme falls back to another 3rd party theme? or what happens when a theme falls back to an incomplete theme?) soo, if we just make the default as air every time the default theme will change the same pain will repeat, if we keep oxygen as the fallback theme we are condemned to keep it complete for ever (that sounds sensible anyways) but will be less painful for old themes even if someday another new default theme will be provided... Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Oxygen coordinator ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel me is for b) too. :) -- Alessandro Diaferia KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: default plasma theme and fallback
I think c) is the most interesting, as it would let people to rely on any
theme they want to (and who'd make a third party theme relying on another
third party theme would have conscience it's not KDE's and, as so, could be
unstable and s/he'd have to be sure the theme is ok time to time), but b) is
surely the safest option.
So, anyway, I go with c) for more options for themes.
Cheers,
--
JJ (|´:¬{)»
-
Eu sou a ressurreição e a vida. Quem crê em mim, ainda que morra, viverá; e
todo o que vive e crê em mim não morrerá, eternamente. Crês isto?
O Senhor, Jesus Cristo - Jo.11:25-26
-
2009/6/25 Nuno Pinheiro n...@oxygen-icons.org
A Thursday 25 June 2009 13:21:22, Marco Martin escreveu:
My vote goes for b)
most themes around are very incomplete.
Hi all,
as i was talking today with Ivan on irc, there could be a problem in
having
air as default theme now, since is the fallback theme too, many existing
(and incomplete) themes that relied on many elements to be the fallback
ones now have the air elements, a thing that could quite break their
look.
there are few possible solutions:
a) not caring, be a bad boys and just require the themes to be complete
(ok, not a solution this one :p)
b)mantain oxygen as default and just load air instead of oxygen at kde
startup
c)have a fallbackTo=foo entry in themes desktop files making possible for
themes to fallback to a desired theme (maybe kinda overkill and what
happens when a 3rd party theme falls back to another 3rd party theme? or
what happens when a theme falls back to an incomplete theme?)
soo, if we just make the default as air every time the default theme will
change the same pain will repeat, if we keep oxygen as the fallback
theme
we are condemned to keep it complete for ever (that sounds sensible
anyways) but will be less painful for old themes even if someday another
new default theme will be provided...
Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
--
Oxygen coordinator
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: default plasma theme and fallback
b) and c) do not rule out each other, indeed: we could have c) as an optional entry which defaults to oxygen which would be the default fallback option. To me this seems the sanest option, since many themes around, being incomplete as Nuno said, rely on the fact that they are fallbacked by oxygen. By doing this we would at the same time easily allow people to write new themes falling back to air or future predefined themes. On Thursday 25 June 2009 16:39:53 Nuno Pinheiro wrote: A Thursday 25 June 2009 13:21:22, Marco Martin escreveu: My vote goes for b) most themes around are very incomplete. Hi all, as i was talking today with Ivan on irc, there could be a problem in having air as default theme now, since is the fallback theme too, many existing (and incomplete) themes that relied on many elements to be the fallback ones now have the air elements, a thing that could quite break their look. there are few possible solutions: a) not caring, be a bad boys and just require the themes to be complete (ok, not a solution this one :p) b)mantain oxygen as default and just load air instead of oxygen at kde startup c)have a fallbackTo=foo entry in themes desktop files making possible for themes to fallback to a desired theme (maybe kinda overkill and what happens when a 3rd party theme falls back to another 3rd party theme? or what happens when a theme falls back to an incomplete theme?) soo, if we just make the default as air every time the default theme will change the same pain will repeat, if we keep oxygen as the fallback theme we are condemned to keep it complete for ever (that sounds sensible anyways) but will be less painful for old themes even if someday another new default theme will be provided... Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: default plasma theme and fallback
On Thu, Jun 25, 2009 at 14:21, Marco Martinnotm...@gmail.com wrote: there are few possible solutions: a) not caring, be a bad boys and just require the themes to be complete (ok, not a solution this one :p) b)mantain oxygen as default and just load air instead of oxygen at kde startup c)have a fallbackTo=foo entry in themes desktop files making possible for themes to fallback to a desired theme (maybe kinda overkill and what happens when a 3rd party theme falls back to another 3rd party theme? or what happens when a theme falls back to an incomplete theme?) Hello everyone, how about a fourth solution? a') Make air the default theme and also let new, incomplete themes fallback on it. But also offer a little script, that allows maintainers of current themes to draw in all missing parts from oxygen, thereby help them make their themes complete. Basically a static, standalone version of the dynamic, internal fallback mechanism. I guess this fourth solution is more work than the other three, but depending on what's in store for theme designers once plasmate rolls around, it might be work, that will be done anyway. And as practical as solution b indeed is, it also appears like a hack to me. michael ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: default plasma theme and fallback
On Thursday 25 June 2009, Marco Martin wrote:
b)mantain oxygen as default and just load air instead of oxygen at kde
startup
and how will that work for krunner? kwin? put this in every application that
should be using the global setting? that doesn't seem like a good idea.
it also means we have to keep Oxygen up to date with all items we create
(otherwise there will be no fallback).
c)have a fallbackTo=foo entry in themes desktop files making possible for
themes to fallback to a desired theme (maybe kinda overkill and what
happens when a 3rd party theme falls back to another 3rd party theme? or
what happens when a theme falls back to an incomplete theme?)
this probably makes sense, but could be combined with:
d) in Plasma::Theme, make the fallback separate from the default theme. this
way Oxygen could be the fallback, Air the default. we could also cover our
bases and have it a cascading list of fallbacks, with Oxygen as the first
fallback and Air the last so if an element appears in Air (our default) that
doesn't appear in Oxygen, then we're still good. this will also preserve
things for widgets that put their widgets in default/ (aka Air)
see attached patch.
soo, if we just make the default as air every time the default theme will
change the same pain will repeat, if we keep oxygen as the fallback theme
we are condemned to keep it complete for ever (that sounds sensible
anyways) but will be less painful for old themes even if someday another
new default theme will be provided...
personally i think that themes that rely on a certain subset of elements in
the fallback theme remaining consistent are operating on a delusion.
in future, they can use FallbackTheme= if that's what they assume. and we need
a techbase article on this :)
--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
KDE core developer sponsored by Qt Software
Index: theme.cpp
===
--- theme.cpp (revision 984110)
+++ theme.cpp (working copy)
@@ -136,6 +136,7 @@
Theme *q;
QString themeName;
+QListQString fallbackThemes;
KSharedConfigPtr colors;
KColorScheme colorScheme;
KColorScheme buttonColorScheme;
@@ -403,7 +404,21 @@
cg = KConfigGroup(metadata, Settings);
useNativeWidgetStyle = cg.readEntry(UseNativeWidgetStyle, false);
+QString fallback = cg.readEntry(FallbackTheme, QString());
+fallbackThemes.clear();
+while (!fallback.isEmpty()) {
+fallbackThemes.append(fallback);
+
+QString metadataPath(KStandardDirs::locate(data, desktoptheme/ + theme + /metadata.desktop));
+KConfig metadata(metadataPath);
+cg = KConfigGroup(metadata, Settings);
+fallback = cg.readEntry(FallbackTheme, QString());
+//TODO: grab the fallback's wallpaper defaults?
+}
+fallbackThemes.append(oxygen);
+fallbackThemes.append(ThemePrivate::defaultTheme);
+
QObject::disconnect(KGlobalSettings::self(), SIGNAL(kdisplayPaletteChanged()),
q, SLOT(colorsChanged()));
@@ -465,16 +480,20 @@
// try for an uncompressed svg file
path = d-findInTheme(name + .svg, d-themeName);
-if (path.isEmpty() d-themeName != ThemePrivate::defaultTheme) {
-// try a compressed svg file in the default theme
-path = d-findInTheme(name + .svgz, ThemePrivate::defaultTheme);
+// search in fallback themes if necessary
+for (int i = 0; path.isEmpty() i d-fallbackThemes.count(); ++i) {
+if (d-themeName == d-fallbackThemes[i]) {
+continue;
+}
+// try a compressed svg file in the fallback theme
+path = d-findInTheme(name + .svgz, d-fallbackThemes[i]);
+
if (path.isEmpty()) {
-// try an uncompressed svg file in the default theme
-path = d-findInTheme(name + .svg, ThemePrivate::defaultTheme);
+// try an uncompressed svg file in the fallback theme
+path = d-findInTheme(name + .svg, d-fallbackThemes[i]);
}
}
-
}
if (path.isEmpty()) {
signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
