Community
Participate
Working Groups
I have the console tab selected, because the last thing I did was run my tests. I make some code changes. Save my file. There are errors, but I don't see them because the Tasks tab is not the selected one. They system should automatically select it.
Moving to Platform UI for consideration.
Automatically switching the tab and selection may work in your scenario but would annoy other users. Automatic selection would be awkward in the case where there are multiple changes and/or the items are sorted. Instead, how about implementing a feature where a view that had "interesting" new information could indicate this by changing tab in some way. The second problem could be addressed by marking the existing problems as being "uninteresting" and showing only the changes.
Your alternative would be a major improvement. But I don't understand the problem with one of your scenarios (multiple changes) or how the other one (sorting) would make any difference. All I'm advocating is one somepiece of code Adds an "Error" to the task list, they "select" the task view tab. To me it's not different than when I run an application, the Console window comes to the front.
Imagine the scenario where you make a change and this results in creating 100's of errors. Selecting them would not be that helpful. If the erors in the task list were not contigious it would be even worse. As soon as you select one of the errors, say to double click on it to open the file, you would have lost all connection between the other 99.
If I make build (or save one or more files causing a build), and I get errors. I need to know what the first one is. I didn't say I was going to click on it. Furthermore, it is possible to have the situation where the build fails, and the *only* visible indicator is a gray circle-white x on a tab window. Or sometimes, not even that. I completely fail to understand the "lost all connection between the other 99" you mention. The errors (as tasks) maintain all the connection I need. Perhaps this is about another feature I'm unaware of.
Knowing which file is "first" isn't always clear as errors may get associated to arbitrary files, even ones you are not editing. I think in your case what would help would be an indication of the changes were as a result of the build. This isn't necessarily the first marker is the file the user is editing. Without the ability to ignore markers that didn't change you would need to select them to draw attention to the user? What is your suggestion for drawing the user's attention to the newly added errors? I think that you and I are in "heated agreement" about this scenario. We also need to be careful when we change the active part programatically. (ie. make the tasks view selected to show the errors). The guideline that we have been following on the UI team is that if the user did some explicit action it is OK to change the active part. In the case of builds this is not necessarily true. (eg. autobuild). If the user is making sweeping changes having the active part change may end up being very frustrating. Can I convince you to try implementing this yourself and let us know how it turns out.
I can understand that automatic activation changes can be dangerous. To me, the user has taken an explicit action. There is not "automatic build". I saved the file, or I clicked on a "build command". I think one thing, to me, is that I don't use Tasks for anything. To me it's just an error tab, so normally it's empty. What I'm trying to solve is the problem where I save a file, and don't realize that there are problems with the build. I find myself saving a file, and then trying to run the program. There is no point. If you'll point me to the general area where the Tasks view is (source wise), I'll give it a try shortly.
David, have you made any progress with this feature?
No, I haven't had any time to do any work on any eclipse-related stuff.
We are starting to wrap up the 2.0 work. I don't expect that we will be able to implement this request in time either. If it's OK with you I am going to mark this defect as "resolve-later" with an increased priority.
OK.
Consider as a post 2.0 enhancement.
Reopen to investigate
Note that in Eclipse 3.0, the Problems view tab turns to a bold font when new problems appear and it is hidden behind other views. Please close if this satisfies your requirements.
It is vastly better in 3.0. I still think it could be better, by optionally (preference) raising the tab. Still I'll close it out. There are more important things to do....
