Quantcast

Re: Anyone needs switching locales and themes at runtime?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Anyone needs switching locales and themes at runtime?

Fabian Jakobs
Administrator
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Anyone needs switching locales and themes at runtime?

Hugh Gibson-2
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Anyone needs switching locales and themes at runtime?

Ralf Nieuwenhuijsen
In reply to this post by Fabian Jakobs
2008/6/17 Fabian Jakobs <[hidden email]>:
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Anyone needs switching locales and themes at runtime?

Ralf Nieuwenhuijsen
In reply to this post by Hugh Gibson-2
2008/6/17 Hugh Gibson <[hidden email]>:
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Anyone needs switching locales and themes at runtime?

Hugh Gibson-2
> > 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Anyone needs switching locales and themes at runtime?

Fabian Jakobs
Administrator
In reply to this post by Ralf Nieuwenhuijsen
Ralf Nieuwenhuijsen schrieb:
> 2008/6/17 Fabian Jakobs <[hidden email]>:
>  
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Anyone needs switching locales and themes at runtime?

Hugh Gibson-2
In reply to this post by Hugh Gibson-2
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Anyone needs switching locales and themes at runtime?

Fabian Jakobs
Administrator
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Loading...