Who has implemented custom decorator classes?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Who has implemented custom decorator classes?

Fabian Jakobs
Administrator
Hi,

I plan to use the qooxdoo decorator classes to render some parts of the
virtual widgets. To do so I have change the API of the decorator
interface (qx.ui.core.decoration.IDecorator) a little. This change only
affects qooxdoo users, who have implemented their own decorator classes.
To get an idea of the impact of such a change I would be interested who
of you has written his/her own decorators?

Best Fabian

--
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG
Brauerstraße 48
76135 Karlsruhe

Amtsgericht Montabaur HRB 6484

Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Markus Huhn, Oliver Mauss, Achim Weiss
Aufsichtsratsvorsitzender: Michael Scheeren


------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Who has implemented custom decorator classes?

Andy Fuchs

1

;-)

a.


On 04.02.09 19:42, "Fabian Jakobs" <[hidden email]> wrote:

> Hi,
>
> I plan to use the qooxdoo decorator classes to render some parts of the
> virtual widgets. To do so I have change the API of the decorator
> interface (qx.ui.core.decoration.IDecorator) a little. This change only
> affects qooxdoo users, who have implemented their own decorator classes.
> To get an idea of the impact of such a change I would be interested who
> of you has written his/her own decorators?
>
> Best Fabian




------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Who has implemented custom decorator classes?

Sebastian Werner
In reply to this post by Fabian Jakobs
No, but I would be interested in your ideas :)

Sebastian


Fabian Jakobs schrieb:

> Hi,
>
> I plan to use the qooxdoo decorator classes to render some parts of the
> virtual widgets. To do so I have change the API of the decorator
> interface (qx.ui.core.decoration.IDecorator) a little. This change only
> affects qooxdoo users, who have implemented their own decorator classes.
> To get an idea of the impact of such a change I would be interested who
> of you has written his/her own decorators?
>
> Best Fabian
>


------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Internationalization

Andy Fuchs
In reply to this post by Andy Fuchs

If I create a localizable application, wouldn't it be nice to create a mixin
containing all localizable strings, instead of distributing the strings all
over the code...

Or are there any disadvantages with this approach (or other ideas)?

tia

andy




------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Who has implemented custom decorator classes?

Fabian Jakobs
Administrator
In reply to this post by Sebastian Werner
Hi Sebastian,
> No, but I would be interested in your ideas :)
>  
I want to use decorators in the layer, which renders the row
backgrounds. This layer uses plain HTML and DOM manipulations for fast
rendering. The decorators currently expect an instance of
"qx.html.Element" as first parameter in the "init", "resize" and "tint"
methods and this is a problem for me.

This is the way the widget uses the decorators right now:

1. create the decorator element as instance of "qx.html.Element"
2. initialize the decorator element:  decorator.init(decoratorelement)
  2.1 The init method in all qooxdoo decorators is the same and looks
like "decoratorElement.useMarkup(this.getMarkup());
3. after the widget's final size has been calculated be the layout
engine the decorator element is resized:
decorator.resize(decoratorElement, width, height);
  3.1 The resize method in all qooxdoo decorators first get the real DOM
element of the decorator element and only work with this DOM element

step three is repeated after each widget resize. This is how I plan to
use decorators in the widget:

1. create the decorator element as instance of "qx.html.Element"
2. initialize the decorator element:  
decoratorElement.useMarkup(decorator.getMarkup());
3. after the widget's final size has been calculated be the layout
engine the decorator element is resized:
decorator.resize(decoratorElement.getDomElement(), width, height);

As you see it is easy the change the decorators to only work with HTML
strings and DOM elements. The init method will be removed and the
"resize" and "tint" method will work with plain DOM elements. The
changes to qooxdoo's decorators and the widget code is minimal. The
benefit is that we are able to use decorators in areas where only HTML
and DOM operations are used.

Best Fabian



>> Hi,
>>
>> I plan to use the qooxdoo decorator classes to render some parts of the
>> virtual widgets. To do so I have change the API of the decorator
>> interface (qx.ui.core.decoration.IDecorator) a little. This change only
>> affects qooxdoo users, who have implemented their own decorator classes.
>> To get an idea of the impact of such a change I would be interested who
>> of you has written his/her own decorators?
>>
>> Best Fabian
>>
>>    
>
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
>  


--
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG
Brauerstraße 48
76135 Karlsruhe

Amtsgericht Montabaur HRB 6484

Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Markus Huhn, Oliver Mauss, Achim Weiss
Aufsichtsratsvorsitzender: Michael Scheeren


------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Who has implemented custom decorator classes?

Sebastian Werner
Fabian Jakobs schrieb:

> Hi Sebastian,
>> No, but I would be interested in your ideas :)
>>  
> I want to use decorators in the layer, which renders the row
> backgrounds. This layer uses plain HTML and DOM manipulations for fast
> rendering. The decorators currently expect an instance of
> "qx.html.Element" as first parameter in the "init", "resize" and "tint"
> methods and this is a problem for me.
>
> This is the way the widget uses the decorators right now:
>
> 1. create the decorator element as instance of "qx.html.Element"
> 2. initialize the decorator element:  decorator.init(decoratorelement)
>   2.1 The init method in all qooxdoo decorators is the same and looks
> like "decoratorElement.useMarkup(this.getMarkup());
> 3. after the widget's final size has been calculated be the layout
> engine the decorator element is resized:
> decorator.resize(decoratorElement, width, height);
>   3.1 The resize method in all qooxdoo decorators first get the real DOM
> element of the decorator element and only work with this DOM element
>
> step three is repeated after each widget resize. This is how I plan to
> use decorators in the widget:
>
> 1. create the decorator element as instance of "qx.html.Element"
> 2. initialize the decorator element:  
> decoratorElement.useMarkup(decorator.getMarkup());
> 3. after the widget's final size has been calculated be the layout
> engine the decorator element is resized:
> decorator.resize(decoratorElement.getDomElement(), width, height);
>
> As you see it is easy the change the decorators to only work with HTML
> strings and DOM elements. The init method will be removed and the
> "resize" and "tint" method will work with plain DOM elements. The
> changes to qooxdoo's decorators and the widget code is minimal. The
> benefit is that we are able to use decorators in areas where only HTML
> and DOM operations are used.

This is not a good solution. Not to say that it is quite bad. I see your
idea behind, but I think this kind of implementation is not good for
qooxdoo.

The issue is that when you directly modify DOM nodes is, that these
changes are not scheduled with the other framework changes. This is
basically a thing which we should not do. We have spend so many time to
make all these changes synchronous.

Another implementation would possibility would be to stay with using
qx.html.Element, and wrap the DOM nodes you want to modify by such an
element. Maybe using some kind of fly-weight pattern to keep memory
consumption down. This definitely needs some modifications to the
Element class (basically at useMarkup()). The benefits here are that you:

* keep the interface as it is
* keep using the style/attribute normalization provided by qx.html.Element

But now a little turnaround (after inspecting some decorators ;))

* the decorators mostly already use direct DOM access (the even use
qx.bom.XXX already)
* the interface change would maybe mean a more general usage pattern

But, to be consequent, the whole classes have to be moved somewhere else
as they are not exactly "ui" specific anymore.

So, finally, it seems that you have my OK ;)

Cheers,
Sebastian


>
> Best Fabian
>
>

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Who has implemented custom decorator classes?

Sebastian Werner
Just a note that the separator support in "Widget" also depends on this
interface

cheers,
Sebastian


Sebastian Werner schrieb:

> Fabian Jakobs schrieb:
>> Hi Sebastian,
>>> No, but I would be interested in your ideas :)
>>>  
>> I want to use decorators in the layer, which renders the row
>> backgrounds. This layer uses plain HTML and DOM manipulations for fast
>> rendering. The decorators currently expect an instance of
>> "qx.html.Element" as first parameter in the "init", "resize" and "tint"
>> methods and this is a problem for me.
>>
>> This is the way the widget uses the decorators right now:
>>
>> 1. create the decorator element as instance of "qx.html.Element"
>> 2. initialize the decorator element:  decorator.init(decoratorelement)
>>   2.1 The init method in all qooxdoo decorators is the same and looks
>> like "decoratorElement.useMarkup(this.getMarkup());
>> 3. after the widget's final size has been calculated be the layout
>> engine the decorator element is resized:
>> decorator.resize(decoratorElement, width, height);
>>   3.1 The resize method in all qooxdoo decorators first get the real DOM
>> element of the decorator element and only work with this DOM element
>>
>> step three is repeated after each widget resize. This is how I plan to
>> use decorators in the widget:
>>
>> 1. create the decorator element as instance of "qx.html.Element"
>> 2. initialize the decorator element:  
>> decoratorElement.useMarkup(decorator.getMarkup());
>> 3. after the widget's final size has been calculated be the layout
>> engine the decorator element is resized:
>> decorator.resize(decoratorElement.getDomElement(), width, height);
>>
>> As you see it is easy the change the decorators to only work with HTML
>> strings and DOM elements. The init method will be removed and the
>> "resize" and "tint" method will work with plain DOM elements. The
>> changes to qooxdoo's decorators and the widget code is minimal. The
>> benefit is that we are able to use decorators in areas where only HTML
>> and DOM operations are used.
>
> This is not a good solution. Not to say that it is quite bad. I see your
> idea behind, but I think this kind of implementation is not good for
> qooxdoo.
>
> The issue is that when you directly modify DOM nodes is, that these
> changes are not scheduled with the other framework changes. This is
> basically a thing which we should not do. We have spend so many time to
> make all these changes synchronous.
>
> Another implementation would possibility would be to stay with using
> qx.html.Element, and wrap the DOM nodes you want to modify by such an
> element. Maybe using some kind of fly-weight pattern to keep memory
> consumption down. This definitely needs some modifications to the
> Element class (basically at useMarkup()). The benefits here are that you:
>
> * keep the interface as it is
> * keep using the style/attribute normalization provided by qx.html.Element
>
> But now a little turnaround (after inspecting some decorators ;))
>
> * the decorators mostly already use direct DOM access (the even use
> qx.bom.XXX already)
> * the interface change would maybe mean a more general usage pattern
>
> But, to be consequent, the whole classes have to be moved somewhere else
> as they are not exactly "ui" specific anymore.
>
> So, finally, it seems that you have my OK ;)
>
> Cheers,
> Sebastian
>
>
>> Best Fabian
>>
>>
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Who has implemented custom decorator classes?

Fabian Jakobs
Administrator
Hi Sebastian,
> Just a note that the separator support in "Widget" also depends on this
> interface
>
>  
I have done the described changes to my local qooxdoo copy and it worked
without any structural changes to the framework classes. I think I will
go this way.

Best Fabian


>> Fabian Jakobs schrieb:
>>    
>>> Hi Sebastian,
>>>      
>>>> No, but I would be interested in your ideas :)
>>>>  
>>>>        
>>> I want to use decorators in the layer, which renders the row
>>> backgrounds. This layer uses plain HTML and DOM manipulations for fast
>>> rendering. The decorators currently expect an instance of
>>> "qx.html.Element" as first parameter in the "init", "resize" and "tint"
>>> methods and this is a problem for me.
>>>
>>> This is the way the widget uses the decorators right now:
>>>
>>> 1. create the decorator element as instance of "qx.html.Element"
>>> 2. initialize the decorator element:  decorator.init(decoratorelement)
>>>   2.1 The init method in all qooxdoo decorators is the same and looks
>>> like "decoratorElement.useMarkup(this.getMarkup());
>>> 3. after the widget's final size has been calculated be the layout
>>> engine the decorator element is resized:
>>> decorator.resize(decoratorElement, width, height);
>>>   3.1 The resize method in all qooxdoo decorators first get the real DOM
>>> element of the decorator element and only work with this DOM element
>>>
>>> step three is repeated after each widget resize. This is how I plan to
>>> use decorators in the widget:
>>>
>>> 1. create the decorator element as instance of "qx.html.Element"
>>> 2. initialize the decorator element:  
>>> decoratorElement.useMarkup(decorator.getMarkup());
>>> 3. after the widget's final size has been calculated be the layout
>>> engine the decorator element is resized:
>>> decorator.resize(decoratorElement.getDomElement(), width, height);
>>>
>>> As you see it is easy the change the decorators to only work with HTML
>>> strings and DOM elements. The init method will be removed and the
>>> "resize" and "tint" method will work with plain DOM elements. The
>>> changes to qooxdoo's decorators and the widget code is minimal. The
>>> benefit is that we are able to use decorators in areas where only HTML
>>> and DOM operations are used.
>>>      
>> This is not a good solution. Not to say that it is quite bad. I see your
>> idea behind, but I think this kind of implementation is not good for
>> qooxdoo.
>>
>> The issue is that when you directly modify DOM nodes is, that these
>> changes are not scheduled with the other framework changes. This is
>> basically a thing which we should not do. We have spend so many time to
>> make all these changes synchronous.
>>
>> Another implementation would possibility would be to stay with using
>> qx.html.Element, and wrap the DOM nodes you want to modify by such an
>> element. Maybe using some kind of fly-weight pattern to keep memory
>> consumption down. This definitely needs some modifications to the
>> Element class (basically at useMarkup()). The benefits here are that you:
>>
>> * keep the interface as it is
>> * keep using the style/attribute normalization provided by qx.html.Element
>>
>> But now a little turnaround (after inspecting some decorators ;))
>>
>> * the decorators mostly already use direct DOM access (the even use
>> qx.bom.XXX already)
>> * the interface change would maybe mean a more general usage pattern
>>
>> But, to be consequent, the whole classes have to be moved somewhere else
>> as they are not exactly "ui" specific anymore.
>>
>> So, finally, it seems that you have my OK ;)
>>
>> Cheers,
>> Sebastian
>>
>>
>>    
>>> Best Fabian
>>>
>>>
>>>      
>> ------------------------------------------------------------------------------
>> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
>> software. With Adobe AIR, Ajax developers can use existing skills and code to
>> build responsive, highly engaging applications that combine the power of local
>> resources and data with the reach of the web. Download the Adobe AIR SDK and
>> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
>> _______________________________________________
>> qooxdoo-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>>    
>
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
>  


--
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG
Brauerstraße 48
76135 Karlsruhe

Amtsgericht Montabaur HRB 6484

Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Markus Huhn, Oliver Mauss, Achim Weiss
Aufsichtsratsvorsitzender: Michael Scheeren


------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Internationalization

thron7
In reply to this post by Andy Fuchs


Andy Fuchs wrote:
> If I create a localizable application, wouldn't it be nice to create a mixin
> containing all localizable strings, instead of distributing the strings all
> over the code...
>
> Or are there any disadvantages with this approach (or other ideas)?
>  

No, it's a fairly common approach, AFAICT, mixins or dummy classes, you
name it. You just have to make sure you gather all possible strings, so
when you use variables in calls to tr() you don't end up with values
that haven't been listed in your mixin.

T.

> tia
>
> andy
>
>
>
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
>  

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Who has implemented custom decorator classes?

Noggin182
In reply to this post by Andy Fuchs
Make that 2!

Sorry for the late reply. We have created two custom decorator classes.
A tripple border that extends from qx.ui.decoration.Double and an inside
border that extends from qx.ui.decoration.Single (you may have seen this
in the code I posted to recreate the firefox bug a while ago).

We don't mind having to make changes if needs be though.

Thanks for the heads up,
Matt

Andy Fuchs wrote:

> 1
>
> ;-)
>
> a.
>
>
> On 04.02.09 19:42, "Fabian Jakobs" <[hidden email]> wrote:
>
>> Hi,
>>
>> I plan to use the qooxdoo decorator classes to render some parts of the
>> virtual widgets. To do so I have change the API of the decorator
>> interface (qx.ui.core.decoration.IDecorator) a little. This change only
>> affects qooxdoo users, who have implemented their own decorator classes.
>> To get an idea of the impact of such a change I would be interested who
>> of you has written his/her own decorators?
>>
>> Best Fabian
>
>
>
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com


------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel