Re: KDE-wide Animation settings

2014-01-05 Thread Martin Graesslin
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

2014-01-05 Thread Hugo Pereira Da Costa

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

2014-01-05 Thread Hugo Pereira Da Costa

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

2014-01-05 Thread Hugo Pereira Da Costa

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

2014-01-05 Thread Martin Graesslin
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

2014-01-05 Thread David Faure
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

2014-01-05 Thread David Faure
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

2014-01-04 Thread Hugo Pereira Da Costa

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

2014-01-04 Thread David Faure
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

2014-01-04 Thread Hugo Pereira Da Costa

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

2014-01-04 Thread David Faure
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

2014-01-04 Thread Dominik Haumann
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

2014-01-04 Thread David Faure
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

2014-01-04 Thread Dominik Haumann
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-01-04 Thread Nicolás Alvarez
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