https://bugs.kde.org/show_bug.cgi?id=365628
Hugo Pereira Da Costa <hugo.pereira.da.co...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hugo.pereira.da.costa@gmail
| |.com
--- Comment #1 from Hugo Pereira Da Costa <hugo.pereira.da.co...@gmail.com> ---
Hi Christoph
this ... is complicated.
right now breeze (and oxygen) style return the value from parent kstyle, which
in turn reads:
KConfigGroup g(KSharedConfig::openConfig(), "KDE-Global GUI Settings");
return g.readEntry("GraphicEffectsLevel", true);
This option is defined in the fine tuning kcm, is a combobox with many choices,
such as "low display resolution and high cpu", "low display resolution and very
high cpu", "high display resolution and low cpu", etc.
Based on this code, only the first combobox entry (low resolution low cpu)
disable SH_Widget_Animate
So I can either:
1/ overwrite this in oxygen and breeze and use their own "disable animations"
flag;
2/ Or remove the disable animations option and rely on this combobox instead.
3/ leave it as it is now.
To be honest, I would vote for 1/ (which you suggest) or 3/ (as it is now)
because I am really not happy about this fine tuning combobox.
Personally I have no clue what high or low cpu means, (especially these days
where we have multiple cores) , nor high and low screen resolutions (especially
since we can plug the same computer on multiple screens of the different
resolution)
Besides, on the developer side, I have no clue how to turn these multiple
choices into a "should I enable this animation or not".
Your opinion ?
You still think I should switch to sync SH_Widget_Animate with breeze/oxygen
internal "enable animations" options ?
What about this graphical effects level ? Should this guy be revisited, removed
?
--
You are receiving this mail because:
You are watching all bug changes.
