KGlobalSettings move to kde4support

[Kevin Ottens]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130618/5f11f9b7/attachment.sig>