Bugzilla – Full Text Bug Listing
| Summary: | Selection consumption for handlers using a single variable | ||
|---|---|---|---|
| Product: | [Eclipse Project] e4 | Reporter: | Remy Suen <remy.suen> |
| Component: | UI | Assignee: | Project Inbox <e4.ui-inbox> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | ob1.eclipse, pwebster |
| Version: | 1.0 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | stalebug | ||
Consider this:
at the MPart level, a set selection is literally:
partContext.set(IServiceConstants.SELECTION, <ISelection in the 3.x world>);
At the window level,
windowContext.set(IServiceConstants.SELECTION, new ContextFunction() {
public Object compute(IEclipseContext context) {
IEclipseContext active = windowContext.getActiveLeaf();
while (active != windowContext) {
Object obj = active.getLocal(IServiceConstants.SELECTION);
if (obj !=null) {
return obj;
}
active = active.getParent();
}
return null;
}
});
In theory, asking for the selection at the window level would get the currently active part selection. Option 2 over above would be to simply assume the the compute(*) context is the leaf context, although we'd have to confirm that.
PW
(In reply to comment #1) > Option 2 over above would be to simply assume the the > compute(*) context is the leaf context, although we'd have to confirm that. If you assume it's the leaf context then you'd get no selection when getLocal(IServiceConstants.SELECTION) is called for a part that doesn't post selection. In that case a part that tries to consume the window's selection would never get injected because it'll always just be null. (In reply to comment #2) > If you assume it's the leaf context then you'd get no selection when > getLocal(IServiceConstants.SELECTION) is called for a part that doesn't post > selection. In that case a part that tries to consume the window's selection > would never get injected because it'll always just be null. I knew there was a reason it was never that simple :-) PW (In reply to comment #2) > If you assume it's the leaf context then you'd get no selection when > getLocal(IServiceConstants.SELECTION) is called for a part that doesn't post > selection. In that case a part that tries to consume the window's selection > would never get injected because it'll always just be null. Wait, isn't that the case now. If a part doesn't post a selection, it will pick up the window context function, which will provide the selection of the window active child. If the part is not active, it'll see the active child selection, and if it is active it will get null in Eclipse 4 ... in eclipse 3.x, we would have to filter that through the INullSelectionListener. PW (In reply to comment #4) > Wait, isn't that the case now. If a part doesn't post a selection, it will > pick up the window context function, which will provide the selection of the > window active child. Well, the current system does work but uses two different variables at the moment. > If the part is not active, it'll see the active child selection, and if it is > active it will get null in Eclipse 4 ... in eclipse 3.x, we would have to > filter that through the INullSelectionListener. I'm not sure how often people actually care about 'nulls' though. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. This is a mass change to close all e4 bugs marked with "stalebug" whiteboard. If this bug is still valid, please reopen and remove the "stalebug" keyword. |
It appears that our desire to make the programming model for Eclipse 4 easier we also want to reduce the number of random constant/variable names. On that note, we want handlers to be able to consume selections based on the state of the running system easily. By easily I mean using only one variable name. @Execute void execute(IServiceConstants.SELECTION Object o) {} Consider a window with an active part, partA, that posts a selection and a partB that doesn't currently post a selection. If we execute the handler in partB's context, we would want the workbench window's current active selection (which would be partA's selection, as the active part). However, if later partB suddenly posts a selection, we would then want the handler to be injected with the selection from partB instead (even if partA is still the active part). This is not difficult to implement with two variable names (this is how it is right now) but I am having some difficulties implementing this with only one variable name.