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