Congratulations. Sounds really good.
On Fri, Dec 13, 2013 at 11:46 AM, Tom Schindl <[email protected]>wrote: > 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 > > [email protected] > > https://dev.eclipse.org/mailman/listinfo/e4-dev > > > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev >
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
