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