Anyone needs switching locales and themes at runtime?

[Fabian Jakobs]

Hi Ralf,

> 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'll give you a small example. Take the "backgroundColor" property. You
can define a symbolic color in a theme - lets call it "focus". If you
set the background color using:

this.setBackgroundColor("focus");

Three things happen:

1. check whether the passed value is defined in the current color theme
2. inform the theme manager that this widget is using the themed color
by registering a callback function, which is called on theme changes
3. Let the theme manager transform the symbolic color name into a CSS color
4. apply the transformed color

We could drop step three, which would reduce the memory usage but then
switching themes would really become expensive. We had to scan all
defined objects, find all properties, which accept themed colors, and
update the computed color value. Right now I am a bit skeptical about
this approach.

> 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?
>  
The theme would be selected at application startup time using the
bootstrap code we already have. I guess we would still need the (meta)
theme manager. The others could probably be dropped.


Best,
Fabian

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

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

[Fabian Jakobs]

Hugh Gibson schrieb:

>> 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?
>>    
>
> +1 for this.
>
> And I've been looking into the locale stuff and I'm not sure how you
> would manage locale loading at runtime without having to have at least
> some of the class structure that is present at the moment.
>
> You still need to indicate which strings can be translated, how plurals
> are translated, and how complex strings are formatted (using %1, %2 etc).
> The natural place for these is where the string is created. So you still
> have to have all the existing calls to tr, trn, and trc. However, these
> would just return a translated string rather than a localised string
> object.
>
> It seems to me that there are two issues here:
>
> 1. Writing code to correctly handle language changes.
> 2. The overhead of being able to dynamically change language.
>
> You are trying to remove the potential altogether by arguing that the
> runtime overhead of the dynamic changes is too big due to all the
> localised string objects.
>
> Why not compromise: have the potential for static translations where tr,
> trn, trc just look up the appropriate string in the translation file and
> give that back. That will reduce the number of objects and should make
> applications run faster. It will use the existing function calls and
> translation structure which you have to retain anyway.
>  

Right, we'd have to keep the "tr", "trn", .. calls and most of the
infrastructure anyway. I'll give your approach a try. Maybe we could
externalize locale switching support into a mixin and make optional this
way. I will do some prototyping with this approach.

I'll keep you updated.
> But don't remove the code that sets up localised strings. Yes, you still
> have to do the hard work and make sure that dynamic localisation works
> for some controls but there is less pressure for that and classes could
> be marked as supporting it or not. That gives more time for you (or the
> community) to modify the classes.
>  

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

[Fabian Jakobs]

thron7 schrieb:
>> The main reasons to cut this feature are performance and complexity.
>>  
>>    
>
> Complexity of the framework code or complexity of the final app, that
> is?! Must be framework complexity...
>  
The complexity of widgets sensitive to locale changes. e.g. any widget
working with dates or times. Either in framework or in application code.

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

[Dioc]

We use runtime locale/language and theme switching in our application. We do not seriously depend on this feature but I should note that removing support of runtime switching can be painful for us (and not only for us) if:
- there will not be an easy way to determine and set locale/theme at startup and change them by reloading application; by the way, reloading of a big application can be quite problematic (time cost);
- i18n in application code will not be such easy as this is done in 0.7; large changes of application code to support new implementation of i18n is not attractive.

Denis

[Ralf Sternberg-2]

Hi Fabian,

Fabian Jakobs wrote:

> I'll give you a small example. Take the "backgroundColor" property. You
> can define a symbolic color in a theme - lets call it "focus". If you
> set the background color using:
>
> this.setBackgroundColor("focus");
>
> Three things happen:
>
> 1. check whether the passed value is defined in the current color theme
> 2. inform the theme manager that this widget is using the themed color
> by registering a callback function, which is called on theme changes
> 3. Let the theme manager transform the symbolic color name into a CSS color
> 4. apply the transformed color
>
> We could drop step three, which would reduce the memory usage but then
> switching themes would really become expensive. We had to scan all
> defined objects, find all properties, which accept themed colors, and
> update the computed color value. Right now I am a bit skeptical about
> this approach.

It would be less expensive than the initial rendering of the ui,
wouldn't it? What about only a single callback "colors have changed" or
even "themes have changed" that widgets react on by applying steps 1, 3,
and 4 if needed? I guess it's not that easy, I'm just trying. ;-)

Best regards, Ralf


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

Fabian Jakobs schrieb:

> Hugh Gibson schrieb:
>  
>>> 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?
>>>    
>>>      
>> +1 for this.
>>
>> And I've been looking into the locale stuff and I'm not sure how you
>> would manage locale loading at runtime without having to have at least
>> some of the class structure that is present at the moment.
>>
>> You still need to indicate which strings can be translated, how plurals
>> are translated, and how complex strings are formatted (using %1, %2 etc).
>> The natural place for these is where the string is created. So you still
>> have to have all the existing calls to tr, trn, and trc. However, these
>> would just return a translated string rather than a localised string
>> object.
>>
>> It seems to me that there are two issues here:
>>
>> 1. Writing code to correctly handle language changes.
>> 2. The overhead of being able to dynamically change language.
>>
>> You are trying to remove the potential altogether by arguing that the
>> runtime overhead of the dynamic changes is too big due to all the
>> localised string objects.
>>
>> Why not compromise: have the potential for static translations where tr,
>> trn, trc just look up the appropriate string in the translation file and
>> give that back. That will reduce the number of objects and should make
>> applications run faster. It will use the existing function calls and
>> translation structure which you have to retain anyway.
>>  
>>    
> Right, we'd have to keep the "tr", "trn", .. calls and most of the
> infrastructure anyway. I'll give your approach a try. Maybe we could
> externalize locale switching support into a mixin and make optional this
> way. I will do some prototyping with this approach.
>  

On a second thought I found a serious problem this this approach.

Suppose we call a method like this:

this.setText(this.tr("Hello %1!", name));

if "tr" returns a static string, there is no way for the widget to
convert it back into something that can be translated into a different
locale.

> I'll keep you updated.
>  
>> But don't remove the code that sets up localised strings. Yes, you still
>> have to do the hard work and make sure that dynamic localisation works
>> for some controls but there is less pressure for that and classes could
>> be marked as supporting it or not. That gives more time for you (or the
>> community) to modify the classes.
>>  
>>    
>
> 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

[Hugh Gibson]

> > Right, we'd have to keep the "tr", "trn", .. calls and most of
> the infrastructure anyway. I'll give your approach a try. Maybe we
> > could externalize locale switching support into a mixin and make
> > optional this way. I will do some prototyping with this approach.
> >  
> On a second thought I found a serious problem this this approach.
>
> Suppose we call a method like this:
>
> this.setText(this.tr("Hello %1!", name));
>
> if "tr" returns a static string, there is no way for the widget to
> convert it back into something that can be translated into a
> different locale.

Why did you want a static string converted back to a value for
translation?

I envisaged two scenarios:

1. Static loading of strings.

In this case this.tr will use the current locale to look up the
translated string, do the substitution (as above) and return the string.
That should work fine. No additional object instances are created and the
translation works using the current locale.

2. Dynamic loading.

This works as now - i.e. an instance of qx.locale.LocalizedString is
created and evaluating the string value is carried out in "toString".
Instances have to listen for changes to the locale and reload their
values. All localised strings will re-evaluate their current values but
using the new locale.


I don't see any problems with this. It would be a compile-time option. If
you want dynamic translation you enable it and take the hit of extra
objects. If you want fast and lean, you disable dynamic loading and
predetermine the locale and runtime.

Hugh

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

[Sebastian Werner]

Am 16.06.2008 um 22:48 schrieb Hugh Gibson:

>>> Right, we'd have to keep the "tr", "trn", .. calls and most of
>> the infrastructure anyway. I'll give your approach a try. Maybe we
>>> could externalize locale switching support into a mixin and make
>>> optional this way. I will do some prototyping with this approach.
>>>
>> On a second thought I found a serious problem this this approach.
>>
>> Suppose we call a method like this:
>>
>> this.setText(this.tr("Hello %1!", name));
>>
>> if "tr" returns a static string, there is no way for the widget to
>> convert it back into something that can be translated into a
>> different locale.
>
> Why did you want a static string converted back to a value for
> translation?
>
> I envisaged two scenarios:
>
> 1. Static loading of strings.
>
> In this case this.tr will use the current locale to look up the
> translated string, do the substitution (as above) and return the  
> string.
> That should work fine. No additional object instances are created  
> and the
> translation works using the current locale.
>
> 2. Dynamic loading.
>
> This works as now - i.e. an instance of qx.locale.LocalizedString is
> created and evaluating the string value is carried out in "toString".
> Instances have to listen for changes to the locale and reload their
> values. All localised strings will re-evaluate their current values  
> but
> using the new locale.
>
>
> I don't see any problems with this. It would be a compile-time  
> option. If
> you want dynamic translation you enable it and take the hit of extra
> objects. If you want fast and lean, you disable dynamic loading and
> predetermine the locale and runtime.

The problem is that in the second case the type of object routed  
between classes is not a string, but a instance of a qooxdoo class.  
This is fundamentelly more complex and different. Every type check  
must handle this correctly etc.

Sebastian

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

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

[Hugh Gibson]

> > 2. Dynamic loading.
> >
> > This works as now - i.e. an instance of qx.locale.LocalizedString
> > is created and evaluating the string value is carried out in
> > "toString". Instances have to listen for changes to the locale and
> > reload their values. All localised strings will re-evaluate their
> > current values but using the new locale.
> >
> > I don't see any problems with this. It would be a compile-time  
> > option. If you want dynamic translation you enable it and take the
> > hit of extra objects. If you want fast and lean, you disable
> > dynamic loading and predetermine the locale and runtime.
>
> The problem is that in the second case the type of object routed  
> between classes is not a string, but a instance of a qooxdoo class.
> This is fundamentelly more complex and different. Every type check
> must handle this correctly etc.

I looked at the existing code (trunk and legacy_0_7_x) and there are no
type checks of qx.locale.LocalizedString outside of the class itself and
the translation management code. qx.Locale.LocalizedString handles
conversion to a string with toString so it can look like a string object
as needed. Where else is type checking needed on the object returned from
this.tr etc? If it's type checking in a property it's trivial for you to
make qx.locale.LocalizedString be a "String" (and to change the property
value when the locale changes).

I thought that the issue was that reload is needed on objects which have
strings when the locale changes, so they need listeners for that event
and so on. But it seems to me that you've done most of the work needed
here. Why throw it away when it can easily be made optional as I have
described?

Your justification for removing this facility, which has been shown to be
of real use in some cases, is that it adds overhead for everything. But a
simple optional change - just making the this.trn call effectively
transparent, fixes all that.

Hugh

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

Hugh Gibson schrieb:

>>> 2. Dynamic loading.
>>>
>>> This works as now - i.e. an instance of qx.locale.LocalizedString
>>> is created and evaluating the string value is carried out in
>>> "toString". Instances have to listen for changes to the locale and
>>> reload their values. All localised strings will re-evaluate their
>>> current values but using the new locale.
>>>
>>> I don't see any problems with this. It would be a compile-time  
>>> option. If you want dynamic translation you enable it and take the
>>> hit of extra objects. If you want fast and lean, you disable
>>> dynamic loading and predetermine the locale and runtime.
>>>      
>> The problem is that in the second case the type of object routed  
>> between classes is not a string, but a instance of a qooxdoo class.
>> This is fundamentelly more complex and different. Every type check
>> must handle this correctly etc.
>>    
>
> I looked at the existing code (trunk and legacy_0_7_x) and there are no
> type checks of qx.locale.LocalizedString outside of the class itself and
> the translation management code. qx.Locale.LocalizedString handles
> conversion to a string with toString so it can look like a string object
> as needed. Where else is type checking needed on the object returned from
> this.tr etc? If it's type checking in a property it's trivial for you to
> make qx.locale.LocalizedString be a "String" (and to change the property
> value when the locale changes).
>
> I thought that the issue was that reload is needed on objects which have
> strings when the locale changes, so they need listeners for that event
> and so on. But it seems to me that you've done most of the work needed
> here. Why throw it away when it can easily be made optional as I have
> described?
>
> Your justification for removing this facility, which has been shown to be
> of real use in some cases, is that it adds overhead for everything. But a
> simple optional change - just making the this.trn call effectively
> transparent, fixes all that.
>  

Performance and memory consumption is only one aspect. The other one,
which I regard equally important, is code complexity and
maintainability. When we initially implemented dynamic theme switching
it seemed like an easy thing to do. We thought we just had to make the
label widget aware of locale changes but things are never that easy.
Very soon other widgets popped up, which needed special handling. Each
widget, which displays text outside of label widgets, needed to be able
to handle locale switches as well. Further all widgets displaying any
time or date related data have to cope with it as well. This aspect is
spread all over the qooxdoo ui codebase. Its the sum of all of this,
which has become a real maintenance issue and which I don't want to port
to 0.8.

You are absolutely right that with your approach we could remove the
performance import for a static language version. My problem with your
suggestion however is that it will reduce none of the mentioned
complexity and will add just another layer on top of it.

I hope I could make my opinion clear :-)


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

[Hugh Gibson]

> You are absolutely right that with your approach we could remove
> the performance import for a static language version. My problem
> with your suggestion however is that it will reduce none of the
> mentioned complexity and will add just another layer on top of it.
>
> I hope I could make my opinion clear :-)

<big grin>

Yes, absolutely. I can be pretty persistent ...

... which is why I would like to float this idea past you:

I see that at present you have put the main code for automatic connection
to the locale system in qx.ui.basic.Label, _applyText function:

    _applyText : function(value, old) {
qx.locale.Manager.getInstance().connect(this._syncText, this,
this.getText());
    },
   
which creates the nightmare as you say: potentially every place where
text is displayed has to have this sort of connection.    

Why don't you simplify this: have the property system automatically link
to the locale manager if a property value "string" is not a string but an
instance of qx.locale.LocalisedString? Then if the locale changes,
automatically call the apply function with the "toString" value of the
property. Similarly when calling getProperty convert to a string and
return that.

That could work for some of the special cases that you're hitting. It
would be turned off (i.e. compiled out) when using the non-dynamic
version of the language translation.

Hugh

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

[Ralf Nieuwenhuijsen]

2008/6/17 Fabian Jakobs <fabian.jakobs@...>:
> Very soon other widgets popped up, which needed special handling. Each
> widget, which displays text outside of label widgets

The label widget exists for a reason: to model labels. There should be
no exceptions where text is displayed outside of a label widget.

That's to me looks like a nightmare of complexity issues, weird bugs, etc.
All complex ui widgets should consist only of the core ui widgets.

Am i mistaken? Are the performance penalties too big? Has this been
measured? Does the label widget lack features?

Greetings,
Ralf N.

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

[Ralf Nieuwenhuijsen]

2008/6/17 Hugh Gibson <hgibson@...>:
> Why don't you simplify this: have the property system automatically link
> to the locale manager if a property value "string" is not a string but an
> instance of qx.locale.LocalisedString? Then if the locale changes,
> automatically call the apply function with the "toString" value of the
> property. Similarly when calling getProperty convert to a string and
> return that.

To me that solution sounds brilliant. The complexity is then still
contained at one place.
But please don't overload the behavior for 'string', rather use some
other name.
Like 'phrase' (to distingish it with the possible not human-readable
string datatype).

This would also remove all the need for this.tr calls. This special
property would just try to lookup a translation, or, if unavailable,
just the expression as is. So, if  myWidget has a property called name
of type 'phrase', i could just do:

 myWidget.setName("Trashcan");
 myWidget.getName();   // returns translated string

greetins,
Ralf.

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

[Hugh Gibson]

> > Why don't you simplify this: have the property system
> automatically link
> > to the locale manager if a property value "string" is not a
> > string but an
> > instance of qx.locale.LocalisedString? Then if the locale changes,
> > automatically call the apply function with the "toString" value
> > of the
> > property. Similarly when calling getProperty convert to a string
> > and
> > return that.
>
> To me that solution sounds brilliant. The complexity is then still
> contained at one place.
> But please don't overload the behavior for 'string', rather use some
> other name.
> Like 'phrase' (to distingish it with the possible not human-readable
> string datatype).
>
> This would also remove all the need for this.tr calls. This special
> property would just try to lookup a translation, or, if unavailable,
> just the expression as is. So, if  myWidget has a property called
> name of type 'phrase', i could just do:

The trouble with that is that the dynamic substitution of parameters into
the translated string would be lost. They are only available when the
translation object is created with the this.tr call. They are retained,
and are put into the translation string when the locale is changed.

Hugh

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

Ralf Nieuwenhuijsen schrieb:
> 2008/6/17 Fabian Jakobs <fabian.jakobs@...>:
>  
>> Very soon other widgets popped up, which needed special handling. Each
>> widget, which displays text outside of label widgets
>>    
>
> The label widget exists for a reason: to model labels. There should be
> no exceptions where text is displayed outside of a label widget.
>  
There are some places, where text can be displayed outside of labels.
Some of them are used in the framework others may be required in
application code:

 - HtmlEmbed: Any text displayed there is outside of the label. This
will effect e.g. a translated API viewer
 - TextField/TextArea
 - Text inside of a table. Changing the language of text inside of a
table is currently not supported and needs special handling in user code

The functionality of these widgets cannot be mapped to a label widget.
The other place where locale changes must be observed are all widgets
dealing with date, number, currency, ... formatting and parsing. The
date chooser is one example for this.
> That's to me looks like a nightmare of complexity issues, weird bugs, etc.
> All complex ui widgets should consist only of the core ui widgets.
>
> Am i mistaken? Are the performance penalties too big? Has this been
> measured? Does the label widget lack features?
>  
We have not measured it yet. I expect the runtime performance in non IE
browsers to be roughly the same but we safe a huge amount of objects.
This directly impacts the performance of IE6, which is very sensitive to
the number of allocated objects, and helps to reduce the overall memory
consumption of the application.


Best Fabian

> Greetings,
> Ralf N.
>
> -------------------------------------------------------------------------
> 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
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

[Hugh Gibson]

> Why don't you simplify this: have the property system automatically
> link to the locale manager if a property value "string" is not a
> string but an instance of qx.locale.LocalisedString? Then if the
> locale changes, automatically call the apply function with the
> "toString" value of the property. Similarly when calling getProperty
> convert to a string and return that.

Fabian, did you see this? What was your view on it?

Hugh

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

Hugh Gibson schrieb:

>> Why don't you simplify this: have the property system automatically
>> link to the locale manager if a property value "string" is not a
>> string but an instance of qx.locale.LocalisedString? Then if the
>> locale changes, automatically call the apply function with the
>> "toString" value of the property. Similarly when calling getProperty
>> convert to a string and return that.
>>    
>
> Fabian, did you see this? What was your view on it?
>  

I think it is a good solution. I actually have implemented a prototype
of this. However I think we have found a slightly better way to do it.
See my separate mail about this.

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