Hello Ralf,
first of all thank you very much for the detailed description. This
gives us a good insight into your problems during the development.
Im not the expert in all of your mentioned fields so I just pick some
of the statements and try to comment on them. Alex and Christian will
sure take care of the rest. :)
4. Thats right. You sure know that the trunk is moving fast and so the
input event is not deprecated anymore. We decided to offer both
possibilities, the input event or the changeValue event with
liveUpdate switched to true. So nothing you should care about in the
written application. Just for your information that you could use both
events next time.
Best wished,
Martin
Am 05.07.2009 um 16:26 schrieb Ralf Nieuwenhuijsen:
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
------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
