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 [EMAIL PROTECTED] ++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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
