Community
Participate
Working Groups
EG (5/19/2001 12:58:03 PM) Consider the following scenario: I'm working in the Java Perspective. My configuration of the Java Perspective has a stack of "views" at the bottom: Console (visible at the top) Search Result Task List When I do a build and have new errors. I don't see the result of the build operation and this can be confusing. I have to manually bring the Tasks view to the front. The build operation should bring the task view to the front automatically. Notice, that the console view and the search result view already support this auto raise option, but not in a consistent way. The console view does it conditional based on a user preference, the search result view does it unconditionally. NOTES:
Programatic changing the layout can lead to loss of context. How about adding support for indicating that there is "something interesting" happening in the view. (eg. In the TaskBar windows will "flash")
Consider as a post 2.0 enhancement
*** Bug 14779 has been marked as a duplicate of this bug. ***
*** Bug 21468 has been marked as a duplicate of this bug. ***
Reopening for 2.1.
Should add a preference for this. Can defer the more general support for notifying that there is a change in a part.
When showing the Tasks view, should also select and reveal the first new problem (i.e. the marker in the delta that has kind ADDED, is a subtype of PROBLEM, and has the earliest creation timestamp). It's better to select the earliest problem rather than the latest, since earlier problems can generate further secondary problems. Need to be careful to properly handle edits in the Tasks view itself. This will work if we only check for PROBLEMs, which can't be manually added, removed or changed. The view should not activate for CHANGED problems. I know of no actual cases where problem markers get modified after the fact, but this can occur if, during creation, a marker is created then modified in separate workspace operations (an easy mistake to make). That is, the plug-in calls createMarker, then setAttribute[s], not wrapped in an IWorkspace.run.
fix released to HEAD stream (IPreferenceConstants, messages.properties, WorkbenchPlugin, WorkbenchPreferencePage)
Reopening to address the selection question, and to refactor for proper split between org.eclipse.ui.workbench and org.eclipse.ui.views.
Q: should it show on any kind of problem (errors, warnings and infos) or just errors - currently activates only for errors (I felt activating it for warnings was too disruptive) - another possibility is to add a pref Q: should it select the (earliest) new problem? - pro: if there are many entries in the Tasks view, simply bringing it to front is not too helpful, since you don't necessarily see what the new problems are - con: will lose user's selection, so may lead to loss of context - I feel the pro outweighs the con
Erich, can we get your thoughts on the above?
>Q: should it show on any kind of problem I'd prefer to show the task view on any kind of problem. Otherwise the user might miss a warning. The model would be that whenever there is "builder" output in the form of a marker the task list is shown. I'd expect that builders will give the user control over the warnings that should be generated (see JDT for an example). >Q: should it select the (earliest) new problem? I'd opt for revealing the first new problem only. When considering the task list like an output log I wouldn't expect that new output is selected. Additional question: Q: What is done if there is a filter that hides the problem? Will the task list still be brought to front? Could the icon of the task view indicate that there is new content. Once the task view receives focus the icon would switch back to the standard one.
Another question: should the Tasks view activate, or leave the current part activated (e.g. the editor). It currently activates, but it's probably less disruptive to only bring it to front. The console seems to only bring itself to front, except when it's a fast view.
No strong opinion... one benefit of activating the task view (and selecting the task <notice that I'm contradictig myself to my previous comment>) is that I can quickly navigate to the task with the keyboard.
After having used eclipse with the the bring to front plus activate the task list behaviour I agree with Nick that this is much to disruptive. In particular when you work with auto build. Therefore the task list should only be brought to front and not be activated.
Karen, can you make this change (look for the console's use of showView to see how it's done), and have Eduardo release it for M4?
This is the behaviour I have observed from the console view (and from the code I have found in ConsoleDocumentManager that seems to control it): - When the view is stacked behind other views, it is brought to the front with no focus - When it is a fast view, it is popped out *and* given focus - When is doesn't exist at all, it is created and not given focus Is this the desired behaviour for showing the task view?
Currently we avoid opening the Tasks view -- it only is brought to front if it is already open. My thinking here is that some perspectives are not for development but rather deployment or other activities, and having the Tasks view opened in these perspectives may not make sense. On the other hand, if you're doing these other activities, you're probably not doing builds. Erich or Darin, have you received any complaints to this effect with the Console? It would probably be better to make them consistent, then if there's an issue, we can address it for both.
Released changes to: - show when new error or warning, but not info - bring to front (opening if necessary), but do not activate (same as Console) Also moved code to Workbench from WorkbenchPlugin to address bug 28512 (still needs to be moved up to org.eclipse.ui.views).
>Erich or Darin, have you received any complaints to this effect with the >Console? there were indeed complaints, in particular when the console was brought to front for any output (a web server can provide lots of output). It was addressed by a preference "show on error/show on output". It looks like auto revealing is highly sensitive due to the loss of context and some users simply might not want it. The initial setting should be to reveal the task view since the motivation for this effort was that first time users find the task view.
Yes, there is a pref to turn it off, but it is on by default.
Personally, I find the new behavior annoying. I'm currently working on a new project, which has multiple errors (since I'm moving code around). Every time I do a save (to clear some fixed errors), my task list leaps up again, when I just closed it. This is compounded by the pref to turn this off being very hard to find. I understand wanting to expose new people to the task list, but it should be easier to stop.
Ok, so 5 seconds after I posted, I found the pref, right under workbench. Hopefully the help will be updated to mention this. I don't suppose it would be possible for Eclipse to implement some "kill Clippy" functionality, e.g. "you've closed the tasks list x times after builds. Do you want to stop having the list appear automatically after builds?"
Need to refactor for M5.
Can't move the listener to the views plugin, since it needs to be hooked before the views plugin is activated.
There is an issue with this feature and the filters of the Tasks view. I have the task filter set to not show certain types of problems. However whenever those types of markers get created, the tasks view grabs the focus away from other views, when in the end it shows nothing new in the tasks view (Because of the filter.)
Victor, could you please enter a new problem report with details about your particular case? I'd rather not reopen this problem report.
Victor, please see previous comment.
Nick, done. New PR #34960
