Hi Ralf,
On Sunday 05 July 2009 Ralf Nieuwenhuijsen wrote:
> *1. You can't change the source url of an PNG image, nor can you destroy
> the image container, on IE6/IE7.
> *The error message is actually given by qooxdoo itself, unfortunately, it
> is only triggered on IE.
>
> Workarounds:
> - use another format if the image needs to be changeable or destroyable
> - set visibility to Hidden and use a canvas element. Be aware that this
> solution costs increasingly more memory. But if the set of possible images
> is going to be fixed size, not really a problem.
>
> Why this isn't a real bug:
> - it seems a normal limitation of the png-transparency hack. It would be
> nice if this bug would always throw, also on other browser though!
Yes, it is a limitation and we're already aware of it. Take a look at
http://bugzilla.qooxdoo.org/show_bug.cgi?id=1896
and
http://bugzilla.qooxdoo.org/show_bug.cgi?id=1909
Both bugs are addressing this issues.
> *5. Animations can only be added to widgets that are already on the screen!
> *The actual code to create an animation seems really low-level as well. You
> have to get a dom-node which only exists if a widget has 'appeared' on the
> screen.
Animations are still only implemented at low-level. This issue is already
reported at http://bugzilla.qooxdoo.org/show_bug.cgi?id=1635
> Why this isn't a real bug:
> - It's just a questionable api design choice here. I would prefer to be
> able to to either add the animation to the widget and have the dom-details
> handeled by Qooxdoo.
This is exactly what a implementation at widget-level would do :)
> A nice bonus of such an architecture would be that we could reuse animation
> objects!
> (Perhaps we already can but it wasn't very clear! I just create a new
> animation object for each and every subsequent animation)
Good point. Can you please add a comment to the bug report mentioned above?
Such input is highly appreciated.
> *6. You can't add an animation to a qx.ui.basic.image! *
This will be addressed by Bug #1635.
> *7. The positional modes of qx.fx.effect.core.Move 'absolute' and
> 'relative' do not do what you think they do.*
> They are about whether positions are relative or absolute compared to the
> initial position of the widget. They are about subsequent animations, for
> one single animation they two modes do the exact same thing.
>
> Workaround:
> - to get a true 'absolute' position subtract the qooxdoo-top and
> qooxdoo-left properties of widgets
> - to get a true 'relative' position call it 'absolute'.
> - to get the subsequent 'relative' positions: either use 'relative' or
> update the qooxdoo-left and qooxdoo-top when the animation finishes.
>
> Why this isn't a real bug:
> - it's just a matter of explaining the implementation better in the
> documentation I guess. The behavior where the animations take place in
> another realm and not deal with layout managers, seems the preferred
> choice, it's just that this choice should be communicated.
These issues will also be addressed with animations at widget level.
You just have to have a little patience with us ;-)
cheers,
Alex
------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
