Community
Participate
Working Groups
Build 20020323 - contribute an action via an action set to the global menu bar. - start eclipse and give focus to task list - set a breakpoint in IWorkbenchActionDelegate.selectionChanged(...) - give focus to Console viewer Trace: - first call with an empty StructuredSelection. In fact a null selection was sent out but PluginAction.selectionChanged magically converted the selection into an empty selection. SelectionService.getSelection returns null - second call with a text selection from the console viewer SelectionService.getSelection returns the text selection - now give focus back to the task list. The trace is: - first call with an empty structured selection. Is also a converted null selection. SelectionService.getSelection returns the TextSelection from console viewer - NO second call If we start to implement a lot of global actions via action delegates the two selection change events will cost use some performance.
Did you have a task selected, or was the selection in the task list empty?
Task list didn't contain any entries therefore no element was selected.
Not for M4
There is danger of introducing a breaking change here. Suggest deferring.
Defer
Too bad a fix for this didn't make it into 2.1 or the 2.1.1 maintenance release. My company is shipping a plugin, which includes a perspective, an editor, outline view, wizards, toolbar, etc., and we're running into this problem a lot. For example, some of our wizards use the selection to set default values, but the delegates which launch the wizards aren't consistently getting a valid structured selection to pass to them. It ends up being an annoyance to the end user, when the selections in the wizards are not set consistently.
Adding my name as this is listed as a performance issue. Please remove the keyword (and my cc) if this is not a performance bug.
Adding my name to the cc list as we are now tracking performance issues more closely. Please remove the performance keyword if this is not a performance bug.
Investigate for 3.1 M7.
In thinking about this some more, I feel that this is a general class of performance problem common to all of our event-based mechanisms in the workbench. Similarly, I recently saw small performance penalties in the handlers/contexts code. Handlers and contexts listen to part activation and deactivation. However, the majority of the time, these are paired events: a "part switch". In this case, the processing of the part deactivation becomes unnecessary. Part deactivation is only interesting if there is no corresponding activation. This is possible, but not common. In talking with Billy Biggs, he recommended adding a new event. A "switch" event, which is notification that a deactivation/activation pair are about to be sent. In this case, the developer can safely ignore the next deactivation event that arrives. This pattern would be accomplished with something like the following: handleDeactivate(...) { if (switching) { switching = false; return; } ... } handleSwitch(...) { switching = true; } In the case of selection events, there is no explicit "deactivate" event. This simply maps to a selection event with a null or empty selection. However, the pattern would still work. Unfortunately, this is an API change and so would have to wait until after 3.1. I don't see any way to address this problem until after 3.1.
Doug: We've obviously been thinking along the same lines. This type of optimization has recently become possible. Previously, workbench window and workbench page temporarily activate the null part between each activation change so there was no way to tell if a subsequent activate was coming (it also meant that the two events weren't really a pair since state changed between each event). I've recently refactored workbench page to make this type of optimization possible. The page now selects the new part before firing the deactivate/activate pair. This means that you can accomplish the effects of a "switch" event by remembering the last active part like this: IWorkbenchPart lastPart; handleDeactivate() { checkForSwitch(); } handleActivate() { checkForSwitch(); } checkForSwitch() { IWorkbenchPart newPart = page.getActivePart(); if (newPart != lastPart) { // The active part has changed. Handle a "switch" now. // .... lastPart = newPart; } } getActivePart() now points to the part about to be activated during the dactivate event, so the only case where you'll get a null active part is the situation where a deactivate won't be followed by an activate.
This PR seems to be reporting several things: 1. Null selections get converted into empty StructuredSelections 2. A redundant empty selection is fired between each activation change. 3. When certain parts are activated, a null selection is fired to the action delegates and the selection service reports a stale selection from the previous part. I'd argue that isssue 1 is a bug -- an empty structured selection also represents "no selection", but it's a lot safer than passing null (passing null is just asking for NPEs from client code). Issue 2 was fixed by the partial patch to bug 53333. That leaves issue 3. I suspect this was caused by one of the following fringe cases: a) a view with a null selection provider b) a view with a null selection c) a view that changed its selection provider after being activated We should ensure that we have test coverage for all three. I suspect that case c is still broken.
Re passing empty selection vs. null, this was originally done for safety, but if this is done there is no way of distinguishing between an empty selection and "no selection". We came up for a solution for this a while back whereby listeners that implement INullSelectionListener will get null instead of an empty selection in the "no selection" case.
From what I understand, these are the current semantics: From a selection provider's point of view, there is an important distinction between a null selection and an empty selection: a null selection means "get your selection from somewhere else" and an empty selection means "clear the selection". From a selection listener's point of view, there is always a selection -- a null selection just would have become a selection from a different source. If this is correct, then what would be purpose of the new interface?
Moving Dougs bugs
Assigning to component owner PW
Actions have been deprecated in favor of org.eclipse.ui.commands/org.eclipse.ui.menus . No more work will be planned for actions.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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.
