Re: [e4-dev] Locale changes at runtime - update

[Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>]

We've used E only i the workbench. I have no strong feelings about E/I
(generally I have both of them!).

Tom

On 15.12.13 18:34, Jonas Helming wrote:
> Hi,
> 
> thank you Dirk for the great work and thank you Tom for warpping it up!
> Might ELocaleSwitchService be a better name for the interface to be
> consistent with the other e4 services?
> 
> Best Regards
> 
> Jonas
> 
> Am 13.12.2013 11:46, schrieb Tom Schindl:
>> Hi,
>>
>> First of all a big thank to Dirk for working through this rather complex
>> topic which has been a lot of work!
>>
>> What makes me a bit proud is that the archtitecture we have in e4 allows
>> to implement something like this with justifiable cost - imagine doing this
>>
>> Now let me elaborate bit what the changes are and how address them. I
>> guess this should make it easier to understand the patch.
>>
>> a) The model changes
>> --------------------
>> Until today the localization was done through EOperations (=Methods)
>> defined in our Ecore model. We have changed that so that those are
>> volatile, transient, derived, unchangeable EStructuralFeatures who from
>> an API point of view are identical to the EOperations previously defined
>> e.g. in MUILabel hence our API is not broken!
>>
>> The reason we change to EStructuralFeatures is that we can now send out
>> Notifications about the changes who are then going directly through our
>> Event-System.
>>
>> To mark EClasses who hold localizable informations and to inform them
>> externally about a changed locale we introduced a new Mixin named
>> Localizable who has a method named updateLocalization().
>>
>> This allows use the generically search the model for model elements
>> effected by a locale change and force them sending out updates. There's
>> a very small potential that this breaks backwards compat if people have
>> extended our Ecore in a way like this:
>>
>> MySpecialPart superTypes [*MySuperClass*, Part]
>>
>> so the generated java code will look like this:
>>
>> class MySpecialPartImpl extends MySuperClassImpl implements MPart {
>> }
>>
>> I don't really think that we should bother with those who have extended
>> our ecore because a similar source incompatible change was made with
>> TrimElement - let me restate the breakage is ONLY for people who
>> extended our Ecore (and even there those who did it in a sensible way
>> would not be affected)
>>
>> b) Local change propagation
>> ---------------------------
>> The central point to switch the locale is ILocaleChangeService which is
>> not implemented at the OSGi-Level but through a ContextFunction which is
>> implemented in ui.workbench.
>>
>> It allows to switch the locale at the application, as well as the
>> context level and the implemention does 2 things:
>> - it will inform *all* model elements of an application who implement
>>    MLocalization about the change
>> - posts an event on the event broker
>>
>> c) Local change consumption:
>> ----------------------------
>> There are 3 ways one can get informed about a local change:
>> - Through the event-broker by listening to the topic
>>   org/eclipse/e4/core/NLS/LOCALE_CHANGE
>>
>> - By using DI and make your bean get TranslationService.LOCALE injected
>>   => the new message system Dirk & me introduced does use this and
>>      you'll get an update Message-Instance injected!
>>
>> - Attaching to the model events listening to the LOCALIZED-Features we
>>   introduced instead of the EOperations from above
>>   => the renderers have to be modified to listen to the LOCALIZED-
>>      Features!
>>
>> I hope you followed along until this point but I felt you need to get
>> some background on what Dirk did and why he did it this way.
>>
>> My plan is to get this in very early in the M5 cycle immediately after
>> M4 has been declared unless someone speaks up. We have to file a CQ
>> because of the size of the contribution. I guess I should go ahead with
>> that once we managed to have consensus if this initial bits are ready to
>> go in
>>
>> Like the split editors in the IDE world this has been the most requested
>> feature in RCP applications I encountered in my past ~10 years of
>> Eclipse RCP consulting.
>>
>> Tom
>>
>> On 13.12.13 10:08, Dirk Fauth wrote:
>>> Hi everybody,
>>>
>>> with the help of Tom regarding the internals of the application model
>>> and more, I was finally able to add the support for Locale changes at
>>> runtime to the application model.
>>>
>>>
>>> This is the ticket for the enhancement:
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=423991
>>>
>>> These are the Gerrit changes containing my contribution:
>>> https://git.eclipse.org/r/#/c/19743/
>>> https://git.eclipse.org/r/#/c/19746/
>>>
>>> I added the ILocaleChangeService that can be injected and used to change
>>> the Locale.
>>> I removed all getLocalizedXxx() methods in the application model and
>>> replaced them with corresponding attributes.
>>> I modified the renderers to listen for the LOCALIZED events.
>>>
>>> I attached an example project to show the new message extension and the
>>> locale changes at runtime in the application model. I will push this
>>> example to GitHub if my contribution gets accepted.
>>>
>>> Hope you like it.
>>>
>>> Greez,
>>> Dirk
>>>
>>>
>>> _______________________________________________
>>> e4-dev mailing list
>>> e4-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>>
>> _______________________________________________
>> e4-dev mailing list
>> e4-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/e4-dev
> 
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>