Bug 308231

Created attachment 162391 [details]
screenshot

I just checked with the simple Image-animated.ycp UI example: The MNG animation looks normal (as expected), but the animated GIF looks very strange indeed.

The animated gif is correct, 'animate /usr/share/YaST2/theme/current/animations/ticks-loop3.gif' displays it like expected.

So the problem is either in yast2-qt or in the Qt library...

We tested this with MNG, which works nicely and is the documented way for the Qt UI. GIF was used for the sake of the Gtk-UI which does not support MNG.

The Qt UI uses standard Qt methods to display and animate those animations. But it looks like Qt (-3) does not display this animated GIF (don't know about others) correctly.

It has been made clear to us that there will be no more support for Qt-3 (other than security fixes, which this is clearly not).

dmueller said (in IRC) that the problem is that the first and the last frame of that GIF are not identical.

Apparently this is not a problem with MNGs (which use the same code with QMovie etc.), but it utterly disturbs display of an animated GIF.

Maybe this can be fixed in the artwork by making an animated GIF that meets the above requirement.

Maybe we should use the file format that works (MNG) so this animation actually fulfills its intention: Better eye candy while the user has to wait. But in that case, we have to think about what to do with the Gtk UI: Either not have it report it supports animations (which it does only half way: no MNG (*)) or (most likely a much more intrusive change) have it support MNG, too.




(*) The UI examples and the UI documentation use MNG everywhere. Even though there is no formal spec about that aspect of a YaST2 UI, it might have been concluded from that that MNG is the format of choice that should be supported if the UI indicates it has the "HasAnimationSupport" capability.

http://forgeftp.novell.com///yast/doc/SL10.2/tdg/Image_widget.html

Stano, Coolo, we need some decisions here:

(1) What do we do about this for 10.3 ?

    (a) leave it like this
    (b) use the MNG that works properly for Qt, but not at all for Gtk
    (c) make a new animated GIF that works properly for both
        (artwork help required - jimmac?)


(2) What do we do to avoid this in the future?

    (a) make the Gtk-UI report "false" for the "HasAnimationSupport"
        UI capability since it does not support the format of choice (MNG)
    (b) add MNG support to the Gtk-UI
    (c) officially drop support for MNG in both the Qt-UI to get down
        to the least common denominator

Please, leave the implementation as is for 10.3

For future:
- UI has to provide a busy progress or similar natively, no hack needed
- I think MNG support for Gtk-UI would be the best way

I think that the best solution for the future is to create a new native widget (`BusyProgress?) which will be handled by the UIs and drop this workaround.

So the look and feel of the indicator will depend on the UI which knows best it's own possibilities and limitations.

(In reply to comment #7 from Stanislav Visnovsky)
> Please, leave the implementation as is for 10.3

OK.

> For future:
> - UI has to provide a busy progress or similar natively, no hack needed

Definitely. We will need that at many places.

> - I think MNG support for Gtk-UI would be the best way

-> mmeeks

(In reply to comment #9 from Stefan Hundhammer)
> > - I think MNG support for Gtk-UI would be the best way
> 
> -> mmeeks

new bug# 308617 :yast2-gtk-ui does not support MNG animations

> > For future:
> > - UI has to provide a busy progress or similar natively, no hack needed
> 
> Definitely. We will need that at many places.

Added as fate #302559 :
http://keeper.suse.de:8080/webfate/match/id?value=302559&display-hint=yes

yast-gtk should render MNG-VCL animations fine now. But please test them, or just send me the file you want to use.

reopening

We have a new, shiny dedicated busy indicator now.