Community
Participate
Working Groups
Currently, we use the EObjectLabelProvider of the current (referencing) language for content proposals, even though the displayed elements are fetched from the index and could even be proxies. See AbstractJavaBasedContentProposalProvider.apply(IEObjectDescription candidate). We should rather use the DescriptionLabelProvider of the language the referenced element comes from.
Is the use of the DescriptionLabelProvider instead of the EObjectLabelProvider for content proposals an agreed design decision? or do you plan to come with something else?
It is agreed that it should be used by default (at least for non resource-local EObjectDescriptions). Though if it doesn't fit your use case, it should be easy to change it. Do you have any additional suggestions?
Not for the time being. I am just trying to clear things before committing to changes in the way we design our label providers now. I want to make sure we don't introduce things we'll need to rollback later. (The resource-local distinction is important, this is the point we are arguing about right now, because we have cases where proposals may include local and external references, and we need to guarantee consistency among proposal texts & images -- thus I was wondering if you had something in mind about that.)
(In reply to comment #2) > It is agreed that it should be used by default (at least for non resource-local > EObjectDescriptions). > Though if it doesn't fit your use case, it should be easy to change it. > > Do you have any additional suggestions? IIRC, we wanted to provide an ILabelProvider that dispatches to the EObjectLabelProvider or the EObjectDescriptionLabelProvider depending on the state of the description (proxy / real EObject). Did I miss something?
(In reply to comment #4) > IIRC, we wanted to provide an ILabelProvider that dispatches to the > EObjectLabelProvider or the EObjectDescriptionLabelProvider depending on the > state of the description (proxy / real EObject). Did I miss something? Yes, that's what I tried to say, expect that we will always have to use EObjectDescriptionLabelProvider for elements form other languages, no matter if the EObject is a proxy or not.
(In reply to comment #5) > Yes, that's what I tried to say, expect that we will always have to use > EObjectDescriptionLabelProvider for elements form other languages, no matter if > the EObject is a proxy or not. Why shouldn't we use the object label provider of other languages if the resolved instance if already available? I propose to encapsulate the logic (EObjectLabelProvider / DescriptionLabelProvider and selecting the label provider according to the resource / language) in a global ContentAssist(Styled)LabelProvider that can be used in any case.
(In reply to comment #6) > Why shouldn't we use the object label provider of other languages if the > resolved instance if already available? Why should we use different implementations depending on the internal state? the labels should really be the same in all cases. Would be confusing otherwise. So all needed information has to be available if we want to compute the label based on an EObjectDescription anyway. Exposing a second label provider for content assist (in IResourceUiServiceProvider) might make sense, but I think that one should also be based on IEObjectDescription. > I propose to encapsulate the logic (EObjectLabelProvider / > DescriptionLabelProvider and selecting the label provider according to the > resource / language) in a global ContentAssist(Styled)LabelProvider that can be > used in any case. As it is only logic but no state, the label provider doesn't need to be global. Only the registry (i.e. IResourceServiceProvider.Registry) needs to be.
(In reply to comment #7) > Why should we use different implementations depending on the internal state? > the labels should really be the same in all cases. Would be confusing > otherwise. > So all needed information has to be available if we want to compute the label > based on an > EObjectDescription anyway. > I'ld assume that people do not fill the user data in their local scope providers but only in the IResourceDescription.Manager. That's why the relevant data for the label provider may be missing - especially if the label provider was implemented in another language it may be quite a hassle to duplicate the user-data logic in the local scope provider. That's why I'ld dispatch to the object label provider if possible.
Removed target milestone M3.
has been solved in the meantime.
Requested via bug 522520. -M.
