> 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. > > Thomas Lübking wrote: > 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 ;-) > > Martin Gräßlin wrote: > wtf?!? I hate magic functionality > > Thomas Lübking wrote: > Well, yes. The "magic" function here is the open flag: > > http://api.kde.org/4.10-api/kdelibs-apidocs/kdecore/html/classKConfig.html#ad1f23964bbf8c11449e92a2596d15f7e > > One can either omit cascading (system wide files) or globals (kdeglobals) > Since the color and some WM settings were/are attractive from many > points, it was/is reasonable to store them globally. > > Aleix Pol Gonzalez wrote: > In any case, this seems broken to me. > > If you're really serious about this, we probably should just deprecate > the function and advise users to just read the file directly if they want to > access this data and move on. > > Thomas Lübking wrote: > No, it's not broken at all - normal KConfig behavior, ever has been. > > If this shall be deprecated (can't say - i don't need them and don't > care) your conclusion is however right: > the current behavior shall be preserved and the clients be advised to > query the setting directly (as kwin does atm) for KF5. > > The "serious" part is that you were about to alter functionality in even > frozen kdelibs and esp. imply a wider reaching change: fixed "titlebar == > window background" assumption, ie. no titlebar colors - which, given the > little war on oxygen back then, probably needs to be openly discussed before. > > Personally, i'd be fine moving the setting to kwin only - as MDI is a bug > to begin with and the setting unlikely required by applications then. > I simply didn't want KWin to receive bugreports "plastik: colors no more > supported" (what, as now figured, would however only happen by withdrawing > the color kcm setting on top of mentioned implication) and i *seriously* do > not want to see such war as on ozone ./. oxygen ever again (so the idea to > deprecate those color config triggered a button ;-) > /my2¢
"I hate magic functionality" ... any sufficiently advanced technology *cough* As noted, this is documented behaviour and it serves a very real and very useful purpose: to allow global settings to be transparently available to (yet still be overridden by!) each application. It's a very simple and elegant way to allow for global behaviours to be configured without requiring such code in every application. - Aaron J. ----------------------------------------------------------- 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 > >
