--===============3537451445785553867== Content-Type: multipart/signed; boundary="nextPart1780853.4e6KNUhXvZ"; micalg="pgp-sha1"; protocol="application/pgp-signature" --nextPart1780853.4e6KNUhXvZ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" 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 fina= lly > 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=20 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 d= on't > see caption properties there. Ideas? It's used a bit outside of kdelibs, but not much indeed. Still as you s= aid it=20 likely makes most sense in KColorScheme. So I'd say extend KColorScheme= =20 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. Se= e > kdisplaySetFont() The idea here would be to handle that using our platformtheme plugin wh= en it=20 comes to forcing user set fonts on widgets. I've found the font API to = be used=20 outside of kdelibs widgets only seldomly and it was always for fixedFon= t(), so=20 although not ideal we currently use a dynamic property names _k_fixedFo= nt on=20 the application object to store it (maybe QGuiApplication could be exte= nded to=20 have that as a regular method). The mechanisms I describe above are implemented in=20 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 l= ikely=20 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 s= ounds=20 strange... But I might miss something. In any case the code is trivial enough that it could be duplicated in k= win and=20 plasma-framework if need be. > - wheelMouseZooms: It's only used by KTextEditor, so I'd say it shoul= d be > moved there and deprecate it. This one I already checked. No action is required, it's read at only on= e place=20 and there's no one writing the setting... So effectively users can't ch= ange=20 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=20 only. It's used only there and in a couple of widgets used in a similar= =20 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 curre= ntly=20 reading from that setting to instead provide a setter/getter pair so th= at=20 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 mo= ve 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 l= ook it > up in lxr. Nobody is using it in kdelibs. It's completely unused so we can ignore it. > - createApplicationPalette/createNewApplicationPalette: These seems t= o 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 depre= cate > these interfaces. It's like the fonts, it's handled at least in part in=20 staging/frameworkintegration/src/platformtheme/kdeplatformtheme.cpp So same treatment: needs to review the corresponding code in our platfo= rm=20 theme plugin. > - emitChange: it mostly depends on what we do with each exposed prope= rty, > like we already did for the icon themes. That one it's basically the task on making sure our QPA plugin reacts t= o=20 setting changes. > - activate/activate(options): They only make sense within a KGlobalSe= ttings > scope. Agreed. > So would it make sense to create separate tasks for each of those ele= ments > that don't have an item so that we can work them together? Having a t= ask > saying "KGlobalSettings move to kde4support" is unrealistic to accomp= lish > at the moment. What should be clarified in the wiki is that the moving task in the cle= anup=20 page for that one has to come last. It indeed just says move without hi= nting=20 that we already have other tasks... We probably should have a few more = and=20 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 th= is=20 email. Regards. --=20 K=E9vin Ottens, http://ervin.ipsquad.net Sponsored by BlueSystems and KDAB to work on KDE Frameworks --nextPart1780853.4e6KNUhXvZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEABECAAYFAlG/+uAACgkQB0u7y43syeJ1/QCfeRs0iYpqZ6P1GFz8USC59Jwo 4tkAn1e445+oIvpHDgzrJ1765YNT3uaW =UWOv -----END PGP SIGNATURE----- --nextPart1780853.4e6KNUhXvZ-- --===============3537451445785553867== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel --===============3537451445785553867==--