KGlobalSettings move to kde4support

[Aleix Pol]

On Tue, Jun 18, 2013 at 8:14 AM, Kevin Ottens <ervin+bluesystems at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130618/dab436c9/attachment.html>