| Re: [e4-dev] Difficulties determining the part providing selection |
Hi Remy. On 5-Jan-2010, at 12:10 PM, Remy Suen wrote: > 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? Yes, I'm following how the demos use modify() for setting the selection in the context. > http://wiki.eclipse.org/E4/EAS/Selection Ah, thanks for pointing that out — my problem is on the consuming side where I do want to know the selection provider. I have a part that both listens to the global selection as well as providing its current selection. It must not react to selections originating from itself (hence the short-circuiting code 'if(selectionPart == this) { return; }' in what I posted previously). > 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. In my app, I currently have 3 parts. The first part is a selection provider. The second part is both a selection consumer and selection provider, reacting to selections from the first part, but also acting as a selection provider. The third part is a selection consumer, and is like the Properties view in that it reacts to the latest selection in either the first or second parts. The second part needs to know the source of the selection to avoid reacting to its own selections. So in this particular case, simply knowing that the selection is not its own would be enough. But there are other situations where a consumer needs to know details about the selection provider. For example, several of the JDT views have an interesting behaviour where they clear themselves if a selection is made from another view that is not a JDT part and that does *not* implement org.eclipse.search.ui.ISearchResultViewPart. I'm currently contemplating a selection consuming view that will only act depending on certain states of the selection provider. [I won't claim that my current design iteration is ideal, but it's getting something working.] > I think that if you ask the local context for the active part it will always return itself. Ah, so that is "active" as meaning "the part that is currently reacting to some change in the workbench". I was expecting "active" to mean "the part containing the widget with focus", which is by extension the part that is providing the selection. >> 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? Sorry for not being clearer, and it's possibly moot given that you're planning to > ultimately remove any direct references to IEclipseContext from the client code. I only meant to suggest the use of adapters to (1) minimize the need for casting by providing type-safe access to various items / services that are being currently being accessed through the context, and (2) shield the developers from knowing the organization of the context (e.g., my fetching the active part from the parent context). Although my example was about selection, I meant it to be a representative situation for any fetches through the context. I meant to suggest that IEclipseSelectionContext should have a Java5'd getAdapter() method like: public <T> T getAdapter(Class<T> clazz) { ... } and IEclipseSelectionContext would provide something like: public interface IEclipseSelectionContext { String getSelectionPartId(); MPart getSelectionPart(); ISelection getSelection(); } The client code could then be free of casts. I guess that's closer to the E3.x services model. > 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 Ok. I'll repost some of the above. Brian. -- On bike helmets: "If you think your hair is more important than your brain, you're probably right." (B. J. Wawrykow)
Attachment:
smime.p7s
Description: S/MIME cryptographic signature