I've had to create an app in an extreme hurry to save somebody's ass. ( a
2000 lines of qooxdoo code and my coworker working flash in 48 hours with no
sleep ;-)
In the procces i've found some weird behaviors, that I quickly wrote away.
This is the summery of those issues. Perhaps some are real bugs, but most
are not. These issues apply to the trunk ( i needed the flash embed! ),
some may also apply to older versions.
At the very least I wasn't able at that time, to do proper investigation.
There are here for your information, perhaps you'll come across some of them
as well. Perhaps some, now I have the time, warrant further investigation.
*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!
*2. TabView throws two changeSelection events when the user actually clicks
on another tab*.
I dunno why. Perhaps first to deselect the current tab and then to select
the new tab?
Workarounds:
- ignore one of the two
- make your app reliable enough to not care about it being thrown twice
Why this isn't a real bug:
- It is defendable that inbetween tab 1 and tab 2 being selected, no tab is
selected. It might be nice to have the guarantee that a TabView never ever
has a null-selection.
*3. Embedding flash, if resized, doesn't deal with focus properly on
Linux/FF combination.*
If you click on the flash widget, it adds focus borders and input events
from that point do not enter the flash app. Click somewhere else to make it
loose 'qooxdoo' focus and then the next click will be registered.
Workarounds:
- call setTabIndex(1); on the flash widget. Dunno why this works, but it
makes the problem go away.
Why this isn't a real bug:
- It's an alpha version of flash, and I haven't been able to pinpoint the
exact preconditions that trigger this.
*4. Input event is deprecated now.*
And keypress isn't really a valid alternative, since it is thrown _before_
the value actually changes
Workarounds:
- just use changeValue and turn on and use 'myTextField.setLiveUpdate(
true );'
Why this isn't a real bug:
- The workaround is a much nicer construct. It just took a while to figure
out the new alternative. Perhaps it would be nice if the error message would
talk about setLiveUpdate.
*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.
Workarounds:
- move your animation creation code into an myWidget.addListener('appear',
function(){
// put it here!
}), myWidget);
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.
What about just adding a:
// sort of pseudo-code to explain the idea
qx.ui.core.Widget.startAnimation: function( vAnim ){
if( this.getContainerElement().getDomElement() ){
vAnim.setTargetNode( this.getContainerElement().getDomElement() ); //
this method should be made available obviously
vAnim.start();
} else {
this.addListenerOnce('appear', function() {
vAnim.setTargetNode( this.getContainerElement().getDomElement() );
// this method should be made available obviously
vAnim.start();
}, this);
}
}
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)
*6. You can't add an animation to a qx.ui.basic.image! *
Workaround:
- You need to put it into a qx.ui.container.Composite or
qx.ui.container.Basic .. first, and add the animation to that.
Why this isn't a real bug:
- it seems logical you can't add animation to all types of gui objects, but
at least it should throw a decent error message.
*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.
Greetings,
Ralf
------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
