Animated labels and progress bars in Oxygen considered harmful?

Aurélien Gâteau agateau at kde.org
Wed Dec 2 17:43:58 GMT 2009


Hugo Pereira Da Costa a écrit :
> On 12/02/2009 10:15 AM, Aurélien Gâteau wrote:
>> Hugo Pereira Da Costa wrote:
>>> On 12/02/2009 09:27 AM, Aurélien Gâteau wrote:
>>>> Hugo Pereira Da Costa wrote:
>>>>> On 12/02/2009 06:48 AM, Stefan Majewsky wrote:
>>>>>> Am Mittwoch, 2. Dezember 2009 09:43:57 schrieb Aurélien Gâteau:
>>>>>>> The widget is not changed behind
>>>>>>> the developer back.
>>>>>> I think the important point is not that this was changed behind the
>>>>>> developer's back,
>>>>>
>>>>> In fact thinking about it: isn't the whole idea of QStyle/KStyle to
>>>>> change widgets behind the developer's back ? When we (Nuno or I)
>>>>> change the tab shape, or the main window background gradients, or
>>>>> the checkmark in radio buttons, we do all that behind dev's back
>>>>> don't we ?
>>>>> So now there is a limit to what a style can and cannot change, and
>>>>> I don't know where it is. I've read reports that bespin did pass
>>>>> the limit (e.g. by adding specific hacks for dedicated
>>>>> applications), and oxygen might well have passed it with e.g.
>>>>> qlabel animations. If this is the case, well, fine, I can remove
>>>>> the animation. But again, this is not obvious to me where the limit
>>>>> is and this might need further discussion (or specification).
>>>>
>>>> I think the limit can be stated like this: a style should not have
>>>> side effects on existing code. For example if I write this:
>>>>
>>>> label->setText("Foo");
>>>> label->adjustSize();
>>>> QSize size = label->size();
>>>>
>>>> Then I expect 'size' to contain the size needed by 'label' to
>>>> display "Foo", not the size needed to display the previous content.
>>> mmm. That's what it is now (and if the old text is displayed during
>>> the animation, it is truncated).
>>> Or do I get it wrong ?
>>
>> I must confess I haven't tested it. Thinking of it, you are probably
>> right this will return a correct value.
>>
>> Still I consider this change a regression. If it's not reverted, I
>> will have to write a custom widget because QLabel can't be trusted
>> anymore.
> if you are planning to do that, I think it is easier to call
> QLabel::setProperty( "_kde_animate", false) (as kdepepo suggested) than
> rewritting a class. Is it not ?

No because I consider this is the wrong way to fix it. Application code
is supposed to be independent from the Qt style.

Thinking a bit more about what you asked (where is the limit), I think
the limit is that developers expect the style to do rendering, not
animations. A style should focus on look, not behavior. Animations
should be implemented either at the library or at the application level.

I can imagine you probably feel limited with the current QStyle API, but
I believe the correct answer is to join Thiago and help Qt developers
define a better style API for WidgetsNG. In the meantime, Oxygen style
should implement what a QStyle is supposed to implement.

Aurélien




More information about the kde-core-devel mailing list