I don't have strong feelings about that. Could you please comment in Gerrit so other reviewers see that too?
There is also a discussion about which methods should be included or not. https://git.eclipse.org/r/#/c/19743/ On Wed, Dec 18, 2013 at 11:36 AM, Jonas Helming < [email protected]> wrote: > I personally prefer either a prefix which expresses the context (e.g. > "M" for application model elements or "E" for workbench services) or no > prefix. I do not really like the "I" prefix, IMHO, it seems to be a left > over from times, when an IDE was not able to visualize the difference > between a class and an interface itself. Just my two cents... > > > > > Am 16.12.2013 14:33, schrieb Tom Schindl: > > 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 > >>>> [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 > >> > > _______________________________________________ > > 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
