| Re: [e4-dev] Difficulties determining the part providing selection |
On Tue, Jan 5, 2010 at 10:10 AM, Brian de Alwis <briandealwis@xxxxxxxxx> wrote:
> Hello everybody. I've had some difficulty creating a view that reacts to selection changes in other parts except from selections within its own part. Unfortunately this wasn't as straight-forward as I had hoped.
At the moment, selection is done in the demos using IEclipseContext's modify(String, Object) method. Did you try going down that path instead?
http://wiki.eclipse.org/E4/EAS/Selection
> I added a setInput() that requests the selection and active part:
>
> @Inject
> public void setInput(
> @Optional @Named(IServiceConstants.SELECTION)
> Object input,
> @Optional @Named(IServiceConstants.ACTIVE_PART)
> MPart activePart,
If you are interested in the selection, why are you concerned with the source part anyway? Consider the 'Properties' view. If you select a file in the 'Package Explorer', the file's contents shows up. The same contents shows up if you select the same file in the 'Navigator'. A part that purely consumes selection should not be concerned with which part is producing the selection. This effectively ties the two parts together and prevents reuse in other applications.
> However the provided activePart provided is always *this* part, rather than the selection part. This doesn't seem right to me — I expected that the other part should be considered as the active part since *this* part is only reacting to a selection in the other part.
Boris and I noticed this problem while we were trying to introduce an MSelectionProvider object into the model to replace the usage of modify(String, Object) to ultimately remove any direct references to IEclipseContext from the client code.
> [If the active part doesn't seem wrong
I think that if you ask the local context for the active part it will always return itself.
> could I then request additional constants such as IServiceConstants.SELECTION_PART and IServiceConstants.SELECTION_PART_ID?]
We added code to do something of that nature into the window renderer while trying to add MSelectionProvider though these constants were hidden from the user. The pseudocode was something like so...
public void selectionChanged(Object selection) {
mselectionProvider.setSelection(selection);
}
@Inject
public void setInput(@Optional @Named(IServiceConstants.INPUT) Object input) {
// do stuff
}
> And as an aside, these casts makes code much less clear than in E3.x, IMHO. I wonder if we mightn't be better for the IEclipseContext to provide for the use of adapters to provide typesafe interfaces. For example:
>
> IEclipseSelectionContext sc =
> context.getAdapter(IEclipseSelectionContext.class);
> if(sc.getSelectionPart() == this) { return; }
It's not totally clear to me what this code is trying to do. You want to ask the adapter for the selection instead of asking the context directly for the selection?
Brian, thank you very much for testing the codebase. Please follow-up with your comments, suggestions and concerns on bug 295007.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=295007
Regards,
Remy
----------
Remy Suen
Eclipse Platform/UI Committer
IBM Ottawa
613-356-5162