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?
I also wonder what the consequences of the theming restructuring would
be. How would the concept of themes change when there is always only one
theme? Would there be still a need for any theme managers?
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
