Community
Participate
Working Groups
Some views (like the console view and formerly the problems view) like to open automatically in response to some background event. In order to disable this behavior, it is necessary to hunt down several preferences from different preference pages to disable the behavior for each view. There should be a global option that disables any attempt to open a view or editor from a background thread. For example, any API that brings a view or editor to the foreground can be disabled unless the SWT event loop is processing a keystroke or mouse event. These APIs could make the view or editor title flash or become bold instead of bringing it to the foreground.
Why bother making it a preference, why not just fix these views to not come to the front?
I think the best we could do here is to provide new API for requesting that a view be activated, without actually activating it. The workbench could flash its tab or whatever. We could then encourage plugins that want to show a view from the background to use this new API rather than showView. Should generalize to editors too. Darin, do you have any thoughts on how you'd like this to work for the debug case?
Your suggestion sounds good. An API to "bring attention" to a view without showing it would work. However, does this conflict with the current "bolding" view title support which is used to indicate that content in a view has changed? Currnetly, when the user turns off the preference to show the console when there is output, we bold the console title via IWorkbenchSiteProgressService.warnOfContentChange (). Would these features conflict? What would be the rules for choosing between the two behaviors?
I don't have a problem with adding new API that respects a no popups policy. Note that views can already do a showView(viewId, secondaryId, VIEW_CREATE) followed by bolding their title. We don't need a new UI affordance. The bold title is already used to draw the user's attention. Views that jump to the foreground always do so because their content has changed. I'd still prefer that the workbench enforce the no-popups policy directly... more like the FireFox popup-blocker or the windows XP option that prevents apps from stealing focus. This would guarantee that it is respected universally without requiring any changes to downstream plugins.
Re: comment 1 We can't always fix the views because not everyone agrees that this is a bug. See bug 85596.
Re comment #5: the user owns the focus, so stealing it is always bad. I suppose we could try the pop-up blocker approach, but I'm not sure that would be appropriate for all existing calls to showView. Re comment #3: I think we'd want the same affordance as warnOfContentChange. Darin, would you be willing to try using showView(viewId, secondaryId, VIEW_CREATE) and IWorkbenchSiteProgressService.warnOfContentChange() together as the default behaviour? If this works for you, we could then consider whether to make this the default behaviour for the regular showView if it wasn't triggered directly by the user.
Discussion with the JDT team indicates that we want to continue with the current form of operation. I.e. the console should open & display automatically when output is written. This is to support new users of Eclipse and the their initial development experience (i.e. write a program that produces output). The claim is that advanced users can turn the preference off.
I still think it would be worth prototyping the approach suggested in comment #3, to see if that gives a strong enough cue to new users without stealing focus.
The intent of this PR was to make it unnecessary to hunt through the preference pages to find all options of the form: "Allow this view to open automatically in situation XXXX" The addition of the new API does not solve this problem, especially if it is not universally adopted. Comment 17 indicates that it won't be. Restoring original summary text.
I've added a "Never steal focus" preference (really, it means "never let views jump to the front uninvited", but I thought the former label was easier to grok). Here's how it works: - If the preference is disabled, everything works as it did before. - As long as Eclipse is responding to a keystroke or a mouse click, everything works as it did before. - In any other situation, any attempt to activate a view or bring it to front will simply result in bolding the tab. The preference is off by default.
Reopening. We are going to have to roll this back for 3.1. M1 due to Bug 106388.
Do we really need this preference?
Unless we can get universal agreement from all plugin authors to never open a view or editor automatically (we can't), or to voluntarily respect a global preference (won't happen either: see comment 7), then we need the preference to forcibly disable the behavior. Those of us who find the behavior intolerable REALLY want it. Steve: The performance issue here looks like an SWT thing. It seems that having any event filter hooked up to certain events causes a performance regression, even if the code in the filter is a no-op. I suspect the filter is being called way too frequently for mousedown filters on tree widgets. If we're going to bring back the "don't jump to foreground" preference, the performance issue will need to be fixed.
Veronika and I looked into the performance thing and could not figure out what was going on. We put a print when the notification was sent while the directory dialog was up and it wasn't sent 1,000,000 times or anything strange like that. We were literally at a loss to understand what Windows was doing and why adding a filter should have anything to do with it ... but it does because we could comment out the lioe that installed this feature and the performance came back.
>I suspect the filter is being called way too frequently for mousedown >filters on tree widgets. The problem was in a directory dialog, not a Tree. Do you have any reason to suspect another (unrelated) problem?
Ok, I think we've fixed the SWT part of this now so you could try it again. The problem was we were chewing CPU when an asynchronous message was pending (see bug 88958).
Created attachment 28240 [details] workbench patch
Created attachment 28241 [details] ide patch These two patches bring back the feature.
Doug, since you rolled back the original patch, can you inspect this version?
I propose the following. We add a new mode to IWorkbenchPage, VIEW_ACTIVATE_IF_ALLOWED. We add a new workbench preference, "Prevent views from taking focus". if (preventViewsFromTakingFocus) if (inSameStackAsActivePart) VIEW_ACTIVATE_IF_ALLOWED == VIEW_CREATE else VIEW_ACTIVATE_IF_ALLOWED == VIEW_VISIBLE else VIEW_ACTIVATE_IF_ALLOWED == VIEW_ACTIVATE I feel this has some advantages over the proposed patch. It does not change the current meaning of any of the API calls, which I believe is better for compatibility reasons (i.e., lower risk). It provides a global switch for preventing focus stealing, which can -- by default -- be off (i.e., preventViewsFromStealingFocus=false). I think this addresses concerns from Debug and JDT. It also means the UI affordance is completely under the control of one thing (and, ideally, this is the presentation). The only problem is, as Stefan points out, this would be an "opt-in" approach. If plug-in developers didn't play nicely, then nothing happens. Within the Eclipse SDK this is probably not a problem; we're all friends here. But in the Eclipse world at large this could be problematic. I think this needs more thought before committing to any one approach.
*** Bug 113109 has been marked as a duplicate of this bug. ***
With the proposed solution, there will still be many situations where views will grab focus from a background thread. The intention of this PR is to arrange such that this should NEVER occur. Doug, I asked for a code inspection, not an opinion on whether you want the feature. If you don't want it, don't enable the preference. I was told that there is resistance to this patch because I am the only one pushing for it. If you are on this CC list because you are in favor of this feature (or if you have filed a duplicate), please: 1. Comment here saying so. 2. Vote on this PR. 3. Tell your friends to do the same.
Reassigning back to myself. I will ask someone else for the code inspection. BTW, if anyone wishes to discuss PRs I'm working on, please do so with me present.
The chance of getting anything universally promised is essentially impossible. Has this been discussed in the newsgroups anywhere? If I am not mistaken we are discussing one view in the SDK currently. I agree with the sentiment that should the debug team agree we could move the preference to the workbench and allow others to use it but I am concerned that we are going to break a lot of affordances in other products by doing this. Generally the approach of willful adoption is safer than forcing a change in behaviour on plug-ins without thier knowledge,
The only thing I can think of that somehow walks the careful walk between forcing change in behaviour and avoiding need for willful adoption is something like a popup blocker in a browser (although not introduced as if something bad happened), where the first time a few is brought to the front without the user causing it, a dialog opens and says "The <view name> view thought you should see it's contents and hence came to the front, do you want to disable this feature for the <view name> view in the future? See ? preferences to re-enable in the future." |Yes| |No| [] don't ask me again OR remember my decision
Re: comment 25 That looks fine to me.
There are currently no plans to work on this feature. PW
I still find this to be a severe usability problem in Eclipse and Eclipse-based products. I'm still interested in working on this myself if someone will consider committing the patch.
If this is still under consideration for 3.3, now would be a good time to look at it. :-)
Created attachment 59186 [details] Grab Focus v02 This is just an update to HEAD so it can be used for testing. PW
Created attachment 61721 [details] Grab Focus Hooks v01 org.eclipse.ui.tweaklets.grabfocus is in the platform-incubator project, and this is the matching hook patch. PW
Released to HEAD >20070325 We haven't finalized the deployment for tweaklets, so I'll attach a plugin that can be used for testing. The actual tweaklet is in platform-incubator/ui/tweaklets/org.eclipse.ui.tweaklets.grabfocus Stefan, I didn't include a pref. Boris suggested that if we want one, install a Tweaklet node and the pref page underneath that. I won't have time to do the pref page, but if you want to tweak the tweaklet (haha) feel free. PW
Created attachment 61929 [details] grabfocus plugin 20070325 Drop this in your plugins directory and you'll get the prevent grab focus behaviour. PW
This is a tweaklet in 3.3 PW
With tweaklet in I20070503-0842 PW
