Community
Participate
Working Groups
Just upgraded from R2.1 to R3.0M4. I don't mind the fast view Problems windows so much. Eventually, I'll figure out how to turn it off so it doesn't hide information I want to see. But it should never, I REPEAT *****NEVER****, steal my focus from when I'm typing in the editor. *****EVER*****. Extremely rude and irritating behavior. I am the human. *I* get to decide where I want to type. This behavior seems to occur (not sure) when I have changed some code which causes a problem to be removed from the problem list.
Happens on WinXP too (the Problem View must be a fast view)
This can be disabled in the Workbench pref page ("Show Problems view when build has errors or warnings"). But I agree it's a usability problem.
Thanks for tip on disabling it. I assumed there would be such. In the meantime, I had been telling people to *not* upgrade to 3.0, because of the usability pain.
I'm open to suggestions for a better way to give the user contextual awareness that they have new compilation errors or warnings, without disrupting their focus.
I'm not strongly objecting to bringing the pane forward. I *am* strongly objecting to typing in an editor, and then finding that the characters I type on the keyboard are not going into the editor. This is very different from giving the user contextual awareness. Law of least surprise says I should not have to guess why I can't type the next line of my program.
And I absolutely agree. The user owns the focus. The current behaviour is a usability bug. But there still might be better ways of giving contextual awareness without bringing a whole heavyweight view to front.
If the problem view is already open, could it use IWorkbenchpage.bringToTop to make it visible without stealing focus?
Bringing the view to top will still steal focus if another view in the same stack had it. We now have support for the part's progress service to indicate that the view has new information. Tod, I forget what the plan was here for the marker views. Can you clarify?
The plan is not to do this at all. We are going to indicate changes by bolding the tab but we do not intend to take focus. We currently have the "open on new problems" option and I think this will remain. It is off by default now however so this problem is resolved.
I think the option should be removed then, since the bold indication is adequate.
Renaming the PR to indicate the change.
I agree that the "show on new problems" option, as it is now, is not useful. However, the new bolding of the view tab is not a sufficient replacement. The only reason I ever enable "show on new problems" is when I want to be certain that I don't launch or check in any code that contains compile errors. I want to know this no matter what perspective I'm in. The bold tab only tells me that markers have changed, and only if the problems view is visible in my perspective. Since "show on new problems" isn't useful in its current state (it shouldn't grab focus and shouldn't open for marker removals), I will remove it... however, I feel that we should replace it with a new way to notify users that their workspace contains errors (possibly using an icon in the status line).
Fixed in head.
