Animated labels and progress bars in Oxygen considered harmful?

[Marco Martin]

On Wednesday 02 December 2009, Aurélien Gâteau wrote:
> 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.

instead i expect that applications won't have control on things like mouseover 
effects or simple transition at all, those are just details in the look, that 
the application developer shouldn't care nor control in any way

> 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.

a qstyle is not "supposed" to implement a thing or another, even tough is true 
that a new api is baadly needed, said new api could or could not have the 
ability to do animations and if it will it would have the exact same problems.
i think it would be betterto adapt applications to the idea that styles will 
be animated, because in the future all will be (at least, hopefully :p)

-- 
Marco Martin