Hi Ralf,
I will try to answer your questions 2 and 3.
2) I have tried to reproduce your issue, but I couldn't reproduce it.
With my example I always get one event fired. Could you please send a
code snippet that reproduce your issue. Thanks
3) Could you please open a bug report for this.
Thanks,
Chris
Martin Wittemann schrieb:
> 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]
>> <mailto:[email protected]>
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
--
Christian Schmidt
Software Entwickler
1&1 Internet AG - Web Technologies
Ernst-Frey-Straße 9 · DE-76135 Karlsruhe
[email protected]
Amtsgericht Montabaur / HRB 6484
Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas
Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver
Mauss, Jan Oetjen
Aufsichtsratsvorsitzender: Michael Scheeren
------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
