Re: KDE-wide Animation settings
On Saturday 04 January 2014 20:52:43 David Faure wrote: On Saturday 04 January 2014 20:19:43 Hugo Pereira Da Costa wrote: The first problem is that with kf5, the style configuration kcm expects a libkstyle_oxygen_config.so *plugin* for this configuration, whereas it was kstyle_oxygen_config.so in kde4 times. now, as the error message indicates: plugins should not start with lib and thus, oxygen still installs kstyle_oxygen_config.so only so that the ill-named plugin is not found, and you get the error dialog. To fix, - either we fix the kcm by changing the looked for plugin name (by removing the lib prefix) Yes. Why does the kcm look for a lib prefix now? Surely there's no good reason for that, the kde4 way was fine. it was me who ported the kcm. I didn't change anything in that regard - at least not knowingly. The only change in KCMStyle::styleSpecificConfig() was: -KLibrary library(libname, KCMStyleFactory::componentData()); +KLibrary library(libname); Also I think to remember that it used to work when I did the port. So I rather think it got broken by a3194a6010961c68da80a9a8aa97501fb637f4a1 Cheers Martin 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: KDE-wide Animation settings
On 01/05/2014 09:42 AM, Martin Graesslin wrote: On Saturday 04 January 2014 20:52:43 David Faure wrote: On Saturday 04 January 2014 20:19:43 Hugo Pereira Da Costa wrote: The first problem is that with kf5, the style configuration kcm expects a libkstyle_oxygen_config.so *plugin* for this configuration, whereas it was kstyle_oxygen_config.so in kde4 times. now, as the error message indicates: plugins should not start with lib and thus, oxygen still installs kstyle_oxygen_config.so only so that the ill-named plugin is not found, and you get the error dialog. To fix, - either we fix the kcm by changing the looked for plugin name (by removing the lib prefix) Yes. Why does the kcm look for a lib prefix now? Surely there's no good reason for that, the kde4 way was fine. it was me who ported the kcm. I didn't change anything in that regard - at least not knowingly. The only change in KCMStyle::styleSpecificConfig() was: -KLibrary library(libname, KCMStyleFactory::componentData()); +KLibrary library(libname); Also I think to remember that it used to work when I did the port. So I rather think it got broken by a3194a6010961c68da80a9a8aa97501fb637f4a1 This commit is the one that _removed_ the lib prefix, consistently with what was done with kde4: (see /usr/lib64/kde4/kstyle_oxygen_config.so, and now: $KF5/lib/plugins/kf5/kstyle_oxygen_config.so all consistent !) as I said, this commit did break the kf5 style kcm, that (incorrectly) expects a lib prefix, and is therefore the one that shows up by git dissect, but I think we'd rather fix the expect a lib prefix part rather than revert the commit. Best, Hugo Cheers Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE-wide Animation settings
On 01/04/2014 11:21 PM, Dominik Haumann wrote: On Saturday 04 January 2014 23:11:14 David Faure wrote: On Saturday 04 January 2014 23:02:35 Dominik Haumann wrote: On Saturday 04 January 2014 20:56:30 Hugo Pereira Da Costa wrote: ok. So this should go to kstyle (nothing oxygen explicit in there). In fact, kstyle returns: KConfigGroup g(KSharedConfig::openConfig(), KDE-Global GUI Settings); return g.readEntry(GraphicEffectsLevel, 0); mmm. No clue which KCM sets this :) (but that answers Dominik's original question I guess) Yes, that answers my question. In particular, using the code widget-style()-styleHint(QStyle::SH_Widget_Animate, 0, widget) is correct *if* we use a KStyle based style. No, it's correct in all cases :) With the other Qt styles you get true, which is the correct default value. Ok, I missed this one, thanks for the clarification! What I personally would like more is to always be able to read this. I of course can use a KSharedConfig::openConfig() and then read the config value myself. However, would it be of interest to have a static accessor for this? Downside is that there are quite a lot of kdeglobals dependent entries... Is the preferred way to read this value manually then in KatePart? Would that also be the preferred way in KMessageWidget? I don't really see what the issue is. Do you care that much for Windows users to be able to turn animations off? Nevermind, was a misunderstanding then. Another issue we have in Kate code: kdeglobals right now do not have this effects enabled by default. A unit test from kde4 times now fails in kf5, because the timings are different, because the effects are off. Are there plans to have a kdeglobals that has enabled effects? As I said, it's a bug in the readEntry() call above. The default is supposed to be 1, so you don't need a special kdeglobals. Ok, so who is going to fix it? ;) Hugo? Question should the default simply be 1 or should kstyle re-introduce the same enumeration that was in KGlobalSettings ? enum GraphicEffect { NoEffects = 0x, /// GUI with no effects at all. GradientEffects = 0x0001, /// GUI with only gradients enabled. SimpleAnimationEffects = 0x0002, /// GUI with simple animations enabled. ComplexAnimationEffects = 0x0006 /// GUI with complex animations enabled. /// Note that ComplexAnimationsEffects implies SimpleAnimationEffects. }; and the default be ComplexAnimationEffects ? Greetings, Dominik ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE-wide Animation settings
On 01/05/2014 09:57 AM, Hugo Pereira Da Costa wrote: On 01/05/2014 09:42 AM, Martin Graesslin wrote: On Saturday 04 January 2014 20:52:43 David Faure wrote: On Saturday 04 January 2014 20:19:43 Hugo Pereira Da Costa wrote: The first problem is that with kf5, the style configuration kcm expects a libkstyle_oxygen_config.so *plugin* for this configuration, whereas it was kstyle_oxygen_config.so in kde4 times. now, as the error message indicates: plugins should not start with lib and thus, oxygen still installs kstyle_oxygen_config.so only so that the ill-named plugin is not found, and you get the error dialog. To fix, - either we fix the kcm by changing the looked for plugin name (by removing the lib prefix) Yes. Why does the kcm look for a lib prefix now? Surely there's no good reason for that, the kde4 way was fine. it was me who ported the kcm. I didn't change anything in that regard - at least not knowingly. The only change in KCMStyle::styleSpecificConfig() was: -KLibrary library(libname, KCMStyleFactory::componentData()); +KLibrary library(libname); Also I think to remember that it used to work when I did the port. So I rather think it got broken by a3194a6010961c68da80a9a8aa97501fb637f4a1 This commit is the one that _removed_ the lib prefix, consistently with what was done with kde4: (see /usr/lib64/kde4/kstyle_oxygen_config.so, and now: $KF5/lib/plugins/kf5/kstyle_oxygen_config.so all consistent !) as I said, this commit did break the kf5 style kcm, that (incorrectly) expects a lib prefix, and is therefore the one that shows up by git dissect, but I think we'd rather fix the expect a lib prefix part rather than revert the commit. Best, mmm. My bad. In fact the current breakage is an inconsistency between what oxygen installs (kstyle_oxygen_config) and what it announce in oxygen.themerc. Just fixed it. Sorry for the noise. Nothing was changed indeed to the kstyle kcm. Hugo Hugo Cheers Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE-wide Animation settings
On Sunday 05 January 2014 10:10:48 you wrote: On 01/05/2014 09:57 AM, Hugo Pereira Da Costa wrote: On 01/05/2014 09:42 AM, Martin Graesslin wrote: On Saturday 04 January 2014 20:52:43 David Faure wrote: On Saturday 04 January 2014 20:19:43 Hugo Pereira Da Costa wrote: The first problem is that with kf5, the style configuration kcm expects a libkstyle_oxygen_config.so *plugin* for this configuration, whereas it was kstyle_oxygen_config.so in kde4 times. now, as the error message indicates: plugins should not start with lib and thus, oxygen still installs kstyle_oxygen_config.so only so that the ill-named plugin is not found, and you get the error dialog. To fix, - either we fix the kcm by changing the looked for plugin name (by removing the lib prefix) Yes. Why does the kcm look for a lib prefix now? Surely there's no good reason for that, the kde4 way was fine. it was me who ported the kcm. I didn't change anything in that regard - at least not knowingly. The only change in KCMStyle::styleSpecificConfig() was: -KLibrary library(libname, KCMStyleFactory::componentData()); +KLibrary library(libname); Also I think to remember that it used to work when I did the port. So I rather think it got broken by a3194a6010961c68da80a9a8aa97501fb637f4a1 This commit is the one that _removed_ the lib prefix, consistently with what was done with kde4: (see /usr/lib64/kde4/kstyle_oxygen_config.so, and now: $KF5/lib/plugins/kf5/kstyle_oxygen_config.so all consistent !) as I said, this commit did break the kf5 style kcm, that (incorrectly) expects a lib prefix, and is therefore the one that shows up by git dissect, but I think we'd rather fix the expect a lib prefix part rather than revert the commit. Best, mmm. My bad. In fact the current breakage is an inconsistency between what oxygen installs (kstyle_oxygen_config) and what it announce in oxygen.themerc. Just fixed it. Sorry for the noise. Nothing was changed indeed to the kstyle kcm. perfect! Thanks for fixing. Cheers Martin 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: KDE-wide Animation settings
On Sunday 05 January 2014 10:04:00 Hugo Pereira Da Costa wrote: On 01/04/2014 11:21 PM, Dominik Haumann wrote: On Saturday 04 January 2014 23:11:14 David Faure wrote: On Saturday 04 January 2014 23:02:35 Dominik Haumann wrote: On Saturday 04 January 2014 20:56:30 Hugo Pereira Da Costa wrote: ok. So this should go to kstyle (nothing oxygen explicit in there). In fact, kstyle returns: KConfigGroup g(KSharedConfig::openConfig(), KDE-Global GUI Settings); return g.readEntry(GraphicEffectsLevel, 0); mmm. No clue which KCM sets this :) (but that answers Dominik's original question I guess) Yes, that answers my question. In particular, using the code widget-style()-styleHint(QStyle::SH_Widget_Animate, 0, widget) is correct *if* we use a KStyle based style. No, it's correct in all cases :) With the other Qt styles you get true, which is the correct default value. Ok, I missed this one, thanks for the clarification! What I personally would like more is to always be able to read this. I of course can use a KSharedConfig::openConfig() and then read the config value myself. However, would it be of interest to have a static accessor for this? Downside is that there are quite a lot of kdeglobals dependent entries... Is the preferred way to read this value manually then in KatePart? Would that also be the preferred way in KMessageWidget? I don't really see what the issue is. Do you care that much for Windows users to be able to turn animations off? Nevermind, was a misunderstanding then. Another issue we have in Kate code: kdeglobals right now do not have this effects enabled by default. A unit test from kde4 times now fails in kf5, because the timings are different, because the effects are off. Are there plans to have a kdeglobals that has enabled effects? As I said, it's a bug in the readEntry() call above. The default is supposed to be 1, so you don't need a special kdeglobals. Ok, so who is going to fix it? ;) Hugo? Question should the default simply be 1 or should kstyle re-introduce the same enumeration that was in KGlobalSettings ? enum GraphicEffect { NoEffects = 0x, /// GUI with no effects at all. GradientEffects = 0x0001, /// GUI with only gradients enabled. SimpleAnimationEffects = 0x0002, /// GUI with simple animations enabled. ComplexAnimationEffects = 0x0006 /// GUI with complex animations enabled. 1) I don't think these multiple levels were ever used anywhere 2) the Qt widgets simply test it as a boolean If you see a good reason for multiple levels, go for it; but if it's just because kde4 had it - not a good enough reason, since it wasn't used there. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE-wide Animation settings
On Saturday 04 January 2014 23:04:50 Nicolás Alvarez wrote: 2014/1/4 David Faure fa...@kde.org: On Saturday 04 January 2014 23:02:35 Dominik Haumann wrote: What I personally would like more is to always be able to read this. I of course can use a KSharedConfig::openConfig() and then read the config value myself. However, would it be of interest to have a static accessor for this? Downside is that there are quite a lot of kdeglobals dependent entries... Is the preferred way to read this value manually then in KatePart? Would that also be the preferred way in KMessageWidget? I don't really see what the issue is. Do you care that much for Windows users to be able to turn animations off? Ideally on Windows we'd follow Windows settings rather than KDE apps having their own configuration. SystemParametersInfo(SPI_GETCLIENTAREAANIMATION) seems to get what we'd want. Sounds good, please make a change request for the Qt windows styles :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE-wide Animation settings
Hi Dominik, there are two issues in what you describe 1. There was an error loading the configuration dialog for this style: Unknown error. 2. QStyle::SH_Widget_Animate The first problem is that with kf5, the style configuration kcm expects a libkstyle_oxygen_config.so *plugin* for this configuration, whereas it was kstyle_oxygen_config.so in kde4 times. now, as the error message indicates: plugins should not start with lib and thus, oxygen still installs kstyle_oxygen_config.so only so that the ill-named plugin is not found, and you get the error dialog. To fix, - either we fix the kcm by changing the looked for plugin name (by removing the lib prefix) (I think it was added in the first place due to the lack of replacement for kde4_add_plugin) - I re-add the lib prefix to the config plugin name installed by oxygen. I'd vote for the first solution, but this requires kde wide agreement. For the second issue, QStyle::SH_Widget_Animate is set to false not in oxygen style but in KStyle by itself. This is unrelated to the style configuration. I am not too inclined to set it to true, since I am absolutely unclear what this style hint is meant for. Can someone explain ? Notably, I don't think it should be set to true for _all_ widgets, since most widgets are already animated internally by oxygen (and thus should not be by the app), though it indeed should return true for KMessageWidget, which is not animated internally. So: should I enable the flag only for widgets that oxygen does not animate itself ? Is that the intended purpose of the flag ? Can someone explain ? Many thanks in advance, Hugo On 01/04/2014 05:58 PM, Dominik Haumann wrote: Hi, in KDE4 times we had e.g. in KMessageWidget: if (KGlobalSettings::graphicEffectsLevel() KGlobalSettings::SimpleAnimationEffects) { // do animation } Seems this was dependent on the style but read from some config value that was set through the kcm 'style', clicking Configure next to the oxygen widget style. This configure button was not available for all styles. In KF5, this became: if (style()-styleHint(QStyle::SH_Widget_Animate, 0, this)) { // do animation } Using the Oxygen style, this currently returns false. The configure button only launches an error message saying There was an error loading the configuration dialog for this style: Unknown error. At the same time, I get this output on the console: kcmshell5(13712)/(default) findLibraryInternal: plugins should not have a 'lib' prefix: libkstyle_oxygen_config.so The config dialog never shows then. Is there a way to enable animations so that style()-styleHint(QStyle::SH_Widget_Animate, 0, this) returns true? Greetings, Dominik ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE-wide Animation settings
On Saturday 04 January 2014 20:19:43 Hugo Pereira Da Costa wrote: The first problem is that with kf5, the style configuration kcm expects a libkstyle_oxygen_config.so *plugin* for this configuration, whereas it was kstyle_oxygen_config.so in kde4 times. now, as the error message indicates: plugins should not start with lib and thus, oxygen still installs kstyle_oxygen_config.so only so that the ill-named plugin is not found, and you get the error dialog. To fix, - either we fix the kcm by changing the looked for plugin name (by removing the lib prefix) Yes. Why does the kcm look for a lib prefix now? Surely there's no good reason for that, the kde4 way was fine. (I think it was added in the first place due to the lack of replacement for kde4_add_plugin) But we can still remove the prefix, can't we? You do so for oxygen :) For the second issue, QStyle::SH_Widget_Animate is set to false not in oxygen style but in KStyle by itself. This is unrelated to the style configuration. I am not too inclined to set it to true, since I am absolutely unclear what this style hint is meant for. Can someone explain ? It should be true on fast local desktops, and false on slow/remote desktops, I suppose. IOW user configurable. Notably, I don't think it should be set to true for _all_ widgets, since most widgets are already animated internally by oxygen (and thus should not be by the app), though it indeed should return true for KMessageWidget, which is not animated internally. So: should I enable the flag only for widgets that oxygen does not animate itself ? No, I think it's rather unrelated. The animations from the widgets themselves are (as can be found by grepping qtbase) - opening trees in QTreeView - moving tabs in QTabBar - dockareas and toolbars Does oxygen animate any of that? I'd be surprised, since these were already animated in Qt4. What's new is letting users turn it off, via kstyle using kconfig. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE-wide Animation settings
On 01/04/2014 08:52 PM, David Faure wrote: On Saturday 04 January 2014 20:19:43 Hugo Pereira Da Costa wrote: The first problem is that with kf5, the style configuration kcm expects a libkstyle_oxygen_config.so *plugin* for this configuration, whereas it was kstyle_oxygen_config.so in kde4 times. now, as the error message indicates: plugins should not start with lib and thus, oxygen still installs kstyle_oxygen_config.so only so that the ill-named plugin is not found, and you get the error dialog. To fix, - either we fix the kcm by changing the looked for plugin name (by removing the lib prefix) Yes. Why does the kcm look for a lib prefix now? Surely there's no good reason for that, the kde4 way was fine. (I think it was added in the first place due to the lack of replacement for kde4_add_plugin) But we can still remove the prefix, can't we? You do so for oxygen :) yes: add_library(kstyle_oxygen_config MODULE ...) For the second issue, QStyle::SH_Widget_Animate is set to false not in oxygen style but in KStyle by itself. This is unrelated to the style configuration. I am not too inclined to set it to true, since I am absolutely unclear what this style hint is meant for. Can someone explain ? It should be true on fast local desktops, and false on slow/remote desktops, I suppose. IOW user configurable. ok. So this should go to kstyle (nothing oxygen explicit in there). In fact, kstyle returns: KConfigGroup g(KSharedConfig::openConfig(), KDE-Global GUI Settings); return g.readEntry(GraphicEffectsLevel, 0); mmm. No clue which KCM sets this :) (but that answers Dominik's original question I guess) Notably, I don't think it should be set to true for _all_ widgets, since most widgets are already animated internally by oxygen (and thus should not be by the app), though it indeed should return true for KMessageWidget, which is not animated internally. So: should I enable the flag only for widgets that oxygen does not animate itself ? No, I think it's rather unrelated. The animations from the widgets themselves are (as can be found by grepping qtbase) - opening trees in QTreeView - moving tabs in QTabBar - dockareas and toolbars Does oxygen animate any of that? I'd be surprised, since these were already animated in Qt4. What's new is letting users turn it off, via kstyle using kconfig. Nope does not. Thanks for the explanation. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE-wide Animation settings
On Saturday 04 January 2014 20:56:30 Hugo Pereira Da Costa wrote: KConfigGroup g(KSharedConfig::openConfig(), KDE-Global GUI Settings); return g.readEntry(GraphicEffectsLevel, 0); The default value is wrong. In KDE4 it was enabled by default. (see KGlobalSettings::graphicEffectsLevelDefault()) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE-wide Animation settings
On Saturday 04 January 2014 20:56:30 Hugo Pereira Da Costa wrote: ok. So this should go to kstyle (nothing oxygen explicit in there). In fact, kstyle returns: KConfigGroup g(KSharedConfig::openConfig(), KDE-Global GUI Settings); return g.readEntry(GraphicEffectsLevel, 0); mmm. No clue which KCM sets this :) (but that answers Dominik's original question I guess) Yes, that answers my question. In particular, using the code widget-style()-styleHint(QStyle::SH_Widget_Animate, 0, widget) is correct *if* we use a KStyle based style. What I personally would like more is to always be able to read this. I of course can use a KSharedConfig::openConfig() and then read the config value myself. However, would it be of interest to have a static accessor for this? Downside is that there are quite a lot of kdeglobals dependent entries... Is the preferred way to read this value manually then in KatePart? Would that also be the preferred way in KMessageWidget? Another issue we have in Kate code: kdeglobals right now do not have this effects enabled by default. A unit test from kde4 times now fails in kf5, because the timings are different, because the effects are off. Are there plans to have a kdeglobals that has enabled effects? Greetings, Dominik ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE-wide Animation settings
On Saturday 04 January 2014 23:02:35 Dominik Haumann wrote: On Saturday 04 January 2014 20:56:30 Hugo Pereira Da Costa wrote: ok. So this should go to kstyle (nothing oxygen explicit in there). In fact, kstyle returns: KConfigGroup g(KSharedConfig::openConfig(), KDE-Global GUI Settings); return g.readEntry(GraphicEffectsLevel, 0); mmm. No clue which KCM sets this :) (but that answers Dominik's original question I guess) Yes, that answers my question. In particular, using the code widget-style()-styleHint(QStyle::SH_Widget_Animate, 0, widget) is correct *if* we use a KStyle based style. No, it's correct in all cases :) With the other Qt styles you get true, which is the correct default value. What I personally would like more is to always be able to read this. I of course can use a KSharedConfig::openConfig() and then read the config value myself. However, would it be of interest to have a static accessor for this? Downside is that there are quite a lot of kdeglobals dependent entries... Is the preferred way to read this value manually then in KatePart? Would that also be the preferred way in KMessageWidget? I don't really see what the issue is. Do you care that much for Windows users to be able to turn animations off? Another issue we have in Kate code: kdeglobals right now do not have this effects enabled by default. A unit test from kde4 times now fails in kf5, because the timings are different, because the effects are off. Are there plans to have a kdeglobals that has enabled effects? As I said, it's a bug in the readEntry() call above. The default is supposed to be 1, so you don't need a special kdeglobals. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE-wide Animation settings
On Saturday 04 January 2014 23:11:14 David Faure wrote: On Saturday 04 January 2014 23:02:35 Dominik Haumann wrote: On Saturday 04 January 2014 20:56:30 Hugo Pereira Da Costa wrote: ok. So this should go to kstyle (nothing oxygen explicit in there). In fact, kstyle returns: KConfigGroup g(KSharedConfig::openConfig(), KDE-Global GUI Settings); return g.readEntry(GraphicEffectsLevel, 0); mmm. No clue which KCM sets this :) (but that answers Dominik's original question I guess) Yes, that answers my question. In particular, using the code widget-style()-styleHint(QStyle::SH_Widget_Animate, 0, widget) is correct *if* we use a KStyle based style. No, it's correct in all cases :) With the other Qt styles you get true, which is the correct default value. Ok, I missed this one, thanks for the clarification! What I personally would like more is to always be able to read this. I of course can use a KSharedConfig::openConfig() and then read the config value myself. However, would it be of interest to have a static accessor for this? Downside is that there are quite a lot of kdeglobals dependent entries... Is the preferred way to read this value manually then in KatePart? Would that also be the preferred way in KMessageWidget? I don't really see what the issue is. Do you care that much for Windows users to be able to turn animations off? Nevermind, was a misunderstanding then. Another issue we have in Kate code: kdeglobals right now do not have this effects enabled by default. A unit test from kde4 times now fails in kf5, because the timings are different, because the effects are off. Are there plans to have a kdeglobals that has enabled effects? As I said, it's a bug in the readEntry() call above. The default is supposed to be 1, so you don't need a special kdeglobals. Ok, so who is going to fix it? ;) Hugo? Greetings, Dominik ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE-wide Animation settings
2014/1/4 David Faure fa...@kde.org: On Saturday 04 January 2014 23:02:35 Dominik Haumann wrote: What I personally would like more is to always be able to read this. I of course can use a KSharedConfig::openConfig() and then read the config value myself. However, would it be of interest to have a static accessor for this? Downside is that there are quite a lot of kdeglobals dependent entries... Is the preferred way to read this value manually then in KatePart? Would that also be the preferred way in KMessageWidget? I don't really see what the issue is. Do you care that much for Windows users to be able to turn animations off? Ideally on Windows we'd follow Windows settings rather than KDE apps having their own configuration. SystemParametersInfo(SPI_GETCLIENTAREAANIMATION) seems to get what we'd want. -- Nicolás ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel