Re: KGlobalSettings move to kde4support
On Thursday 20 June 2013 07:50:04 Martin Gräßlin wrote: On Wednesday 19 June 2013 15:04:57 Matthew Woehlke wrote: On 2013-06-18 11:54, Aleix Pol wrote: On Tue, Jun 18, 2013 at 5:40 PM, Matthew Woehlke wrote: On 2013-06-18 03:10, Dominik Haumann wrote: On Tuesday, June 18, 2013 08:14:50 Kevin Ottens wrote: 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. 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? What are these used for? They sound like WM colors? 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. Perhaps, but KColorScheme already has quite some colors and they are (fairly) well organized at the moment. I would like to understand first what these other colors are used for and if maybe existing colors should be used instead, or at least how to best fit them into the existing framework. Here you can see where and how it's used: http://lxr.kde.org/ident?i=activeTitleColor http://lxr.kde.org/ident?i=inactiveTitleColor http://lxr.kde.org/ident?i=activeCaptionColor http://lxr.kde.org/ident?i=inactiveCaptionColor Yes, those appear to be the WM colors. I just had a look at the usage of KGlobalSettings inside KWin: none of these colors are used - neither in KWin core nor in the window decorations shipped with KWin. KWin reads color values with these names from a config group called WM without using KGlobalSettings (see kde- workspace/kwin/libkdecorations/kdecoration_p.cpp line 60ff). But tracing back the argument passed into this method: it always reads the values from kwinrc, never from kdeglobals. In case that had once been supported: it's at least broken since 4.0. So from my side there is no need to keep any special handling. If we want to make this work again we just need to modify the KCM to change kwin's config file for these colors. Right... So that means the pair of usages we have in khtml are kind of abuse from the original intent. I'd say we port those to KColorScheme calls instead and that's it, no further action required (I adjusted the wiki in that regard). Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by BlueSystems and KDAB to work on KDE Frameworks signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KGlobalSettings move to kde4support
Hello, On Tuesday 18 June 2013 20:00:40 Aleix Pol wrote: I added theme here [1]. Can you take a look and see if it's what you expected? :) Mostly good, I adjusted just a bit. I also removed the tasks which were deprecate only. The whole class will get deprecated when moving in kde4support, so no action is required apart from the dependency cuts incurred by the move (part of the move task IMO). Regards. [1] http://community.kde.org/Frameworks/Epics/kdelibs_cleanups -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by BlueSystems and KDAB to work on KDE Frameworks signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KGlobalSettings move to kde4support
On Tue, Jun 18, 2013 at 5:54 PM, Aleix Pol aleix...@kde.org wrote: On Tue, Jun 18, 2013 at 5:40 PM, Matthew Woehlke mwoehlke.fl...@gmail.com wrote: On 2013-06-18 03:10, Dominik Haumann wrote: On Tuesday, June 18, 2013 08:14:50 Kevin Ottens wrote: 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. 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? What are these used for? They sound like WM colors? 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. Perhaps, but KColorScheme already has quite some colors and they are (fairly) well organized at the moment. I would like to understand first what these other colors are used for and if maybe existing colors should be used instead, or at least how to best fit them into the existing framework. Thanks, (Please keep me CC'd.) -- Matthew __**_ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/**listinfo/kde-frameworks-develhttps://mail.kde.org/mailman/listinfo/kde-frameworks-devel Hi, Here you can see where and how it's used: http://lxr.kde.org/ident?i=activeTitleColor http://lxr.kde.org/ident?i=inactiveTitleColorhttp://lxr.kde.org/ident?i=activeTitleColor http://lxr.kde.org/ident?i=activeCaptionColorhttp://lxr.kde.org/ident?i=activeTitleColor http://lxr.kde.org/ident?i=inactiveCaptionColor Aleix Hi Matthew, Can we have your insight in this? I'd appreciate it very much. Aleix PS: it wasn't Caption, it was Text http://lxr.kde.org/ident?i=activeTextColor http://lxr.kde.org/ident?i=inactiveTextColor ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KGlobalSettings move to kde4support
On 2013-06-18 11:54, Aleix Pol wrote: On Tue, Jun 18, 2013 at 5:40 PM, Matthew Woehlke wrote: On 2013-06-18 03:10, Dominik Haumann wrote: On Tuesday, June 18, 2013 08:14:50 Kevin Ottens wrote: 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. 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? What are these used for? They sound like WM colors? 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. Perhaps, but KColorScheme already has quite some colors and they are (fairly) well organized at the moment. I would like to understand first what these other colors are used for and if maybe existing colors should be used instead, or at least how to best fit them into the existing framework. Here you can see where and how it's used: http://lxr.kde.org/ident?i=activeTitleColor http://lxr.kde.org/ident?i=inactiveTitleColor http://lxr.kde.org/ident?i=activeCaptionColor http://lxr.kde.org/ident?i=inactiveCaptionColor Yes, those appear to be the WM colors. Two possibilities come to mind. One is to continue to treat WM colors as totally independent. I think this would be best done by creating a new class similar to KColorScheme but not the same class, maybe KWmColorScheme. This is the simplest and most similar to the current state of things. The best way I have come up with to extend KColorScheme to support WM's is to add a new color set, maybe TitleBar or Caption, and to add a new decoration role BorderColor (defaulting to normal background). The new color set would need to load both border color, and all colors for the Inactive state, separately from settings so that users have the same degree of control as before. (Actually maybe not border color; I don't think the KCM allows setting that independently at the moment. Maybe we could even omit border color entirely, at least for now.) The advantages of the second method are that WM's would also newly get all the additional color role goodness (window title bar with PositiveBackground, anyone?) and users can again configure the secondary (blend) title bar background color (as this should switch over to the AlternateBackground role). However it makes KColorScheme's life harder due to the special case code for loading colors for the new set, and requires more changes to the KCM. -- Matthew ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: KGlobalSettings move to kde4support
On Wednesday 19 June 2013 15:04:57 Matthew Woehlke wrote: On 2013-06-18 11:54, Aleix Pol wrote: On Tue, Jun 18, 2013 at 5:40 PM, Matthew Woehlke wrote: On 2013-06-18 03:10, Dominik Haumann wrote: On Tuesday, June 18, 2013 08:14:50 Kevin Ottens wrote: 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. 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? What are these used for? They sound like WM colors? 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. Perhaps, but KColorScheme already has quite some colors and they are (fairly) well organized at the moment. I would like to understand first what these other colors are used for and if maybe existing colors should be used instead, or at least how to best fit them into the existing framework. Here you can see where and how it's used: http://lxr.kde.org/ident?i=activeTitleColor http://lxr.kde.org/ident?i=inactiveTitleColor http://lxr.kde.org/ident?i=activeCaptionColor http://lxr.kde.org/ident?i=inactiveCaptionColor Yes, those appear to be the WM colors. I just had a look at the usage of KGlobalSettings inside KWin: none of these colors are used - neither in KWin core nor in the window decorations shipped with KWin. KWin reads color values with these names from a config group called WM without using KGlobalSettings (see kde- workspace/kwin/libkdecorations/kdecoration_p.cpp line 60ff). But tracing back the argument passed into this method: it always reads the values from kwinrc, never from kdeglobals. In case that had once been supported: it's at least broken since 4.0. So from my side there is no need to keep any special handling. If we want to make this work again we just need to modify the KCM to change kwin's config file for these colors. Cheers Martin Gräßlin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KGlobalSettings move to kde4support
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
Re: Re: KGlobalSettings move to kde4support
On Tuesday, June 18, 2013 08:14:50 Kevin Ottens wrote: 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. CC Matthew, since he knows a lot about KColorScheme. Maybe he can be of help here. Greetings, Dominik ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KGlobalSettings move to kde4support
On 2013-06-18 03:10, Dominik Haumann wrote: On Tuesday, June 18, 2013 08:14:50 Kevin Ottens wrote: 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. 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? What are these used for? They sound like WM colors? 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. Perhaps, but KColorScheme already has quite some colors and they are (fairly) well organized at the moment. I would like to understand first what these other colors are used for and if maybe existing colors should be used instead, or at least how to best fit them into the existing framework. Thanks, (Please keep me CC'd.) -- Matthew ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KGlobalSettings move to kde4support
On Tue, Jun 18, 2013 at 5:40 PM, Matthew Woehlke mwoehlke.fl...@gmail.comwrote: On 2013-06-18 03:10, Dominik Haumann wrote: On Tuesday, June 18, 2013 08:14:50 Kevin Ottens wrote: 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. 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? What are these used for? They sound like WM colors? 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. Perhaps, but KColorScheme already has quite some colors and they are (fairly) well organized at the moment. I would like to understand first what these other colors are used for and if maybe existing colors should be used instead, or at least how to best fit them into the existing framework. Thanks, (Please keep me CC'd.) -- Matthew __**_ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/**listinfo/kde-frameworks-develhttps://mail.kde.org/mailman/listinfo/kde-frameworks-devel Hi, Here you can see where and how it's used: http://lxr.kde.org/ident?i=activeTitleColor http://lxr.kde.org/ident?i=inactiveTitleColorhttp://lxr.kde.org/ident?i=activeTitleColor http://lxr.kde.org/ident?i=activeCaptionColorhttp://lxr.kde.org/ident?i=activeTitleColor http://lxr.kde.org/ident?i=inactiveCaptionColor Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KGlobalSettings move to kde4support
On Tue, Jun 18, 2013 at 8:14 AM, Kevin Ottens ervin+bluesyst...@kde.orgwrote: 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
