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