Anyone needs switching locales and themes at runtime?

[Fabian Jakobs-2]

Hi,

for 0.8 we are considering to remove two feature currently available in
0.7. We are very interested how you feel about this.

1. No longer support switching locales/languages of the application at
runtime.

While it looks like a nice feature the actual usefulness seems pretty
low. Most applications (e.g. gmx.com) change the locale only after a
restart. Changing the locale is not a common action and it may be OK to
require a reload to apply the change.  None of the other toolkits
support the dynamic change. dojo and GWT determine the locale at
application startup either through URL parameters or other static resources.

The cost of having the dynamic approach is:

 - for each translatable string (this.tr("...")) in the application we
have to keep an instance of qx.locale.LocalizedString
 - in each widget (mostly labels) we need to keep a connection to the
localized string and listen for locale changes
 - each widget has to be prepared to handle localized strings in each
place where a normal string, which is shown at the screen, is expected.
If it gets a localized string it must establish a connection to the
locale manager to listen for locale changes and update the displayed string.
 - At startup, all translated strings for all possible locales must be
transferred together with the application
 - some widgets need special and sometimes complex code  to handle
locale changes at runtime:
   - DateChooser
   - DateChooserButton
   - ComboBox
   - Button
   - Table

Being able to change the locale at runtime comes with a cost and we
think the cost is too high to justify this feature.
<http://bugzilla.qooxdoo.org/show_bug.cgi?id=871>


2. No longer support changing the theme at runtime

Basically the same arguments apply to theming. Changing the theme at
runtime requires us to always keep a connection between the widgets and
the associated theme entries. This costs runtime performance, memory and
increases the complexity of the widgets.
<http://bugzilla.qooxdoo.org/show_bug.cgi?id=861>


I know both features are cool but do we really NEED it. Does anyone
depend on one of the mentioned features or plans to use them? We really
like to know how you feel about this.


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


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[asaris]

I agree with you. I do speak 3 languages and have experience building
multi language solutions. There's no need for these features at runtime.

asaris

Fabian Jakobs wrote:

> Hi,
>
> for 0.8 we are considering to remove two feature currently available in
> 0.7. We are very interested how you feel about this.
>
> 1. No longer support switching locales/languages of the application at
> runtime.
>
> While it looks like a nice feature the actual usefulness seems pretty
> low. Most applications (e.g. gmx.com) change the locale only after a
> restart. Changing the locale is not a common action and it may be OK to
> require a reload to apply the change.  None of the other toolkits
> support the dynamic change. dojo and GWT determine the locale at
> application startup either through URL parameters or other static resources.
>
> The cost of having the dynamic approach is:
>
>  - for each translatable string (this.tr("...")) in the application we
> have to keep an instance of qx.locale.LocalizedString
>  - in each widget (mostly labels) we need to keep a connection to the
> localized string and listen for locale changes
>  - each widget has to be prepared to handle localized strings in each
> place where a normal string, which is shown at the screen, is expected.
> If it gets a localized string it must establish a connection to the
> locale manager to listen for locale changes and update the displayed string.
>  - At startup, all translated strings for all possible locales must be
> transferred together with the application
>  - some widgets need special and sometimes complex code  to handle
> locale changes at runtime:
>    - DateChooser
>    - DateChooserButton
>    - ComboBox
>    - Button
>    - Table
>
> Being able to change the locale at runtime comes with a cost and we
> think the cost is too high to justify this feature.
> <http://bugzilla.qooxdoo.org/show_bug.cgi?id=871>
>
>
> 2. No longer support changing the theme at runtime
>
> Basically the same arguments apply to theming. Changing the theme at
> runtime requires us to always keep a connection between the widgets and
> the associated theme entries. This costs runtime performance, memory and
> increases the complexity of the widgets.
> <http://bugzilla.qooxdoo.org/show_bug.cgi?id=861>
>
>
> I know both features are cool but do we really NEED it. Does anyone
> depend on one of the mentioned features or plans to use them? We really
> like to know how you feel about this.
>
>
> Best Fabian
>
>  

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Natsukawa]

Am Fr, 13.06.2008, 12:17, schrieb Fabian Jakobs:
> Hi,
>
>
> 1. No longer support switching locales/languages of the application at
> runtime.
>

I use this feature. I have a GUI, which is started and then used by
different persons. So they should choose the language they like, when they
use it. So I would be really happy, if this feature is still supported
because new loading of the whole application costs a lot of time,
espacially if you are inside a work flow.

Maria



-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Sebastian Werner]

Maria Siebert schrieb:

> Am Fr, 13.06.2008, 12:17, schrieb Fabian Jakobs:
>> Hi,
>>
>>
>> 1. No longer support switching locales/languages of the application at
>> runtime.
>>
>
> I use this feature. I have a GUI, which is started and then used by
> different persons. So they should choose the language they like, when they
> use it. So I would be really happy, if this feature is still supported
> because new loading of the whole application costs a lot of time,
> espacially if you are inside a work flow.

Interesting. Is this some type of multi-user terminal? How does it work
exactly? Do they switch every few hours or even more often?

Sebastian

>
> Maria
>
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@...
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Tobias Oetiker-3]

Hi Fabian,

> for 0.8 we are considering to remove two feature currently available in
> 0.7. We are very interested how you feel about this.
>
> 1. No longer support switching locales/languages of the application at
> runtime.
>
> While it looks like a nice feature the actual usefulness seems pretty
> low. Most applications (e.g. gmx.com) change the locale only after a
> restart. Changing the locale is not a common action and it may be OK to
> require a reload to apply the change.  None of the other toolkits
> support the dynamic change. dojo and GWT determine the locale at
> application startup either through URL parameters or other static resources.
>
> The cost of having the dynamic approach is:
>
>  - for each translatable string (this.tr("...")) in the application we
> have to keep an instance of qx.locale.LocalizedString
>  - in each widget (mostly labels) we need to keep a connection to the
> localized string and listen for locale changes
>  - each widget has to be prepared to handle localized strings in each
> place where a normal string, which is shown at the screen, is expected.
> If it gets a localized string it must establish a connection to the
> locale manager to listen for locale changes and update the displayed string.
>  - At startup, all translated strings for all possible locales must be
> transferred together with the application
>  - some widgets need special and sometimes complex code  to handle
> locale changes at runtime:
>    - DateChooser
>    - DateChooserButton
>    - ComboBox
>    - Button
>    - Table
>
> Being able to change the locale at runtime comes with a cost and we
> think the cost is too high to justify this feature.
> <http://bugzilla.qooxdoo.org/show_bug.cgi?id=871>

our major customer deployed application uses this active language
switching feature, and people quite like it, but I guess if
language switching was possible through a reload, this would be
fine too, if the benefits are so great ...

> 2. No longer support changing the theme at runtime
>
> Basically the same arguments apply to theming. Changing the theme at
> runtime requires us to always keep a connection between the widgets and
> the associated theme entries. This costs runtime performance, memory and
> increases the complexity of the widgets.
> <http://bugzilla.qooxdoo.org/show_bug.cgi?id=861>
>
>
> I know both features are cool but do we really NEED it. Does anyone
> depend on one of the mentioned features or plans to use them? We really
> like to know how you feel about this.

In my eyes both features are great to convince people about the
coolness of qooxdoo, in production I don't see that much value.
Couldn't there be an aproach where there are two tr objects, one
which is active and one which is smaller, faster but not acitve ?

cheers
tobi

--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten
http://it.oetiker.ch tobi@... ++41 62 213 9902

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Natsukawa]

Am Fr, 13.06.2008, 12:46, schrieb Sebastian Werner:

> Maria Siebert schrieb:
>
>> Am Fr, 13.06.2008, 12:17, schrieb Fabian Jakobs:
>>
>>> Hi,
>>>
>>>
>>>
>>> 1. No longer support switching locales/languages of the application
>>> at runtime.
>>>
>>
>> I use this feature. I have a GUI, which is started and then used by
>> different persons. So they should choose the language they like, when
>> they use it. So I would be really happy, if this feature is still
>> supported because new loading of the whole application costs a lot of
>> time, espacially if you are inside a work flow.
>
> Interesting. Is this some type of multi-user terminal? How does it work
> exactly? Do they switch every few hours or even more often?
>

The app is an administration form for doormen. Since there can be more
doormen using one computer for a bigger building. So they change using of
the app because its only a small part of their job. Since the app is also
used in the netherlands, the doormen like to change between english and
german easily, since some of them are better in german and other in
english.

Maria



-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Fabian Jakobs-2]

Hi Tobias,

>> for 0.8 we are considering to remove two feature currently available in
>> 0.7. We are very interested how you feel about this.
>>
>> 1. No longer support switching locales/languages of the application at
>> runtime.
>>
>> While it looks like a nice feature the actual usefulness seems pretty
>> low. Most applications (e.g. gmx.com) change the locale only after a
>> restart. Changing the locale is not a common action and it may be OK to
>> require a reload to apply the change.  None of the other toolkits
>> support the dynamic change. dojo and GWT determine the locale at
>> application startup either through URL parameters or other static resources.
>>
>> The cost of having the dynamic approach is:
>>
>>  - for each translatable string (this.tr("...")) in the application we
>> have to keep an instance of qx.locale.LocalizedString
>>  - in each widget (mostly labels) we need to keep a connection to the
>> localized string and listen for locale changes
>>  - each widget has to be prepared to handle localized strings in each
>> place where a normal string, which is shown at the screen, is expected.
>> If it gets a localized string it must establish a connection to the
>> locale manager to listen for locale changes and update the displayed string.
>>  - At startup, all translated strings for all possible locales must be
>> transferred together with the application
>>  - some widgets need special and sometimes complex code  to handle
>> locale changes at runtime:
>>    - DateChooser
>>    - DateChooserButton
>>    - ComboBox
>>    - Button
>>    - Table
>>
>> Being able to change the locale at runtime comes with a cost and we
>> think the cost is too high to justify this feature.
>> <http://bugzilla.qooxdoo.org/show_bug.cgi?id=871>
>>    
>
> our major customer deployed application uses this active language
> switching feature, and people quite like it, but I guess if
> language switching was possible through a reload, this would be
> fine too, if the benefits are so great ...
>
>  
>> 2. No longer support changing the theme at runtime
>>
>> Basically the same arguments apply to theming. Changing the theme at
>> runtime requires us to always keep a connection between the widgets and
>> the associated theme entries. This costs runtime performance, memory and
>> increases the complexity of the widgets.
>> <http://bugzilla.qooxdoo.org/show_bug.cgi?id=861>
>>
>>
>> I know both features are cool but do we really NEED it. Does anyone
>> depend on one of the mentioned features or plans to use them? We really
>> like to know how you feel about this.
>>    
>
> In my eyes both features are great to convince people about the
> coolness of qooxdoo, in production I don't see that much value.
>  

This is exactly my impression, too. The key question is: Is this
coolness worth the price.

> Couldn't there be an aproach where there are two tr objects, one
> which is active and one which is smaller, faster but not acitve ?
>  

The main reasons to cut this feature are performance and complexity.
With this dual approach we could improve the performance but would
increase the complexity even more. For me the choice for both, locale
and theme switches, is between "implementing it as it is in 0.7" or
"removing the functionality".

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


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Tobias Oetiker-3]

Hi Fabian,

> > In my eyes both features are great to convince people about the
> > coolness of qooxdoo, in production I don't see that much value.
> >
> This is exactly my impression, too. The key question is: Is this
> coolness worth the price.

well I think this is a major issue with webstuff. At least for me,
I first look at the demo and then I look further.

For me the reason to start looking into qooxdoo was, that I went to
the demo page and was totaly impressed by the pixel perfect layout
on linux and when I saw that it even works on ie6 safari, opera I
knew that this was a  framework I wanted to spend time exporing.
Only then did I discover the inner beauty of it and all the cool oo
features that make writing qooxdoo applications so much fun.

but if the demos hadn't been so imressive, I would not have bothered
to look on ...

cheeers
tobi



--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten
http://it.oetiker.ch tobi@... ++41 62 213 9902

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Helder Magalhães]

Fabian Jakobs-2 wrote:

for 0.8 we are considering to remove two feature currently available in
0.7. We are very interested how you feel about this.

1. No longer support switching locales/languages of the application at
runtime.
2. No longer support changing the theme at runtime

I know both features are cool but do we really NEED it. Does anyone
depend on one of the mentioned features or plans to use them? We really
like to know how you feel about this.

Supporting runtime switching these is awsome from the "coolness" point of view. Helps popping those "wow" in demos, I believe! ;-)

On the other hand, considering implementation is costly and currently experiencing some issues (such as issue 764 [1]), IMHO I'd agree with you and remove them in order to enhance performance and decrease memory usage.

Regards,

  Helder Magalhães

[1] http://bugzilla.qooxdoo.org/show_bug.cgi?id=764

[Derrell Lipman]

On Fri, Jun 13, 2008 at 6:17 AM, Fabian Jakobs <fabian.jakobs@...> wrote:

1. No longer support switching locales/languages of the application at
runtime.

I have no strong opinion on #1.  The only problem I see is, living in the US, our national language is about to change from English to Spanish. :-)

2. No longer support changing the theme at runtime

This one I have a stronger opinion about.  Not only is this a must-see feature in any demo of qooxdoo (I use that as a key portion of my demos with showcase), but I also don't know of any other frameworks that support themes/skins that don't allow run-time switching.  People like to try out different themes.  If the like them, they keep them; otherwise they switch back or try a different one.  (Consider KDE, Windows,  various music applications, etc.)  In no case that I can think of does it require a restart to see a new theme.

I believe that them changes should continue to be dynamically available.

Cheers,

Derrell
 

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Mike Rea]

I know both features are cool but do we really NEED it. Does anyone
depend on one of the mentioned features or plans to use them? We really
like to know how you feel about this.
/quote>

So many great points on both sides of this argument.  I, like many others, was initially won over by qooxdoo due to the impressiveness of the demos, including the run-time theme-switching and localization.

However, as qooxdoo matures, I believe the keys to greater adoption & long-term success will be simplicity and performance.  Many great demos will woo developers to try qooxdoo, even without run-time theme switching and localization.  The improved performance and simplicity may be reasons for developers to stick with qooxdoo.

Here's a few reasons why I think it's OK to remove run-time theme-switching:

1.) Performance:  Very few users will really need run-time theme and localization switching.  Every user of every application is subjected to that application's performance.  If qooxdoo is 10% slower than Ext JS due to rarely used features, is it worth it?  To me, no.  I'd rather go with performance.

2.) Competitive landscape:  Sacrificing run-time switching doesn't place qooxdoo at any competitive disadvantage relative to the other frameworks.  However, if performance is not on par with other frameworks, it would be a disadavantage

3.) Wow-factors: Qooxdoo has a lot of other wow-factors, and it's soon going to have many more.  These will enthuse potential adopters in lieu of the current theme-switching.

4.) Simplicity -> translation: Development velocity.  If keeping run-time switching slows development efforts that are going to bring additional widgets to the toolkit, then the opportunity cost could be very expensive.

5.) Again, Performance -> Advanced themes (for example: http://www.sqville.com/aie/demos/aiedemobrowser/index.html#Office_03~TabView_1.html) are probably going to have a good deal of theme-specific code anyway.  Loading theme-specific code for multiple themes is costly in terms of up-front load time.

6.) People like Chris Eskew are doing amazing things with qooxdoo's theming capabilities.  Anything that can be done to make it easier to theme qooxdoo is going to benefit the framework and all of those who use it.

[Erich Konicek-2]

Fabian Jakobs schrieb:
> Hi,
>
> for 0.8 we are considering to remove two feature currently available in
> 0.7. We are very interested how you feel about this.
>
> 1. No longer support switching locales/languages of the application at
> runtime.
>  
I use switching language at loign (in a login screen as part of my
qooxdoo-app).

Will qooxdoo 0.8 bring an easy methode to load only parts of an
application at startup (e.g. login screen)?
And after it the possibility to reload the application with a new locale
within the app?
Then I can live well with it.
> 2. No longer support changing the theme at runtime
>  
Never used in an application.

Regards,
 Erich



-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Guilherme Aiolfi]

I'd choose performance, maintainability, simplicity rather than these features.

2008/6/13 Mike Rea <rea.michael@...>:

I know both features are cool but do we really NEED it. Does anyone
depend on one of the mentioned features or plans to use them? We really
like to know how you feel about this.

/quote>

So many great points on both sides of this argument.  I, like many others,
was initially won over by qooxdoo due to the impressiveness of the demos,
including the run-time theme-switching and localization.

However, as qooxdoo matures, I believe the keys to greater adoption &
long-term success will be simplicity and performance.  Many great demos will
woo developers to try qooxdoo, even without run-time theme switching and
localization.  The improved performance and simplicity may be reasons for
developers to stick with qooxdoo.

Here's a few reasons why I think it's OK to remove run-time theme-switching:

1.) Performance:  Very few users will really need run-time theme and
localization switching.  Every user of every application is subjected to
that application's performance.  If qooxdoo is 10% slower than Ext JS due to
rarely used features, is it worth it?  To me, no.  I'd rather go with
performance.

2.) Competitive landscape:  Sacrificing run-time switching doesn't place
qooxdoo at any competitive disadvantage relative to the other frameworks.
However, if performance is not on par with other frameworks, it would be a
disadavantage

3.) Wow-factors: Qooxdoo has a lot of other wow-factors, and it's soon going
to have many more.  These will enthuse potential adopters in lieu of the
current theme-switching.

4.) Simplicity -> translation: Development velocity.  If keeping run-time
switching slows development efforts that are going to bring additional
widgets to the toolkit, then the opportunity cost could be very expensive.

5.) Again, Performance -> Advanced themes (for example:
http://www.sqville.com/aie/demos/aiedemobrowser/index.html#Office_03~TabView_1.html)
are probably going to have a good deal of theme-specific code anyway.
Loading theme-specific code for multiple themes is costly in terms of
up-front load time.

6.) People like Chris Eskew are doing amazing things with qooxdoo's theming
capabilities.  Anything that can be done to make it easier to theme qooxdoo
is going to benefit the framework and all of those who use it.

--
View this message in context: http://www.nabble.com/Anyone-needs-switching-locales-and-themes-at-runtime--tp17820406p17823744.html

Sent from the qooxdoo-devel mailing list archive at Nabble.com.


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

Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Jim Hunter-2]

I am all for making things faster, but what would the method be to change themes on a reload? To me, if I reload the page it starts over and whatever the default theme is would get loaded. What would the code look like to change themes? If I could change themes on a fast reload that would be fine with me. I am all for making .8 as fast as possible!

Jim

On Fri, Jun 13, 2008 at 3:17 AM, Fabian Jakobs <fabian.jakobs@...> wrote:

Hi,

for 0.8 we are considering to remove two feature currently available in
0.7. We are very interested how you feel about this.

1. No longer support switching locales/languages of the application at
runtime.

While it looks like a nice feature the actual usefulness seems pretty
low. Most applications (e.g. gmx.com) change the locale only after a
restart. Changing the locale is not a common action and it may be OK to
require a reload to apply the change.  None of the other toolkits
support the dynamic change. dojo and GWT determine the locale at
application startup either through URL parameters or other static resources.

The cost of having the dynamic approach is:

 - for each translatable string (this.tr("...")) in the application we
have to keep an instance of qx.locale.LocalizedString
 - in each widget (mostly labels) we need to keep a connection to the
localized string and listen for locale changes
 - each widget has to be prepared to handle localized strings in each
place where a normal string, which is shown at the screen, is expected.
If it gets a localized string it must establish a connection to the
locale manager to listen for locale changes and update the displayed string.
 - At startup, all translated strings for all possible locales must be
transferred together with the application
 - some widgets need special and sometimes complex code  to handle
locale changes at runtime:
  - DateChooser
  - DateChooserButton
  - ComboBox
  - Button
  - Table

Being able to change the locale at runtime comes with a cost and we
think the cost is too high to justify this feature.
<http://bugzilla.qooxdoo.org/show_bug.cgi?id=871>


2. No longer support changing the theme at runtime

Basically the same arguments apply to theming. Changing the theme at
runtime requires us to always keep a connection between the widgets and
the associated theme entries. This costs runtime performance, memory and
increases the complexity of the widgets.
<http://bugzilla.qooxdoo.org/show_bug.cgi?id=861>


I know both features are cool but do we really NEED it. Does anyone
depend on one of the mentioned features or plans to use them? We really
like to know how you feel about this.


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


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

--
Jim Hunter

DAILY THOUGHT: SOME PEOPLE ARE LIKE SLINKIES - NOT REALLY GOOD
FOR ANYTHING BUT THEY BRING A SMILE TO YOUR FACE WHEN PUSHED DOWN THE STAIRS
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[Fabian Jakobs-2]

Hi Jim,
> I am all for making things faster, but what would the method be to
> change themes on a reload? To me, if I reload the page it starts over
> and whatever the default theme is would get loaded. What would the
> code look like to change themes? If I could change themes on a fast
> reload that would be fine with me. I am all for making .8 as fast as
> possible!
I could think of several ways to set the theme. Right now we have some
bootstrap code which loads the main qooxdoo application. This code could
read a cookie or an URL parameter to determine the theme and locale and
initialize the qooxdoo application accordingly.

Another option could be a static login before the main qooxdoo
application. With the knowledge of the user you could read his
preferences e.g. from a database. We use this approach e.g. at
<http://gmx.com>.

If think if we actually remove the dynamic switching we have to come up
with a good solution to perform static switching.

Best Fabian

> Jim
>
>
> On Fri, Jun 13, 2008 at 3:17 AM, Fabian Jakobs <fabian.jakobs@...
> <mailto:fabian.jakobs@...>> wrote:
>
>     Hi,
>
>     for 0.8 we are considering to remove two feature currently
>     available in
>