> On June 22, 2013, 10:58 a.m., Thomas Lübking wrote: > > kdeui/util/kglobalsettings.cpp, line 308 > > <http://git.reviewboard.kde.org/r/111171/diff/1/?file=165092#file165092line308> > > > > These are the colors for the window titlbar (with ambiguous function > > names, though), the default for activeTitleColor used to be #30AEE8 - that > > is blue! > > > > Now you want to return the active window background (ie. usually gray) > > - iow: enforce the color alignment that once caused the former KWin > > maintainer to for the oxygen deco into the new default ozone? > > > > I mean, decorations can still keep their internal color settings (what > > was somehow required because the titlebar color was initially happily > > removed from the color kcm - instead one could define the button color in > > listviews...), but the implication of this change is that the titlbar can > > no more be individually configured and *has* to align to the window > > background. > > > > -> The RR should clearly state that central color configuration for > > titlebars will ultimately be unsupported. > > > > Until then, the change can imo not go in before KF5 anyway, because > > it's a very visible behavioral change for users of Laptop, Plastik, BII and > > some legacy decorations (you still /can/ compile Quartz and Keramik and > > what they all were called) and pot. some distro specific decorations. > > Aleix Pol Gonzalez wrote: > Are you sure these are being used? because I searched for uses of this > API and I didn't see such uses. > > Thomas Lübking wrote: > KWin reads the setting values by hand in > libkdecorations/kdecoration_p.cpp - so actually I was wrong in that aspect: > the change in KGlobalSettings will not have a visible impact here - no > guarantee for 3rd party decos beyond bespin (esp. on custom config dialogs) > > Not sure whether this makes the change better, since now KWin will no > longer reflect what KGlobalSettings reports. > I'm not sure how important it is to export those values via > KGlobalSettings (i guess they existed to use the colors on MDI windows from > KStyle), but even while deprecated, their behavior should not change. > And unless the conclusion is that titlebars shall align to the window > content color, the advice should also not be to query that instead. It's > better to state "information not avialable" than to give a false information. > > Martin Gräßlin wrote: > It's worse - KWin does not just read the values by itself, it reads them > from kwinrc instead of kdeglobals. So whatever is set in KGlobalSettings: > KWin ignores it.
No ;-) Welcome to the magics of KConfig. I for one have no [WM] entry in kwinrc, it's only in kdeglobal - try grepping it =) However, KConfig resolves to kdeglobal for *every* rc unless explicitly told do do not, so <advert> kconfig kdeglobal/WM list and kconfig kwinrc/WM list </advert> will print the same value (read from kdeglobal) unless you explicitly add a configuration to kwinrc (what's afaics not done anywhere - hopefully ;-) - Thomas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111171/#review34861 ----------------------------------------------------------- On June 22, 2013, 10:25 a.m., Àlex Fiestas wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/111171/ > ----------------------------------------------------------- > > (Updated June 22, 2013, 10:25 a.m.) > > > Review request for KDE Frameworks and kdelibs. > > > Description > ------- > > Deprecate: inactiveTitleColor, inactiveTextColor, activeTitleColor, > activeTextColor in favor of KColorScheme and replace the implementation of > those methods with it. > > > Diffs > ----- > > kdeui/util/kglobalsettings.h 4b77ed5 > kdeui/util/kglobalsettings.cpp 3e60632 > khtml/misc/helper.cpp dccb9bf > > Diff: http://git.reviewboard.kde.org/r/111171/diff/ > > > Testing > ------- > > I have compared the colors returned by the methods before and after this > patch, they are close enough. > > Additionally used some apps like filelight with the change, and it seems to > work for them as well. > > > Thanks, > > Àlex Fiestas > >
