Re: [e4-dev] [Proposal] Locale switching

[Dirk Fauth <dirk.fauth@xxxxxxxxx>]

For the context stuff:

In E4Application.createDefaultHeadlessContext() the Locale value is set to the service context.

IEclipseContext serviceContext = E4Workbench.getServiceContext();
...
String locale = Locale.getDefault().toString();
serviceContext.set(TranslationService.LOCALE, locale);
TranslationService bundleTranslationProvider = TranslationProviderFactory.bundleTranslationService(serviceContext);
serviceContext.set(TranslationService.class, bundleTranslationProvider);

If I set the value for TranslationService.LOCALE to the application context, the application model is not changing the localized values. If I set it to the service context, it works.

If I understand it correctly, than the TranslationService is lying in the service context. Therefore it does not know about the application context. And therefore the model only knows about the Locale in the service context. Does that make sense?

On Mon, Dec 2, 2013 at 6:14 PM, Dirk Fauth <dirk.fauth@xxxxxxxxx> wrote:

My understanding of the model is yet not deep enough. I guess I need some more detailed information on how to do this. :-(

Am 02.12.2013 16:58 schrieb "Tom Schindl" <tom.schindl@xxxxxxxxxxxxxxx>:

On 02.12.13 16:49, Dirk Fauth wrote:
> Hi,
>
> I worked on the LocaleChangeService with feedback from Tom. Several facts:
>
> 1. The LocaleChangeService is not a OSGi service, but will be created
> via context function.
> 2. It has additional methods for setting the Locale via String, which is
> in respect to the TranslationService.LOCALE that is represented as
> String also.
> 3. There is an event fired on Locale change.
> 4. The model update is triggered directly (so the event might not be
> necessary, but who knows all use cases a user might have).
> 5. The Locale needs to be set to the OSGi context and not the
> application context, as the model seems to only checking the OSGi context.
>
> I've implemented some functionality that iterates over the model below
> the MApplication and filters out all MUILabel elements. It then exectues
> EMF notifications to update the UI. So the update can be triggered via
> model and it is not necessary to listen for events in the renderers,
> which should simplify things a lot.
>
> This works fine so far, but at this point the implementation gets ...
> well ... kind of ugly. I need to determine the concrete model
> implementation as I need to specify the EMF notification feature ID
> which is tight connected to the model. For example, to execute the EMF
> notification for the label of a MPart you need to execute eNotify() on
> PartImpl like this
>
> PartImpl impl = (PartImpl) element;
> impl.eNotify(new ENotificationImpl(impl, Notification.SET,
> BasicPackageImpl.PART__LABEL, oldLabel, label));
>
> I wouldn't need to cast directly to PartImpl. Usually UIElementImpl
> should be good enough to call eNotify(), but I need to know about the
> BasicPackageImpl.PART__LABEL feature id.
>
> This would leave me to implement a set of instanceof checks for every
> model element, so I know what feature needs to be updated in detail.
> Isn't there a more generic way to execute a notification that the label
> needs to be updated?
>
> Another idea would be to extend the MUILabel to contain a
> updateLocalization() method or something like that, that hides the
> implementation about what needs to be done for updateing such
> information. This would also allow the implementations to override, as
> for example parts also come with descriptions that are able to be
> localized and that are not specified in MUILabel. Would that make sense?
>
> What do you think? Any help or idea is appreciated. I implemented the
> locale change already for MWindow and MPart (which is easy when you only
> need to implement at one place), and it works very nice. Would love to
> finish this in the right way to get the locale change feature completely
> done for Luna.
>

We can solve all of this with:
a) make the localize* attributes volatile, transient, derived features
b) introduce a mixin interface with your proposed method
c) make MUILabel implement the mixin
   => send out events derived features
d) make the renderers listen to new volatile features

The advantage is that people deriving from our model can implement our
mixin and do the appropriate thing.

Tom
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev