Re: Summary: Anyone needs switching locales and themes at runtime?

> Hi,
>
> thank you for all of your replies and constructive ideas on this topic.
> I guess without this feedback our solution would look completely
> different. Let me summarize some of the discussion and explain what we
> plan to do.
>
>
> Locale Switch:
>
> I was surprised that so many of you actually use it and really like to
> keep this feature. Especially the kiosk like application Maria Siebert
> described, would be hard to do without. Our concern was mainly
> performance and maintainability. I think we can improve both without
> cutting this feature. What we plan to do is:
>
> 1. Introduce a variant "qx.dynamicLocaleSwitch", which controls whether
> dynamic locale switching can be used. The variant defaults to "off". In
> this mode no additional performance/memory overhead is there. If it is
> turned on the memory consumption is about the same as it is now.
>
> 2. Get rid of the LocalizedString. Instead we use a trick to attach the
> information to retranslate a string to the translated string object.
> This is best explained with a snipplet of code:
>
>         txt = new String(txt);
>         txt.args = args;
>         txt.messageId = messageId;
>
>
> This way we can work with normal strings everywhere and don't have to
> differentiate between LocalizedString and normal strings. We can just
> listen for locale changes, then check, whether the string property has a
> "messageId" field and retranslate the property if needed. This is
> totally unobtrusive for the rest of the widget code.
>
>
> Theme switch:
>
> There were significantly less posts supporting the theme switch. Most of
> you said something like "It is a cool feature but in production it does
> not have much value". The memory impacts of supporting dynamic theme
> switching is much larger than for the locale switch so still advocate
> for removing this feature.
>
> Maybe we can later investigate Ralf's idea of iterating over all objects
> and look for dynamic properties on a theme switch. This could remove the
> memory overhead but would slow down the theme switch. Right now I have
> no idea how feasible this approach is.
>
>
>
> Best Fabian
>
>
>