Summary: Anyone needs switching locales and themes at runtime?

[Fabian Jakobs]

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


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

[thron7]

Sounds cool.

T.

> 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
>
>
>  

-------------------------------------------------------------------------
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

[Peter Schneider-2]

Hi Fabian,


> [...]
> This is best explained with a snipplet of code:
>
>         txt = new String(txt);
>         txt.args = args;
>         txt.messageId = messageId;
>
> [...]

Does this mean, a application programmer can not write this anymore? :

  var label = new qx.ui.basic.Label(this.tr("Settings"));

and has to do something like this? :

  var txt = new String("Settings");
  txt.messageId = "id_settings";
  var label = new qx.ui.basic.Label(txt);

or am I just to pessimistic and some kind of static class member like tr()
will still be available?

Maybe it's just me, but I don't like the 2nd example ...

this is just *my* 2 cents; So anybody, please feel free to see it this way ;)

Best Kuddel


-------------------------------------------------------------------------
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

[Fabian Jakobs]

Peter Schneider schrieb:

> Hi Fabian,
>
>
>  
>> [...]
>> This is best explained with a snipplet of code:
>>
>>         txt = new String(txt);
>>         txt.args = args;
>>         txt.messageId = messageId;
>>
>> [...]
>>    
>
> Does this mean, a application programmer can not write this anymore? :
>
>   var label = new qx.ui.basic.Label(this.tr("Settings"));
>  

No, the public API does not change. My code snipplet just shows an
internal implementation detail, which solves some of our problems with
the old implementation.

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