Re: Anyone needs switching locales and themes at runtime?

> Hi Fabian,
>
> RAP provides infrastructure that allows switching themes at runtime.
> It's not yet API though, as theme-switching caused problems with earlier
> qooxdoo versions. However some people asked for it on the RAP newsgroup
> and I think there are some people actually do switch themes at runtime.
> If qooxdoo drops this functionality, RAP will lose it too. Although we
> are always interested in performance improvements, we wouldn't like to
> sacrifice this feature.
>
> Just for curiosity, could you roughly explain what this connection
> between the widgets and associated theme entries is needed for? If the
> widgets use it to listen for theme changes, wouldn't it also be possible
> to re-layout everything in case of a theme change, thus making theme
> switching a more costly operation in favor of overall performance?
>  

> Switching locales is not an issue for us.
>
> Best regards, Ralf
>
> 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
>
>
>