Re: Tokamak 3 - The organization begins
On Wednesday 24 June 2009 23:26:18 Mario Fux wrote: Good morning Just a friendly reminder. The end of June/begin of July is near. Please add yourself to: http://techbase.kde.org/Projects/Plasma/Tokamak3 Aaron, Davide and Rob are already added. Greets from Germany. Tomorrow I'll go to Berlin for the Linuxtag. Mario I can't come, it's the beginning of the school year for the kids (little Clarisse joining her first year!) I'll also be away for most of July and August so if someone pops in (mail, IRC, Akademy,...) and wants to work on the Picture Frame, please encourage him! Things should be less frantic from September and will allow me a better involvement in KDE. Best regards, I would have enjoyed meeting you again Mario, Anne-Marie ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: BackgroundListModel::removeBackground must be a slot but it wasn't
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/883/ --- Review request for Plasma. Summary --- @backgroundlistmodel.cpp: connect(m_dirwatch, SIGNAL(deleted(QString)), this, SLOT(removeBackground(QString))); used as Slot but it wasn't defined as slot in .h file Diffs - /trunk/KDE/kdebase/workspace/plasma/wallpapers/image/backgroundlistmodel.h 986882 Diff: http://reviewboard.kde.org/r/883/diff Testing --- Thanks, Omer F. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
default plasma theme and fallback
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
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
Review Request: Fix Plasma clocks not being aware of timezone changes until next plasma-desktop restart
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/889/ --- Review request for Plasma. Summary --- The plasma timeengine reacts to timezone changes, but the timesource does not; this patch filles the gap. note the signal/slot/bool/updateslot dance is due to the fact that timesource could possibly get the update signal before KSystemTimeZone (and indeed it does) This addresses bugs not and reported?. https://bugs.kde.org/show_bug.cgi?id=not https://bugs.kde.org/show_bug.cgi?id=reported? Diffs - branches/KDE/4.3/kdebase/workspace/plasma/dataengines/time/timesource.h 987201 branches/KDE/4.3/kdebase/workspace/plasma/dataengines/time/timesource.cpp 987201 Diff: http://reviewboard.kde.org/r/889/diff Testing --- Basic testing done and it works Thanks, Jacopo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: BackgroundListModel::removeBackground must be a slot but it wasn't
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/883/#review1382 --- good catch; it can even go into protected slots, and this change needs to also be made to the two wallpapers that duplicate this code in plasma-addons. i'll take care of that .. thanks for patch :) - Aaron On 2009-06-25 02:38:01, Omer F. USTA wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/883/ --- (Updated 2009-06-25 02:38:01) Review request for Plasma. Summary --- @backgroundlistmodel.cpp: connect(m_dirwatch, SIGNAL(deleted(QString)), this, SLOT(removeBackground(QString))); used as Slot but it wasn't defined as slot in .h file Diffs - /trunk/KDE/kdebase/workspace/plasma/wallpapers/image/backgroundlistmodel.h 986882 Diff: http://reviewboard.kde.org/r/883/diff Testing --- Thanks, Omer F. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix Plasma clocks not being aware of timezone changes until next plasma-desktop restart
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/889/#review1383 --- how about just doing it from the engine itself, keeping this all in one place and avoiding synchronization issues? i'll upload a patch in a moment. - Aaron On 2009-06-25 13:54:58, Jacopo De Simoi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/889/ --- (Updated 2009-06-25 13:54:58) Review request for Plasma. Summary --- The plasma timeengine reacts to timezone changes, but the timesource does not; this patch filles the gap. note the signal/slot/bool/updateslot dance is due to the fact that timesource could possibly get the update signal before KSystemTimeZone (and indeed it does) This addresses bugs not and reported?. https://bugs.kde.org/show_bug.cgi?id=not https://bugs.kde.org/show_bug.cgi?id=reported? Diffs - branches/KDE/4.3/kdebase/workspace/plasma/dataengines/time/timesource.h 987201 branches/KDE/4.3/kdebase/workspace/plasma/dataengines/time/timesource.cpp 987201 Diff: http://reviewboard.kde.org/r/889/diff Testing --- Basic testing done and it works Thanks, Jacopo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Fix Plasma clocks not being aware of timezone changes until next plasma-desktop restart, alt patch
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/891/ --- Review request for Plasma. Summary --- Alternate patch to http://reviewboard.kde.org/r/889/ from 889: The plasma timeengine reacts to timezone changes, but the timesource does not; this patch filles the gap. the benefit of this patch is that the change is done in one place, no synchronization issues based on who gets a signal first. (i wonder if it needs to update all the timezones, even, or just the local one? not that updateAllSources is slow, so it shouldn't matter..) Diffs - trunk/KDE/kdebase/workspace/plasma/dataengines/time/timeengine.h 980060 trunk/KDE/kdebase/workspace/plasma/dataengines/time/timeengine.cpp 980060 trunk/KDE/kdebase/workspace/plasma/dataengines/time/timesource.h 980060 trunk/KDE/kdebase/workspace/plasma/dataengines/time/timesource.cpp 980060 Diff: http://reviewboard.kde.org/r/891/diff Testing --- Thanks, Aaron ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
air backgrounds - a little too translucent?
hi all ... is it just me or are the widget, dialog and panel backgrounds in Air just a little too translucent, making it hard to read text and see fine details? should it be made slightly more opaque? blurring would probably help a lot, but that isn't supported by all compositing setups and we simply can't (yet) do it properly on a QGrahpicsScene. -- 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: air backgrounds - a little too translucent?
A Friday 26 June 2009 01:05:16, Aaron J. Seigo escreveu: hi all ... is it just me or are the widget, dialog and panel backgrounds in Air just a little too translucent, making it hard to read text and see fine details? should it be made slightly more opaque? yeah a bit, its a trade off, general public see transparent as cool, but transparency comes with problems, low contrast being one of them, I guess we can make it less transparent, do remember the trade here less cool more usable... I know its a no brainier :) if every one agrees we can make it more opaque by 25%??? blurring would probably help a lot, but that isn't supported by all compositing setups and we simply can't (yet) do it properly on a QGrahpicsScene. -- Oxygen coordinator ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: air backgrounds - a little too translucent?
On Thursday 25 June 2009, Nuno Pinheiro wrote: A Friday 26 June 2009 01:05:16, Aaron J. Seigo escreveu: hi all ... is it just me or are the widget, dialog and panel backgrounds in Air just a little too translucent, making it hard to read text and see fine details? should it be made slightly more opaque? yeah a bit, its a trade off, general public see transparent as cool, but transparency comes with problems, low contrast being one of them, I guess we can make it less transparent, do remember the trade here less cool more usable... yes, that is indeed the trade-off; in this case at least it will still be somewhat translucent so it won't be completely uncool ;) if every one agrees we can make it more opaque by 25%??? +1 from me, but that was probably already evident :) -- 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: Review Request: Fix Plasma clocks not being aware of timezone changes until next plasma-desktop restart, alt patch
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/891/#review1384 --- Much better than mine! It would be excellent if we could trigger an update of all the containers attached but I just can't find the way to do it (is it possible?) Right now it waits for next trigger to update all clocks, which can be in fact be quite confusing, as the user can have to wait 1 minute to have it set. - Jacopo On 2009-06-25 16:34:27, Aaron Seigo wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/891/ --- (Updated 2009-06-25 16:34:27) Review request for Plasma. Summary --- Alternate patch to http://reviewboard.kde.org/r/889/ from 889: The plasma timeengine reacts to timezone changes, but the timesource does not; this patch filles the gap. the benefit of this patch is that the change is done in one place, no synchronization issues based on who gets a signal first. (i wonder if it needs to update all the timezones, even, or just the local one? not that updateAllSources is slow, so it shouldn't matter..) Diffs - trunk/KDE/kdebase/workspace/plasma/dataengines/time/timeengine.h 980060 trunk/KDE/kdebase/workspace/plasma/dataengines/time/timeengine.cpp 980060 trunk/KDE/kdebase/workspace/plasma/dataengines/time/timesource.h 980060 trunk/KDE/kdebase/workspace/plasma/dataengines/time/timesource.cpp 980060 Diff: http://reviewboard.kde.org/r/891/diff Testing --- Thanks, Aaron ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: air backgrounds - a little too translucent?
Nuno++ On Friday 26 June 2009 02:17:46 Nuno Pinheiro wrote: A Friday 26 June 2009 01:05:16, Aaron J. Seigo escreveu: hi all ... is it just me or are the widget, dialog and panel backgrounds in Air just a little too translucent, making it hard to read text and see fine details? should it be made slightly more opaque? yeah a bit, its a trade off, general public see transparent as cool, but transparency comes with problems, low contrast being one of them, I guess we can make it less transparent, do remember the trade here less cool more usable... I know its a no brainier :) if every one agrees we can make it more opaque by 25%??? blurring would probably help a lot, but that isn't supported by all compositing setups and we simply can't (yet) do it properly on a QGrahpicsScene. ___ 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
