GNOME Bugzilla – Bug 326159
Experimental strict-focus-approximation feature
Last modified: 2006-05-15 17:10:32 UTC
I emailed Havoc about this a few months back and he said it'd be worth a shot. My rationale in that email (kind of long winded) was: In bug 151818 comment 22, I basically argue that most users tend to launch windows and then use them when they appear, meaning that (a) new windows should get focus by default and (b) minimizing window movement should trump minimizing occlusion for the window placement algorithm. If the usage pattern is to launch windows and defer using them, then the results should be reversed. There are a few reasons users tend to use windows when they appear (e.g. most basic users try to do one thing at a time, launchers on the desktop or menu on the panel don't lend themselves to quick-fire launching of several applications or other commands anyway). However, the opposite tends to be true for terminal users for various reasons (these aren't basic users, the terminal is setup for trying to do lots of commands at once especially with the fg & bg & screen commands, quick-fire launching of commands is just a way of life and encouraged and rewarded at the command line, such users tend to often have lots of terminal windows and/or emacs windows and/or all kinds of other windows while they keep an eye on multiple of them, cute tricks like launching a viewer application then using ctrl+c to close it without having to do multiple application switches, etc.) In fact, although I prefer the focus-by-default behavior (I often use the panel menu or panel launchers to start apps and find it weird if those apps don't show up with focus), I have often wanted things started from the terminal to not get focus. I have even resorted to setting DESKTOP_STARTUP_ID to _TIME0 in the enviroment (thus lying and pretending it was launched with startup-notification) and other stuff to get such behavior. So, the best solution might be not giving things launched from terminals the focus, though I wouldn't know how to do that. An equally effective solution might be to not have new windows get focus if the focus is currently on the terminal (at least for sloppy/mouse focus, as then this would just be saying that new windows shouldn't override the invariants when the focus window is a terminal). Also, it's worth noting that each and every case where people have explained why they wanted strict focus (and there's been a fair number now) has begun with "In a terminal...". So, I'm betting that this intermediate behavior would solve the strict focus requests without adding a preference while simultaneously improving behavior for those people that tend to make use of both ways to launch things, like me. It's hard to be sure without trying it, but I think it might be worth a try. It might need a new window type (META_WINDOW_TYPE_TERMINAL) and/or temporary hacks based on window class to detect current terminals so I thought I'd run the idea by you to see what you thought. Anyway, this is related to bug 152004, but because I consider it experimental, I decided to file it separately. I'll attach a patch in a minute; it seems sane in my use, at least.
Created attachment 56945 [details] [review] Terminal usage is fundamentally different in terms of user expectations; here's one shot at smart inbetween behavior to handle it
This might be one you want to avoid right before a freeze? I'm fine with the patch, other than its hackiness (maybe it would be better to invent a hint and add it to gnome-terminal and just only support gnome-terminal? I dunno). Seems like there's a good chance it will be too magic and confuse people, but trying it out will let us know...
Well, I'd like to push it now considering that (a) it's just feature freeze (meaning we have two months to apply a one line patch to undo the feature if needed), and (b) that I really do feel we need more info about the usage scenarios of those wanting strict focus. Besides, unlike bug 326041, this patch won't uncover buggy apps and therefore won't mean extra time demanded of us working with other module authors, plus it doesn't affect the normal users since terminal users tend to be more advanced. I agree that the hackiness sucks, but it was somewhat deliberate and will only be temporary. I think that to get enough feedback I want it to apply to far more terminals (especially given the problems of gnome-terminal and vte causing many to not use them) which isn't feasible with a new property. Anyway, I'll add the following comment above window_is_terminal() (in addition to renaming that function with a double leading underscore to show that it's weird): /* This function is an ugly hack. It's experimental in nature and ought to be * replaced by a real hint from the app to the WM if we decide the experimental * behavior is worthwhile. The basic idea is to get more feedback about how * usage scenarios of "strict" focus users and what they expect. See #326159. */ Also, one thing I forgot to mention in this bug (which I'm only mentioning now for historical purposes for those that run across this bug) is that other than an orthogonal raise option (see bug 326156) a strict focus option is the only behavior that I found that is patched in by more than one distro-not-having-a-common-maintainer -- in this case being provided by both Debian & Ubuntu, and RHEL. Given that and stuff like http://lwn.net/Articles/148007/ (among many others), I want to understand the reasons behind this more. I think I understand it and explained it in my original comment, but I am not sure.
Created attachment 57117 [details] [review] Add some underscores to window_is_terminal() and explicitly state that its code is a _temporary_ ugly hack As mentioned in my comment above, I'd like the hack for now but agree that it should be temporary and have added a comment to that effect.
As per Havoc's comments in #2, I'm assuming the fixed up patch is okay to go in for now. Kick me if I'm wrong.
I am finding this feature to be annoying. When I launch applications (even from the Applications menu) they always open behind my gnome-terminal window. It seems to me that if I wanted my gnome-terminal window to stay on top then I could have just selected "On Top" from the Metacity window menu. Thanks.
Right, I noticed that and know the fix for it; I'll cook up a patch. :)
Created attachment 57324 [details] [review] Fix the problem pointed out in comment 6
Ubuntu bug about that: https://launchpad.net/distros/ubuntu/+source/metacity/+bug/28607 "The new metacity in dapper (2.13.13) has a feature which allows terminal windows to keep focus even if a new application is started. As I use gnome-terminal very often I find this behaviour very annoying: everytime I start a new application (be it from panel, menu, global keybinding or gnome-terminal) I've to focus the new window manually if gnome-terminal had the focus. I'd prefer if this behaviour could be turned on/off . If this isn't possible, please at least apply the patch from http://bugzilla.gnome.org/show_bug.cgi?id=326159#c8 which should make this behaviour less strict. Thanks."
I don't like this feature neither, even with the patch from comment #8. When I start emacs from a command line that's to use it, not to have it placed behind the command line and have to switch
Committed the new patch; sorry about that bug. Windows started from panel launchers, the panel menu, global keybindings, etc. should now be focused.
And windows started from the command line? Like "emacs something"?
*** Bug 327188 has been marked as a duplicate of this bug. ***
Just my own 2 cents: I often start applications from the command line, but not because I like to fill my task bar, but because I actually want to use them. So personally I find the current behaviour pretty inconvenient. I would like to see all windows that I deliberately requested (as opposed to e. g. an incoming gaim dialog) get the focus. The task bar behavior of minimizing a window instead of bringing it to the foreground aggravates this problem, so it always requires at least two clicks to eventually see the newly started application. Thank you for considering!
*** Bug 327878 has been marked as a duplicate of this bug. ***
Just an AOL to c#14: when I start an application, I expect it to ... start. Popping under gives me no visual indication that the app has actually started, other than the phenomenally ugly brief flash of a window mapping, and then being lowered in the stack. It's a very odd occasion when I go to start an application and don't actually want to use it. Generally, I'm starting mplayer, which I expect to just appear. The fix from c#11 is much better. The biggest aggrevation was having my Gaim buddy list pop under g-t, but that's seemingly been fixed, so. Even so, I find this behaviour hideously breaks my expectations; it's nothing like what I can think of in any other window manager. I really like the new focus stealing stuff, which basically matches my expectations exactly. But the strict-focus-approximation mode just makes me angry every time it triggers.
I've been finding this change very aggravating when trying to develop and test a PyGTK application; I sat around for a while wondering if my program was missing some startup notification magic before somebody on IRC pointed me to this bug. If I wanted to launch lots of things in quick succession from a terminal, I'd use 'foo & bar & baz &' or similar to launch them all at once without having to return focus to the terminal each time. Otherwise, I want launching graphical applications from a terminal to work the same way that launching command-line applications from a terminal works: i.e. by default they should appear in the foreground. This change effectively auto-backgrounds all graphical applications, which runs contrary to my expectations as a terminal user. If it's possible to tell whether a window has been launched in the background from a terminal, then that would be ideal; but even if that's not possible, I would much prefer that the default "foregroundness" for new windows launched from a terminal be analogous to the default foregroundness for command-line programs.
Similarly, this new behaviour even sucks in cases when I did not actively request a new window; e. g. it is very inconvenient to actively select gnome-gpg windows; in earlier versions they got the focus right away (at least when I wasn't typing anything at that moment), now I have to reach to the mouse and select it. Likewise with ICQ windows, g-v-m notifications, etc. Please restore the old behavior 'select new windows unless the user is currently typing something' (not stealing focus while typing is a veeery good thing).
I'm finding this new behavior very annoying. I tend to start things from the shell because I don't like using a mouse. Here's three areas that particularly frustrate me: I try to play a video in mplayer. My mplayer is set up to default to full screen, so what I end up with is the video playing, full screen, behind every other window including the gnome panels I keep at the top and bottom of my screen. At work I frequently connect back to my home machine via vncviewer. Even though it's ssh tunnelled I still have a password set, and now the password request dialog pops up behind everything else, forcing me to grab my mouse and click it to bring it to the front. I keep four terminal windows open (many with multiple tabs, but that's besides the point.) Alt-tabbing between these terminal windows is frustrating now. Usually I end up in the same window I tried to get out of. I have to alt-tab repeatedly to get it to actually let another window come to the top.
Au contraire! I like the new behavior. It always irritated me that, while I was working, waiting for some window to come up, that the focus changed when it came up. I alone want to determine when to change focus. Since people seem to be in violent disagreement, perhaps the optimum solution is to provide user-settable options amoung the various behaviors.
I like the general idea of this behaviour and haven't noticed the Metacity implementation of it getting in my way yet. Apple has implemented this in OS X's WM and it's a huge relief to not have to worry about new applications jumping in front of what you are currently working on. Some applications don't seem to play nicely in OS X though, like Firefox.. so I don't know exactly what Apple's done but a quick study of the OS X behaviour should probably be done to see what their compromises are and apply that knowledge to Metacity.
Really, it hasn't done me any good until now, and only increased the number of key presses I need to get to an application (first launch it, then switch to the window it has opened). If it is useful, it's probably not in most of the situations, based on which a default behaviour should be designed. This should really be a configurable thing disabled by default so power users who see fit can enable it at will.
I've just tried 2.13.89 and I can't say that I like this feature. If I start an application from a terminal it's because I want to use it. Having it appear underneath the terminal window is counterproductive. The main reason we run applications from the terminal is to see debug output. When the application starts we always want to interact with it, for a while at least, then return to the terminal to see why it fell over ;-)
Elijah, please? :)
Besides gnome-terminal, firefox also launches apps behind it. For example, bittorrent.
The new behavior is really irritating. The cure is worse than the disease!
Created attachment 61093 [details] [review] Make "strict focus approximation" configurable
I think we are too near to the final release to apply this patch. It's really unfortunate that GNOME 2.14 will ship with this behaviour.
Patch looks mostly okay in concept and I'll probably apply a fixed-up version during 2.15 (maybe 2.14 if cries are loud enough that lots of people agree to the free breaks). Just a couple pointers: - Please use the -p flag (as well as the -u flag you already use) when creating patches; not doing so makes the patch harder to read - I'd rather have an enumerated like type than a boolean one for this flag. I'm not convinced we understand a wide enough set of usage cases (as well as not necessarily having a smart enough default yet) to narrow it to a boolean[1]. Also, although we won't want to support all weird permutations, making it a string will make it easier for other people (or distros) to modify. Thus, please make this a string type preference with two valid values for now. [1] See also the patch filed from Havoc in bug 152004; while it did lots of stuff that is now unnecessary, it indicates (and I've read this elsewhere as well) that there are people who for some reason like don't-ever-focus-new-windows-no-matter-what. That's just one example of a different dimension to this issue.
Created attachment 61120 [details] [review] Make strict focus configurable
From an accessibility point of view, this change is *very* annoying. If a blind user starts another application from gnome-terminal and it gets "put to the back" with no focus, they immediately have to use Alt-Tab to find it and give it focus. Assuming they know that this is what has happened. If you really think this should be the default (and I'm one of those sighted users that doesn't like this either), then having the ability to configure it to turn it off, is acceptable. Personally, I'd prefer if the default was to disable this "feature". Thanks.
When commands are run from the terminal, bash sends some control sequence when each new command prompt is printed, notifying the terminal emulator as to what the user's current directory is. gnome-terminal displays this in its title bar. It should be fairly straightforward to allow focus stealing by default, but prevent focus stealing for the launched window if the gnome-terminal title text is set after the last text the user typed. This would allow for focus stealing when a user enters a command without an ampersand at the end, but would prevent focus stealing when the user enters a command with an ampersand. (If launching a command pops up a window, it is highly unlikely that the app should be doing anything with stdin, so if the terminal is blocking on stdin, then it is likely that anything the user types is just going to /dev/null anyway, and focus-stealing shouldn't be prevented.)
The patch looks good, all I have is a stylistic comment: I'd prefer the key were named "focus_new_windows" instead of "strict_focus_mode" as far more people will understand the former. The two choices would be "smart" (2.12's default behavior and the default once this key is added) and "strict" (2.14's default behavior; a different name for this one might be okay but I couldn't come up with anything better). Then, for the weirdos out there that really want an "always" or "never" option, it'll be easy for them to create. Yeah, I know that "strict focus" is in some places (Debian/Ubuntu) used for what I mean by "never" here. Like I said, I'm open to better names for what I called strict. Thanks for working on this. :)
Created attachment 61971 [details] [review] Revised patch to configure new window focus
Well, I think this is kinda crazy and exactly the kind of wacky embarassing setting metacity was designed to not have. But Elijah is doing most of the work these days, so it's tough for me to take a hard line... GNOME in general is certainly going more in the shell-users/UNIX-users direction and maybe it's even right for that audience to have this.
*** Bug 336944 has been marked as a duplicate of this bug. ***
(In reply to comment #35) > Well, I think this is kinda crazy and exactly the kind of wacky embarassing > setting metacity was designed to not have. But Elijah is doing most of the work > these days, so it's tough for me to take a hard line... GNOME in general is > certainly going more in the shell-users/UNIX-users direction and maybe it's > even right for that audience to have this. I don't feel that this adds any value to me, as a shell/UNIX user (the only thing I launch from the menu is Firefox: everything else is from the shell). It only confuses and annoys.
*** Bug 337422 has been marked as a duplicate of this bug. ***
*** Bug 337501 has been marked as a duplicate of this bug. ***
I use lirc with irexec to open xine and mythtv with a remote control. I find that if I happen to have a terminal open, then they will inconvienently open up behind the terminal. However, I appreciate that there are times when the feature would be useful. I think that the suggestion made by Luke Hutchison is the most logical and consistent approach: allow users to choose whether to open new windows in the foreground or background depending on if the command line ends with an ampersand.
Let me point out that the bug is not just with the command line, but everything. Try the following, the end result is pretty annoying: (from bug 337422) 1. start maximized gnome-terminal 2a. select 'Open Terminal' from context menu or Ctrl+N 2b. select 'Open Link' from context menu 2c. run 'gvim' on command line
Tommi: You gave three examples of launching things from a terminal; and thus not a single counter example to this bug having to only doing with the terminal. ;-) Luke's options has two problems: (a) it'll be nearly impossible for us to determine if an app was launched with an ampersand, (b) it's not really the point -- people want to do things like launch a simple app like xv or eog and then hit ctrl-c to cancel out of it. Rich: The accessibility scenario you describe doesn't make any sense: (1) We already prevent focus stealing for e.g. getting new IMs from someone and your arguments would mean we'd have to revert that behavior (re-introducing security bugs--someone accidentally got a kernel hacker's root password by IMing him at just the right time), and (2) accessibility can check for the demands-attention hint for such windows just as is done for windows denied focus in other cases. Havoc makes a really good point; however, given that (a) it was *his* suggestion to add a pref for strict focus in the first case (see bug 123803 comment 4 and bug 152004), and (b) as noted in bug 326156 this is the other significant option that distros are patching in, I'm thinking we should include it. My big question is why is Ubuntu patching out this strict focus, and adding a different one in with a pref, instead of just doing what Ron's patch does and making this be the pref? CC'ing seb128 -- if this patch is applied will you have it replace your current strict focus patch or do you intend to keep adding that patch? Another way of asking that, is do users of the traditional strict focus kludge that has been patching into Debian/Ubuntu actually have an usage scenarios for which the "smart" strict focus behavior does not suffice; data I have so far suggests that the "smart" behavior is good enough for them and improves things for other users but you might have a bigger sample of users to query than I do.
Umm, I said command line, not terminal.
Elijah, of what are you talking about exactly? We do patch that "put apps starting from command line to the background" out (005-strict-focus-approximation-patch-326159.patch) because the echo we got about it was not good and it was annoying for most of the distribution team working on Ubuntu. Note that we did that after some weeks of upstream ignoring the comments made on the topic If you speak about 001_strict_focus.patch, we ship it since january 2005, that was a patch sent by one of the members of the Ubuntu distribution team not pleased with the window manager trying to be smart and the bugged applications breaking that. I'll ping him to know if the "smart" mode would be good enough for its usecase, I see no objection to replace it for my part
Just brainstorming alternatives that might satisfy the constraints people have mentioned -- My understanding is the *only* reason for prevention of focus stealing is to prevent the cases where: (1) the user is typing into an old window, and keeps typing while a new window opens, and thus inadvertently sends characters to the new window; (2) less frequently, the user is not typing into the old window, but decides to type into the old window just as the new window opens. (The effect is the same, but there is no timestamp saying the user recently typed into the old window.) (Did I miss anything?) I think it is not right to say there is only one solution to any problem, in this case that the only solution is to put the new window behind the old one and to blink the panel button. Perhaps alternatives could be brainstormed? There may be a less controversial fix... Given that the above situations always occur within the first few seconds of the new window opening, the situation can be detected relatively easily, setting time thresholds to balance the appropriate proportion of false positives and false negatives. Let's say that the new window is opened at the front (old Metacity behavior) and it is detected that the user types into the new window "too soon" (case (2) above), or "too soon after typing into the old window" (case (1) above). How can that be handled? Suggestions: (a) if the new window is a modal dialog, disable keyboard shortcuts to its buttons during the initial time period, i.e. silently swallow keyboard input (yes there are problems with this, just brainstorming) (b) [perhaps better?] pop up a dialog that says, "You just typed 'ls -l<Enter>', and the window you ended up typing into just opened. Did you intend to send this keyboard input to the previous window, or this new window? Click [OK] to send this text to 'Gedit (unnamed.txt)', [Cancel] to send this text to 'gnome-terminal (~/Documents)'" [Then disable text input into this dialog for a couple of seconds to avoid cascading the problem!] If the user selects Cancel, then focus is returned to the old window and the new window is put behind the old one. Otherwise the text is forwarded to the new window, and it is left at the front. There could be a GConf key that specifies a list of exceptions, and the few hackers that like to have windows never open at the front when launched from gnome-terminal could simply add 'gnome-terminal' to that list of exceptions. Any other ideas?
(In reply to comment #44) > Elijah, of what are you talking about exactly? ...I'll ping him to know if > the "smart" mode would be good enough for its usecase, I see no objection to > replace it for my part. I guess I wasn't very clear, but it looks like you understood anyway. I just want more feedback on whether Ron's patch, if applied, would be enough to replace 001_strict_focus.patch for you guys. (I'm assuming of course, that it'd also circumvent the need for 005-strict-focus-approximation-patch-326159.patch, for obvious reasons) The historical context is that both Debian/Ubuntu and RHEL had a strict focus patch. I tried to figure out why people wanted that and from what I can tell, the "experimental strict-focus-approximation" feature *is* what those users wanted (and makes that feature useful to a wider set of users than the old strict focus patch would be, even if it unfortunately isn't good enough to be the default behavior). But, that's a relatively small sampling of users that I've been able to query so I was just asking for more feedback.
(In reply to comment #45) > Just brainstorming alternatives that might satisfy the constraints people > have mentioned -- Always welcome. :) But this bug isn't really about "focus stealing prevention" and I find it odd to be discussing in those terms here. It is related in that it is about whether to focus new windows, but focus stealing prevention is all about the set of users who _normally_ expect to use windows when they launch them and figuring out the special cases where windows shouldn't be focused when they appear. This bug is about users who don't expect to interact with windows when they launch them until they later manually go focus them. That may sound weird to many people, but there is a large group of such users. See the Debian/Ubuntu/RHEL strict focus patches. See bug 152004 and countless others. Also http://lwn.net/Articles/148007/. I tried to figure out if the differences in expectations of these users was just due to different methods of launching (e.g. command line vs panel launchers and such) or other behaviors. As far as I can tell, that appears to be partially true. And I think that my patch + Ron's is a smart behavior that makes things more usable for this group (still pending further feedback from seb128). But there's enough of a split that it can't be handled in the default behavior and needs a pref if it is to be handled. I do like some of the ideas with timing and special handling of input to new windows for a brief interval. Someone mentioned things along this line elsewhere (something about MS Windows disabling input temporarily to avoid accidental dismissal of dialogs, IIRC). I don't know whether the WM or the toolkit should be responsible for such actions, and there might be accessibility ramifications (as there always is when the issue of timing comes up), but it may be worth pursuing further. But it might be worth investigating. But I think it's a different bug report and that it's related to focus stealing prevention rather than a strict focus mode.
Elijah, w.r.t. accessibility. My colleague Will Walker had a similar concern which he reported as comment #82 in bug #149028 ( http://bugzilla.gnome.org/show_bug.cgi?id=149028#c82 ) In short, you responded that this is a gnome-terminal bug, and needs to be fixed there. Fine. It sure would be nice that when you add a new feature like this, that you work with other parties involved (i.e. gnome-terminal, accessibility), and make sure that everybody plays together well before the new feature is fully integrated. As I said before, as long as there is a way to turn this feature off, it should be just fine. One final comment. Over the years, one of the things I've learnt from the HCI experts is that when you use software, it shouldn't surprise you. Things should be intuitive and obvious. GNOME 2.14 desktop windows "jumping to the back" because the window manager put them there, surprised me.
(In reply to comment #48) > In short, you responded that this is a gnome-terminal bug No, I didn't. I said it was an issue separate from focus stealing prevention and pointed him to another metacity bug (this one) rather than a gnome-terminal bug. See also comment 47 of this bug. > and make sure that everybody > plays together well before the new feature is fully integrated. gnome-terminal needed no changes. accessibility already had to be modified previously to handle focus stealing prevention; those previous changes would be sufficient without extensions to handle other don't-focus-new-windows situations like the one in this bug. So the point is moot AFAICT. > As I said before, as long as there is a way to turn this feature > off, it should be just fine. > > One final comment. Over the years, one of the things I've learnt > from the HCI experts is that when you use software, it shouldn't > surprise you. Things should be intuitive and obvious. GNOME 2.14 > desktop windows "jumping to the back" because the window manager > put them there, surprised me. Giving focus to the new windows launched from the command-line was surprising (and annoying to no end) lots of users. See other parts of comment 47 for a small sampling of places to read up on this. By this criteria that you just listed, the new feature introduced in this bug was therefore good and well needed. Right? Sorry, I couldn't resist the sarcastic rhetorical question. ;-) But basically, you assumed that this decision should have been obvious, which implies that you are either more important than the other users, or that there are clearly more users like you than otherwise. I think it is obvious now due to lots of extra feedback that makes me pretty certain that you are among the majority, but I don't feel it's a fair implication to make about the situation previously.
(In reply to comment #49) > Giving focus to the new windows launched from the command-line was surprising > (and annoying to no end) lots of users. How is it surprising that when you launch a windowed program from the commandline, the window is going to open at some point? And that focus will probably be taken by the windowed app when that happens? The only situation I can think of that this might actually be "surprising" is if the user has run the app in the background using "&" or "Ctrl-Z bg", and knows the window will open eventually but doesn't know when. Hence my suggestion in Comment #32, that maybe it's good to try to figure out whether an app is backgrounded or not, because that seems to lie at the core of the problem. The situation you describe in Comment #42, where the user might want to Ctrl-C out of an app after starting it is an entirely separate issue from being "surprised". And of course if the window is already open, they can accomplish the exact same thing with Ctrl-Q or Alt-F4, so there's no lack of keyboard control. Also, if you weigh up the frequency that a user will actually try to quickly abort a program when they run as a fraction of total commands run from the commandline, and multiply that by the fraction of total users that actually run a lot of commands from the commandline and demand that sort of control, your arguments are not really statistically justified. Besides, isn't GNOME trying to deliberately cater to the unskilled user more than the KDE types? :o) I second Rick's comment about UI predictability here.
One other comment about the element of surprise, because I don't think I made my logic clear in Comment #32 and Comment #50. If the power user launches a windowed app from the commandline and then continues typing into the terminal, one of the following things must be true: (1) The windowed app has to accept input keyboard-entered input from stdin in addition to input through its main window. How many apps like this do you know of? (2) The user is typing at the app and it's not listening to stdin, so their keystrokes are going to /dev/null. Silly user. (3) The user launched the app with an ampersand. The app starts backgrounded. (4) The user has hit Ctrl-Z before a window opens then types "bg", and is still typing. The app is backgrounded when the window opens. (This is the situation you are probably mostly describing.) (5) The user types Ctrl-C before a window opens, and the app never gets to open its window. (6) The user tries to hit Ctrl-Z or Ctrl-C after the app has opened its window, intending to have those keys go to the terminal, but they are sent instead to the app window. In situations (3) and (4), the app is backgrounded when the window opens. Putting the difficulty of detecting this aside for a second, if this can indeed be detected it could be used to open the window behind the terminal when the app is backgrounded. (Comment #32 gives a suggestion of how to be notified every time the command prompt has been displayed, so you know if you have a "live" terminal.) In situations (4) and (5), the user has typed the keys faster than the window opened. Clearly there are slow systems and slow programs around that will increase the likelihood of this, although from a pragmatic point of view, programs open really fast on every system I use these days. Whether the user might *want* to get one of these two "power keypresses" in before the window opens is a separate issue. The workaround to Ctrl-Z is the ampersand; the workaround to Ctrl-C is Ctrl-Q. Assuming the user tries anyway to hit Ctrl-C or Ctrl-Z, we get situation 6. This can be ameliorated by the suggestions in Comment #45. There are lots of comments surrounding this whole issue that the user "might want to" keep typing into the terminal. However I don't know of any situations other than the above, and I have tried to break down the possible scenarios systematically. Given this list of scenarios, the number of situations that can't be handled in an unsurprising way seems very small.
(In reply to comment #50) > (In reply to comment #49) > > Giving focus to the new windows launched from the command-line was > > surprising (and annoying to no end) lots of users. > > How is it surprising that when you launch a windowed program from the > commandline, the window is going to open at some point? And that focus will > probably be taken by the windowed app when that happens? That a window will eventually open isn't the surprising part; it's the relative speed at which it does so. It's annoying if it's fast enough that it's just barely quicker than the users typing speed when the system isn't loaded but isn't that fast at other times. (And, technically, there's also a problem in that focus-stealing-prevention is totally defeated when launching things from a terminal because it becomes impossible to determine when the app was launched in the general case; bash and other shells don't comply with the application launching spec stuff in the EWMH; sure, this probably shouldn't be used to weigh decisions either way, and thus I'm making it a parenthetical comment, but it is a huge technical caveat that is worth keeping in mind in addition to other factors) > The only situation I can think of that this might actually be "surprising" is > if the user has run the app in the background using "&" or "Ctrl-Z bg", and > knows the window will open eventually but doesn't know when. Hence my > suggestion in Comment #32, that maybe it's good to try to figure out whether > an app is backgrounded or not, because that seems to lie at the core of the > problem. That sounds like it'd solve part of the problem, if technically feasible. But, as far as I can tell from reading comments on the matter over a course of years, I strongly suspect that those who launch an app in the background and don't like the current strict-focus-feature would do so merely so they could come back to the terminal and type more commands later (They may not be familiar with Ctrl-Z plus the bg command, or may think it's just too much of a pain). Also, given that several commands can cause windows to open and return to a command prompt without using the '&' character (e.g. happens for me when I run 'mozilla' since it ends up just telling a previous instance to open another window and then exits), I don't think this idea will work for the users who like strict focus either. So, as stated, I think it'd work part time for both kinds of users but end up negatively surprising both kinds of users at times too. I hope this doesn't come across as negative. It's a very useful comment and idea you had. I like it from a brainstorming perspective; I had never thought along those lines before. It has given me some useful things to think about. I'm just pointing out what are potential problems to see if you or others can perhaps refine the ideas or come up with alternative solutions (and maybe help get me thinking of more ideas too). > The situation you describe in Comment #42, where the user might want to > Ctrl-C out of an app after starting it is an entirely separate issue from > being "surprised". Yes, I was listing it as an additional issue; my apologies if I didn't make that clear that it was separate. > And of course if the window is already open, they can accomplish > the exact same thing with Ctrl-Q or Alt-F4, so there's no lack of keyboard > control. Ctrl-Q isn't universal. Good point with Alt-F4, though it can be intercepted by the app and thus won't necessarily close. I'll try to remember this and point it out to users that often do things like this and see if it's close enough for them or if it has annoying problems. I suspect they just needed to learn a new keybinding, though I'm not certain. > your arguments are not really statistically justified. I never claimed that they were -- no significant statistics were available. Also, you've tried to compare only against the case of quickly aborting and trying to ignore other reasons for strict focus, which I don't think is fair as pointed out above. > Besides, isn't GNOME trying to deliberately cater to the unskilled user more > than the KDE types? :o) We're talking about the behavior with respect to terminals. I don't see how this is a relevant argument regardless of the viewpoint you have with respect to this bug report. ;-) But, honestly, this really is the big problem. This bug is all about subsets of a minority userbase -- those who use the command line (and thus the decision really ought to be totally irrelevant to Gnome if it's focusing on e.g. mainstream business users or similar). Determining the minority and majority of a niche userbase isn't easy (are the ones complaining a result of a dissatisfaction of the majority that is getting out, or is it just a loud minority?). Debian, Ubuntu, and RHEL took the easy route out by adding a kludge for some of these users. I was just trying to figure out why this 'strict' focus behavior was used, and found a compromise that made it useful to me as well. From the feedback I have, the compromise seems to be good for the strict focus users. Unfortunately, this group is a minority (yet another one that I'm a part of, I guess) and the compromise doesn't work for the majority. But, hey, I figured out smarter behavior for part of the users, and we can return the default behavior to the old 2.12 way. > I second Rick's comment about UI predictability here. So did I. ;-)
(In reply to comment #52) > That sounds like it'd solve part of the problem, if technically feasible. But, > as far as I can tell from reading comments on the matter over a course of > years, I strongly suspect that those who launch an app in the background and > don't like the current strict-focus-feature would do so merely so they could > come back to the terminal and type more commands later (They may not be > familiar with Ctrl-Z plus the bg command, or may think it's just too much of a > pain). Yes, you are right. Again though it might be worth it to try to actually figure out just how large a chunk of users you're talking about when you say "those who launch an app in the background and don't like the current strict-focus-feature". Each successive corner case seems to cover a smaller group of users :-) At least you can make the behavior consistent to the user if you say something like, "If you launch a program in the background using &, then it will open behind the current window. Otherwise the behavior will be consistent with every other situation on your desktop, where the window is opened on top". > Also, given that several commands can cause windows to open and return > to a command prompt without using the '&' character (e.g. happens for me when I > run 'mozilla' since it ends up just telling a previous instance to open another > window and then exits), I don't think this idea will work for the users who > like strict focus either. So, as stated, I think it'd work part time for both > kinds of users but end up negatively surprising both kinds of users at times > too. This is not relevant -- Comment #32 referred to a way of detecting whether a new command prompt had been printed to the terminal, regardless of how it got there (whether the program died, or spawned a disowned child process and exited, or printed an ampersand, or was stopped or killed with Ctrl-Z / Ctrl-C. Metacity can do this directly by simply watching for requests to change the window title text for terminal windows. Doesn't even require any vte magic. Do you want to try it out and see if you think it feels natural?
(In reply to comment #53) > > run 'mozilla' since it ends up just telling a previous instance to open another > > This is not relevant -- Comment #32 referred to a way of detecting whether a Ah, sorry, I misinterpreted the point you were making. I understand now that I have thought about it more -- you are saying that giving the user a rule that is supposed to give consistent control over focus behavior (e.g. tagging on a "&") breaks down if an app launched from the commandline is not consistent with that policy (e.g. drops you straight back to the commandline). You make a good point. I was looking at it from the point of view of consistency of the effect of the command (i.e. whether the user gets the command line back after launching the command), not consistency of the form of the command (i.e. whether the behavior is always the same with and without explicit backgrounding). From that point of view, it is always a little unnerving when programs like firefox and nautilus do the non-standard thing of launching a new window in an existing instance, or disowning a child process, and dropping you back to the commandline... maybe they are what is broken as far as consistency :) Sorry, I am also not trying to be inflammatory about this, just trying to add some comments asking for (and trying to add) a more rigorous, case-by-case analysis of what the real usage is, and how the current situation would or wouldn't break down in each case. I still think there may be a solution that is not just a further complicated set of heuristics on top of the current ones, but in order to find that sort of solution it may require some stringent logical analysis of what's really going on.
(In reply to comment #53) > Yes, you are right. Again though it might be worth it to try to actually > figure out just how large a chunk of users you're talking about when you say > "those who launch an app in the background and don't like the current > strict-focus-feature". Each successive corner case seems to cover a smaller > group of users :-) I should have been more clear. I meant to say "I strongly suspect that most users complaining about the current feature" (i.e. what appears to be the majority of terminal users and not any extra corner cases) "would dislike having an app show up without focus even if launched with an ampersand at the command line." Or, restated, most terminal users launch an app in order to use it immediately; the usage of the ampersand is just a convenience for whenever the user gets back to the terminal, not necessarily an indication of wanting a different focusing behavior. > Metacity can do this directly by simply watching for requests to change the > window title text for terminal windows. Doesn't even require any vte magic. > Do you want to try it out and see if you think it feels natural? After investigating further, this fails for two reasons: 1) From a simple patch I tried, Metacity gets no notification for the title from gnome-terminal in response to most commands (e.g. 'ls') that are run. It only gets a notification if the title actually changes (i.e. when the directory changes) rxvt is the same way. konsole does notify at the completion of every command, so of the three it seems to be the only one that does what you were claiming and assuming. 2) If all terminals really did behave as you suspected, then we could obtain the time at which the title was last updated. But that still leaves us with a missing piece of information -- the time at which the window was launched. That information isn't available unless the app supports the startup-notification spec AND it was launched by a startup-notification-compliant launcher (which bash and other shells are not). (In reply to comment #54) > I still think there may be a solution that is not just a further complicated > set of heuristics on top of the current ones, but in order to find that sort > of solution it may require some stringent logical analysis of what's really > going on. You're definitely unusual; most people wouldn't attempt to do this work. Thanks for the efforts. You've helped me think about the problem in a few more dimensions and I like how you're trying to break down all the cases. I hope I don't appear too critical or dismissive as I try to poke and prod different ideas.
In my opinion, opening new windows underneath causes lots of confusion, and is not a good default. For defaults, how about the following behaviour: In sloppy and click to focus modes, new windows appear on top and get the focus In 'mouse' focus mode, new windows appear on top, and only get the focus if the pointer actually lies in the window. If opening windows below is desired, that could happen via a configuration setting.
I spend most of my day on the command line. I've been on FC5 for all of twelve hours and already I hate metacity. Opening windows behind the terminal is very broken. Please, please, please fix this quickly.
I'm seeing a yardstick emerging here... if there's no clear consensus about which group of users is larger or more "important" (out of those who like a certain behavior and those who do not), or if every change to a non-configurable default turns up new unhappy users, there is a pretty clear case for making the behavior configurable until a version of the behavior is found that nobody ever needs to "turn off".
Ron's patch has been committed to CVS HEAD. Pending approval from the release-team (see http://mail.gnome.org/archives/release-team/2006-April/msg00019.html), it will be applied to the 2.14 branch. If the release-team turns it down (feature & string freeze break after the .0 release doesn't look good, so this may be likely), I'd just suggest distros with disgruntled users manually apply the patch. Thanks for the work, Ron. :)
*** Bug 152004 has been marked as a duplicate of this bug. ***
Just FWIW, the changed behavior has made my life much more pleasant. It is aggravating to have the focus taken away from active windows, and the changed behavior has fixed most of those issued for me. As long as it remains configurable, though, I guess I don't care if it's the default.
To follow up on comment 59, metacity-2.14.3 has been released with this focus behavior reverted. It is a configurable pref, recoverable via: gconftool-2 --set /apps/metacity/general/focus_new_windows \ --type string strict Release announcement at http://mail.gnome.org/archives/gnome-announce-list/2006-April/msg00030.html
*** Bug 338779 has been marked as a duplicate of this bug. ***
I just brought in metacity 2.14.3, and I can confirm that the bahviour is reverted. Yeay! AfC
... except that the patch doesn't completely restore the old behaviour, as it seems to ignore changing to another workspace. :-/ Let me explain: I use a dedicated workspace with several terminal windows for compiling stuff. I have a script that basically does the ./configure && make && make check thing, then pops up a zenity window when it's finished. I usually start the script, then switch to a different workspace to do some web browsing, e-mail stuff, whatever. Before that annoying strict-focus thing, the zenity window would pop up on whatever workspace was currently active, and remind me to go check the results of the build. Now, it always pops up on the workspace that it was started from, and I only ever see it if I happen to switch back to the compiling workspace to check the progress myself - which makes the whole thing pretty much pointless and useless. To reproduce: 1a. Hit Alt-F2, click "run in terminal", and run 'sleep 3; zenity --info --text test' 1b. Alternatively, start gnome-terminal, and run 'sleep 3; zenity --info --text test' 2. Switch to a different workspace 3. Wait 3 seconds 4. ... 5. Still nothing. :-( To see the difference, do: 1c. Hit Alt-F2, _don't_ click "run in terminal", and run 'sleep 3; zenity --info --text test' 2., 3. as above 4. Enjoy the zenity window popping up on whatever the currenty active workspace happens to be! :-) Should I reopen this bug, or should I report it as a new one?
Thomas (comment 65): That is not strict-focus behaviour. Metacity does fix (change ;) more things that just this bug :) There have been huge discussions on whether a new window should popup on the original workspace or the current. Please open a new one.
[x] done, see http://bugzilla.gnome.org/show_bug.cgi?id=339149 Pointers to the huge discussions you mentioned would be appreciated. :-)
Just to add a few cents more to this discussion. I would suggest that the placement of and focus behaviour of new windows should be thought of as separate (but of course related) issues. Just because new windows should not always get focused (which I agree with - they shouldn't always get focused) doesn't mean they shouldn't appear on top (I think in general they should). I would like a 'strict-focus' but not if it means that new windows are placed somewhere below. There are many applications that open windows that the user wants to see, but should not get focus. Some examples are gnuplot, rasmol, mathematica (non-notebook interface). All of these are command-line applications that show graphical output in separate windows that in general should not get focus. Mplayer is another example of a command line app with output in a separate window that shouldn't necessarily get focused. Splash windows should also not get focused. Personally, I use mouse focus - I want the focus in the window that the pointer is in - always. New windows in my opinion should open so they are visible, but they should not steal focus - they should get it if the pointer is in them. I'm obviously not the with the majority with that opinion. These are issues that are really important - if things can't be made to work well for a given user, they'll have a lousy experience. I don't care much what is chosen as defaults, but I think this is an area that absolutely needs some configurable options. There are actually a bunch of people like me who grew up using unix and 'legacy' window managers where mouse focus was all there was and who can't imagine using anything else. There are also tons of people who've never seen mouse focus. I think both these types of people should be accomodated. I think the rules for whether or not new windows get focus have to depend on the focus mode. I know I'm oversimplifying here because there are all sorts of special cases, but: Could the options for click-to-focus mode be as simple as: - New windows appear: on top | on bottom - New windows: get focus | don't in Mouse (or sloppy) focus mode: - New windows appear: on top | on bottom - New windows: always steal focus | never get focus | get focus if the pointer is in them. perhaps additional selections for some those options need to be added to deal with some of the peculiar situations that arise - sort of a 'sane mode' type of option in which app- and situation-specific choices can be made. I think the idea of 'choosing good defaults' is very difficult to apply in this case, and really does require giving options because different people use the window manager in very different ways.
There's already a separate mechanism for windows which don't accept focus, but they're much rarer than you think. The mplayer window, for example, accepts users input, so it needs to be able to take focus.
Sure, mplayer can take input in its window, gnuplot windows can take user input too, but 85% of the time I don't want it focused - I have more commands I want to type and see the effects of. So a mechanism for windows that don't accept focus (eg splash screens?) is helpful but doesn't cover these cases.