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

[Jonas Helming <jonas.helming@xxxxxxxxxxxxxx>]

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