Animated labels and progress bars in Oxygen considered harmful?
Hugo Pereira Da Costa
hugo at oxygen-icons.org
Wed Dec 2 15:33:59 GMT 2009
On 12/02/2009 03:49 AM, Robert Knight wrote:
>> its feasible if we agree on some QObject "dynamic property" name, that one application could set, (QObject::setProperty( ... ))
>> and that the style would catch. Something like "_kde_no_animation_".
>>
>
>> Problem is: you can't expect 3rd party KDE (or Qt) applications to set
>> this property.
>>
> Indeed. As Thiago mentioned, if you try to go too far beyond what the
> QStyle API was designed for this could well lead
> to breakages in 3rd party applications (whether they are open
> source/libre software or not) - leading to the unfortunate situation
> where these applications work better on
> Windows/Gnome/Mac OS X than on KDE.
>
Hi Robert,
I don't agree with your point. In the situation you describe above, you
would have animations that look better on Windows/Gnome/Mac Os than on
KDE +With Oxygen+. You can switch style, fork style (e.g. Ozone). IMO
KDE is _not_ oxygen (although I'd love too :-)). I'd think that people
would switch style before switching OS. (In fact, some distributions do
not even come with oxygen style as the default. E.g. mandriva).
And in quite some people's mind, the above (look better on windows etc.
than with oxygen) already happens (cause oxygen as too little contrast,
too dull backgrounds; etc.). I don't think label's animations (appart
from bug), changes the situation dramatically.
> Regards,
> Robert.
>
>
> 2009/12/2 Marco Martin<notmart at gmail.com>:
>
>> On Wednesday 02 December 2009, Aurélien Gâteau wrote:
>>
>>> Hi,
>>>
>>> This evening I was busy polishing the tooltips which appear over
>>> Gwenview tooltips (current ones are a bit crappy). These tooltips are
>>> implemented using QLabel instead of QToolTip because QLabel provide
>>> precise positioning.
>>>
>>> One of the bugs I noticed was that when the mouse moved from item1 to
>>> item2, the tooltip label would be immediatly moved to item2, but it
>>> would still display item1 text for a few seconds.
>>>
>>> It turned out this was caused by the Oxygen widget style animating the
>>> change of label text. I can probably work around this by using a custom
>>> widget instead of a QLabel, but I believe it would be the wrong fix.
>>> Oxygen goes too far in my opinion, and should not try to animate labels
>>> behind the developer's back.
>>>
>> if i understood correctly it does appen the following:
>> -mouse over an image it shows a tooltip
>> -mouse over another image, the tooltip disappears, appears over the new image
>> and the text fades, right?
>>
>> so what should be done in the style is simply disable the animatin if the
>> widget, or any of his parent hyerarchy is not visible.
>>
>> (even tough i would prefer for tooltips that they would just slide to the new
>> position with fading text, without the magical disappear and appear, but
>> that's another story)
>>
>> the behabiour it has now feels way more natural, it has quirks for sure (we're
>> having sme ugly problems with proxywidgets for them but nothing that can't be
>> overcomed i think), becase it's young, but shouldn't be killed only because
>> oh, noes! it's not how computer worked!
>>
>>
>>> The "Animated progress bars" option is also probably problematic as I
>>> guess it is the cause of the strange behavior of the "Get Hot New Stuff"
>>> dialog (if you click "Install" on several items in a short while, the
>>> progress bar goes back and forth).
>>>
>> i see nothing wrong with that, it looks more natural to me
>>
>> Cheers,
>> Marco Martin
>>
>>
More information about the kde-core-devel
mailing list