On Tue, Jun 18, 2013 at 8:14 AM, Kevin Ottens <ervin+bluesyst...@kde.org>wrote:
> Hello, > > On Monday 17 June 2013 19:43:33 Aleix Pol wrote: > > So I was looking at KGlobalSettings to see what we need to do to finally > > deprecate all KGlobalSettings, as suggested by the required kdelibs > > cleanups. > > Ah good, it was in my hit list for the coming days too. But if you can > handle > it that's fine by me. > > > So the things missing to be done are: > > - (in)active(Title/Color)Color: I'm unsure why those are there, but > > they're only used by khtml (within kdelibs) and I don't know if they're > > configurable. I guess they should be using KColorScheme, although I don't > > see caption properties there. Ideas? > > It's used a bit outside of kdelibs, but not much indeed. Still as you said > it > likely makes most sense in KColorScheme. So I'd say extend KColorScheme > accordingly and then deprecate. > > > - Font methods: They are used in many places in and out of kdelibs, I'm > > unsure what's the plan for it. Should we create a new class for that? Or > > add it to QStyle? Or maybe we can just standarize some font names. See > > kdisplaySetFont() > > The idea here would be to handle that using our platformtheme plugin when > it > comes to forcing user set fonts on widgets. I've found the font API to be > used > outside of kdelibs widgets only seldomly and it was always for > fixedFont(), so > although not ideal we currently use a dynamic property names _k_fixedFont > on > the application object to store it (maybe QGuiApplication could be > extended to > have that as a regular method). > > The mechanisms I describe above are implemented in > staging/frameworkintegration/src/platformtheme/kdeplatformtheme.cpp > Needs review as it might miss some calls to QApplication::setFont > > Most of the aspects of KGlobalSettings to "ensure consistency" should > likely > follow the same path. > > > - isMultiHead: Reads a env variable that tells if KDE has to work on > multi > > head mode. It's only used by plasma and KWin, so we can probably find a > > better place for the check. > > Is it even still needed? Nowadays relying on an env variable for that > sounds > strange... But I might miss something. > > In any case the code is trivial enough that it could be duplicated in kwin > and > plasma-framework if need be. > > > - wheelMouseZooms: It's only used by KTextEditor, so I'd say it should be > > moved there and deprecate it. > > This one I already checked. No action is required, it's read at only one > place > and there's no one writing the setting... So effectively users can't change > it, only the default is used. > > > - naturalSorting: it's used by KDirOperator and Dolphin. Unsure what it > > does. > > It does what Alex Merry said. It's in fact a setting driven by dolphin > itself > only. It's used only there and in a couple of widgets used in a similar > context. I would say it should be fully handled in dolphin itself then. > > On the kdelibs side the only thing needed is then for the widgets currently > reading from that setting to instead provide a setter/getter pair so that > dolphin will be able to change their behavior when it sees fit. > > > - graphicEffectsLevel/graphicEffectsLevelDefault: That's being dealt by > > Alex Fiestas, no? > > Yep, there's tasks in the wiki around that already. > > > - opaqueResize: I see there's already a task created about it, to move > it > > to Qt. It's about using QSplitter. I guess we can assume this goes to > > kde4support and it's fine. > > Yep, the task is there already. > > > - buttonLayout: I really can't tell who uses it, it's impossible to look > it > > up in lxr. Nobody is using it in kdelibs. > > It's completely unused so we can ignore it. > > > - createApplicationPalette/createNewApplicationPalette: These seems to me > > that they're only used because of some limitation in the Qt we had in > > maemo, to force applications to use the oxygen style. For some reason. > I'd > > say the code for this should go to KQGuiPlatformPlugin and just deprecate > > these interfaces. > > It's like the fonts, it's handled at least in part in > staging/frameworkintegration/src/platformtheme/kdeplatformtheme.cpp > So same treatment: needs to review the corresponding code in our platform > theme plugin. > > > - emitChange: it mostly depends on what we do with each exposed property, > > like we already did for the icon themes. > > That one it's basically the task on making sure our QPA plugin reacts to > setting changes. > > > - activate/activate(options): They only make sense within a > KGlobalSettings > > scope. > > Agreed. > > > So would it make sense to create separate tasks for each of those > elements > > that don't have an item so that we can work them together? Having a task > > saying "KGlobalSettings move to kde4support" is unrealistic to accomplish > > at the moment. > > What should be clarified in the wiki is that the moving task in the cleanup > page for that one has to come last. It indeed just says move without > hinting > that we already have other tasks... We probably should have a few more and > clarify a few existing ones as you found out above. > > I can do that if you're fine with the extra information I brought in this > email. > > Regards. > -- > Kévin Ottens, http://ervin.ipsquad.net > > Sponsored by BlueSystems and KDAB to work on KDE Frameworks > > _______________________________________________ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel > > I added theme here [1]. Can you take a look and see if it's what you expected? :) Aleix [1] http://community.kde.org/Frameworks/Epics/kdelibs_cleanups
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
