KGlobalSettings move to kde4support

Aleix Pol aleixpol at kde.org
Mon Jun 17 17:43:33 UTC 2013


Hi,
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.

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?

 - 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()

 - 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.

- wheelMouseZooms: It's only used by KTextEditor, so I'd say it should be
moved there and deprecate it.

- naturalSorting: it's used by KDirOperator and Dolphin. Unsure what it
does.

- graphicEffectsLevel/graphicEffectsLevelDefault: That's being dealt by
Alex Fiestas, no?

- 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.

- buttonLayout: I really can't tell who uses it, it's impossible to look it
up in lxr. Nobody is using it in kdelibs.

- 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.

- emitChange: it mostly depends on what we do with each exposed property,
like we already did for the icon themes.

- activate/activate(options): They only make sense within a KGlobalSettings
scope.

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.

Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130617/c870cb50/attachment.html>


More information about the Kde-frameworks-devel mailing list