Some random issues I've collected with workarounds

[Ralf Nieuwenhuijsen-2]

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
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Martin Wittemann]

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
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Alexander Back]

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
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Christian Schmidt-18]

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
>> qooxdoo-devel@...
>> <mailto:qooxdoo-devel@...>
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
>  
> ------------------------------------------------------------------------
>
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@...
> 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
schmidt.christian@...

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
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Ralf Nieuwenhuijsen-2]

>Good point. Can you please add a comment to the bug report mentioned above?
>Such input is highly appreciated.

Done.

>You just have to have a little patience with us ;-)

I will!

I was very much aware of the state of both the flash support and the animation support.
And I think it's all moving at great pace already. I especially like the fact that combinators (to combinate effects sequentially and concurrently)  are becoming a central feature.

I would however would love to see the time-range settings be moved out of animation object and added to the 'add' method.
Sort of like:

  myAnim1 = new  .. // some anim
  myAnim2 = new ...// another anim

  myAnim3 = new qx.core.effects.Parallel();
  myAnim3.add( myAnim1, {duration: "50%", delay: "25%"} );
  myAnim3.add( myAnim2, {duration: "100%" );

  myWidget.startAnimation( myAnim3, {duration: 6} )  // play the two animanations in parallel voor 6 seconds

Notice how it's very much like how we build up our widgets. The parrelel animation behaving like the Canvas of animations, and the Consequential combinator behaving like a HBox. (except in this case the dimension is time). 

Besides playAnimation, it would be also be nice to have repeatAnimation(), pauseAnimation() and stopAnimation() at the widget level.
I'll add this suggestion to the bug report as well for you guys to look into.

Greetings,
Ralf

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Alexander Back]

Hi Ralf,

many thanks for this detailed feedback!

cheers,
  Alex

On Monday 06 July 2009 Ralf Nieuwenhuijsen wrote:

> I will!
>
> I was very much aware of the state of both the flash support and the
> animation support.
> And I think it's all moving at great pace already. I especially like the
> fact that combinators (to combinate effects sequentially and concurrently)
> are becoming a central feature.
>
> I would however would love to see the time-range settings be moved out of
> animation object and added to the 'add' method.
> Sort of like:
>
>   myAnim1 = new  .. // some anim
>   myAnim2 = new ...// another anim
>
>   myAnim3 = new qx.core.effects.Parallel();
>   myAnim3.add( myAnim1, {duration: "50%", delay: "25%"} );
>   myAnim3.add( myAnim2, {duration: "100%" );
>
>   myWidget.startAnimation( myAnim3, {duration: 6} )  // play the two
> animanations in parallel voor 6 seconds
>
> Notice how it's very much like how we build up our widgets. The parrelel
> animation behaving like the Canvas of animations, and the Consequential
> combinator behaving like a HBox. (except in this case the dimension is
> time).
>
> Besides playAnimation, it would be also be nice to have repeatAnimation(),
> pauseAnimation() and stopAnimation() at the widget level.
> I'll add this suggestion to the bug report as well for you guys to look
> into.

------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Ralf Nieuwenhuijsen-2]

On Mon, Jul 6, 2009 at 1:37 PM, Christian Schmidt <schmidt.christian@...> wrote:

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

Hmm. I can't reproduce it either!
I'm not sure what my bug was, I eventually rewrote that part to load the contents of tab-pages on demand, so the offending code is no longer present in my project as well.
Perhaps I was just chasing ghosts.
 

3) Could you please open a bug report for this.

Done: http://bugzilla.qooxdoo.org/show_bug.cgi?id=2552

PS. It would be really cool if we could submit bug reports straight from the PlayGround editor, with the code attached, so people can try the same code on different architectures.
And visa-versa to have the code of all open bugs be available in the PlayGround and/or Demo/Test-Viewer.

Greetings,
Ralf

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Christian Schmidt-18]

Perfect, thank you!

Ralf Nieuwenhuijsen schrieb:

> On Mon, Jul 6, 2009 at 1:37 PM, Christian Schmidt
> <schmidt.christian@... <mailto:schmidt.christian@...>> wrote:
>
>     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
>
>
> Hmm. I can't reproduce it either!
> I'm not sure what my bug was, I eventually rewrote that part to load
> the contents of tab-pages on demand, so the offending code is no
> longer present in my project as well.
> Perhaps I was just chasing ghosts.
>  
>
>     3) Could you please open a bug report for this.
>
>
> Done: http://bugzilla.qooxdoo.org/show_bug.cgi?id=2552
>
> PS. It would be really cool if we could submit bug reports straight
> from the PlayGround editor, with the code attached, so people can try
> the same code on different architectures.
> And visa-versa to have the code of all open bugs be available in the
> PlayGround and/or Demo/Test-Viewer.
>
> Greetings,
> Ralf
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
>  
> ------------------------------------------------------------------------
>
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@...
> 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
schmidt.christian@...

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
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel