LWN: Comments on "GNOME and the way forward"

GNOME and the way forward

renox — Fri, 02 Sep 2005 21:36:11 +0000

>The problem would be smaller if all apps had sub-second loadtimes but that's by far not the case.

Which is why I think that having 'transition-window' (note this isn't splash-screen which are totally other thing) would be great: each time you open an app, a window (quasi-empty at first, with just the tittle of the application and a progress bar for slow starting apps) should open: this would be very fast because the window is empty, then when the application is ready to be used, it replace the content of the window with the content and notice the user by changing the color of the application window and icon, for example.

Of course when the replacement occurs it should keep the shape defined by the user as you can iconify, resize the 'transition-window' even though the application is not ready to be used yet.

This should improve the life of users, but it can only works if the transition window can be raised very fast (but as it is mostly empty this shouldn't a problem, I think) and for application with a central unique window. For the gimp, it wouldn't work..

Focus stealing

newren — Tue, 30 Aug 2005 06:04:27 +0000

Sorry for the slow response...

> Actually, I see only one exception in Jon's response--an application
> grabbing the mouse.

The other was "If focus remains when the pointer goes onto the background, that's OK." There is always a window under the mouse, even if it's the background window (the thingy drawn by nautilus with the icons on it) or the root window when nothing like nautilus is running (the root window will be a concept most users are unaware of as it's kind of an x implementational detail though it is exposed to some extent in some environments so some users do know about it). Allowing a window to retain focus despite the mouse being over a different window, such as the nautilus background window or root window, is an exception to the "window under the pointer has the focus, always" rule. Some users may not realize that it's an exception, but that's kind of my point--there are likely other exceptions that the user doesn't know about or doesn't realize that they are exceptions. I want to know what the exceptions are and what aren't.

> But there is an alternative setting "Focus
> Under Mouse" which sounds like it does exactly what Jon is asking for.

It may be exactly what he's asking for, but that's what I'm trying to find out. Note that "Focus Under Mouse" in KWin destroys keynav (as claimed by KWin itself). That seems strange to me. It may actually be what users want, but I wanted to find out if perhaps something that doesn't focus new windows without destroying keynav might be more desirable. There's a number of other behaviors I need to get nailed down as well...

> * I also don't use the keyboard to move applications between workspaces.
> But if I did, and doing this puts the mouse over a different application,
> it sure seems like it *should* give that application the focus.

Yeah, that's the initial response of everyone that hasn't tried this (and it was the way I initially coded it too; I definitely was in the "everyone" group at one point). It seems to make sense. After all, if a user switches workspaces without moving a window with them we definitely want to focus the new window under the mouse. It isn't obvious without looking closer why things would be different when bringing a window with you while switching workspaces. So, let's look a little closer...

Let's say you were trying to move the original application, A, two workspaces to the right using keybindings. If the mouse is over the desktop instead of A, but A is still active (meaning that this can only happen with "sloppy" focus) then there's a special case: If another application, B, happens to be at the same coordinates where the mouse is in the intermediate workspace, and we focus B after the first workspace change like you suggest, that will make it impossible for the user to get application A where they want it without moving the mouse. But the thing is, users aren't aware of this. Instead, they just do this expecting things to work and then get really surprised when A moves only one workspace and B ("some random app") also moves one workspace...and it does take them a while to figure out what is really going on. Further, even if the user only moves one workspace over, they are moving A with them which means they almost certainly have an intent to continue interacting with that window (just as if the user alt-tabbed to it).

So focusing B really doesn't make sense (at least not for any use cases I've ever seen--maybe there are users out there, perhaps ones that don't mind keybindings being broken altogether, that would like this?). Anyway, ever since we switched from focusing the window B in this specific case, all the complaints about this issue stopped (which is surprising--virtually any change you make in a window manager, including "obvious" bugfixes, almost always results in bug reports with people requesting an option for the old behavior).

> But the above answers aside, I suspect that what Jon wants is simply to
> have new applications NOT automatically get focus, while leaving
> essentially everything else about window focus alone.

Good, I'm glad to hear that someone else is coming to the same conclusion. :-)

GNOME and the way forward

ekj — Sat, 27 Aug 2005 16:07:17 +0000

I don't want this. I have selected, in my preferences, how to give focus to a window, in my case "focus follows mouse". I selected that because that's what I want.

The fact that I (at some time in the past) typed "Alt+F2 gimp" is no indication at all that I want gimp focused whenever it gets done loading. When I want to use it, I'll select it. The problem would be smaller if all apps had sub-second loadtimes but that's by far not the case.

GNOME and the way forward

mightyduck — Fri, 26 Aug 2005 15:52:08 +0000

> Do you honestly believe the GTK developers are thinking "Boy, I'd love
> to implement X, Y, and Z, but because MS doesn't, I guess we can't"? Do
> they have a secret project with 300 options and a million revolution
> features they're keeping hidden from you? You're postulating a vast
> conspiracy by the GNOME developers to kill the Unix way, whatever that
> might mean to you. That's bullshit.

No it's not bullshit. Let's get a little reality check here. Gnome is
backed by big corporations like Sun, HP, IBM(?) and they give a sh*t
about old UNIX users. They're goal is to pry loose Windows users and
convert them to their systems. THAT'S why Gnome is more and more
following the WindBlows way of things.

The one who pays the musicians determines which music is to be played!

GNOME and the way forward

zdzichu — Thu, 25 Aug 2005 13:03:41 +0000

There is not need to put this preference in Evolution.
There is already Prefered Application submenu in preferences. Default editor could be put there.

GNOME and the way forward

k8to — Thu, 25 Aug 2005 09:16:26 +0000

I've been using email for decades now, and have been through a huge range of email programs: mailx, eudora, pine, elm, a variety of wonky BBS-based acess methods, whatever the mail was on our VMS systems, pegasus mail, yahoo mail, gmail, and I've pretty much always come back to elm, and more recently mutt. It's just better at getting the job done. Despite significant experience with all the others, I really quite like it.

And you know I'm editing this web form in gvim too. A feature the mozilla people have had requested since it started without ever being satisfied.

Thanks for calling me a nobody.

Focus stealing prevention

stuart — Thu, 25 Aug 2005 08:24:04 +0000

So perhaps a solution to the first problem is that you don't steal focus if an application does not have startup-notification.

GNOME and the way forward

utoddl — Mon, 22 Aug 2005 19:19:43 +0000

Lastly, making everything configurable-- even with hidden configuration options-- comes at a cost to the developers and can make the software unusable.

There was a passage in the Amiga User Interface Styleguide (or something like that -- it's been a while since I pulled it out) that gave what I thought was pretty good advice:

Don't create a user option just because you were unable to make a design decision.

(or something like that). Clearly some things need to be configurable by users, but not everything. And as you point out, some unanticipated configurations may prove unstable.

Focus stealing

EricBackus — Mon, 22 Aug 2005 05:03:48 +0000

newren wrote:
> Okay, you reiterated that you want the window under the pointer to
> always have focus. But then you went and stated two exceptions.

Actually, I see only one exception in Jon's response--an application
grabbing the mouse. And I think both he and you acknowledged that there's
nothing for the window manager to do in this case anyway.

I'm not a Gnome user, so maybe my opinions on this are not very important.
For what it's worth, I use KDE set to "Focus Follows Mouse", which DOES
give the focus to new windows. But there is an alternative setting "Focus
Under Mouse" which sounds like it does exactly what Jon is asking for.

In response to your questions, I can provide my own answers:

* The window list on the taskbar, like many things on the taskbar, is a
special case. I'd expect having the mouse over the taskbar to be much
like having the mouse over the background, so I don't see anything
contradictory about making a click on the window list switch window focus
just as though you briefly moved the mouse over the new application.

* Alt-tab or alt-esc could perhaps warp the pointer. If you don't warp
the pointer, perhaps you could merely top the selected application, but
leave focus wherever the mouse is. I don't use these so I don't really
have an opinion.

* I also don't use the keyboard to move applications between workspaces.
But if I did, and doing this puts the mouse over a different application,
it sure seems like it *should* give that application the focus.

But the above answers aside, I suspect that what Jon wants is simply to
have new applications NOT automatically get focus, while leaving
essentially everything else about window focus alone.

GNOME and the way forward

amikins — Sun, 21 Aug 2005 08:05:18 +0000

That's pretty much been my experience with Gnome since 2.0 started.
The simplest thing I miss dearly and am no longer sure how to accomplish in any window manager is a floating toolbar at the very top of the screen not aligned with the center or right edge that does not displace windows (i.e. cut into screen real estate).
I preferred to place my clock and a few other system monitoring tools in a spot where they would overlap with the titlebar of a maximized application, and they quite happily fit there without interfering with anything else.
Early on in the gnome 2 cycle this started becoming an obscure option that had to be enabled to keep the 'smart' behavior from fighting me.
Later on, the option disappeared from easy location; it wasn't until well after I threw my hands up at Gnome in general (for other reasons as well) that I learned that the 'power' configuration was hidden away in a place that was totally unobvious.
The last time I used Gnome (Which was admittedly about a year ago) I couldn't figure out how to regain that behavior.. The changlog insisted no behavior was lost, and my attempt to clarify my problem to a developer at that point in time (I can't recall to whom I was speaking) basically gave the impression that there was nothing lost, and if there was, I wasn't doing anything worthwhile anyway.

I'm also curious.. Did Metacity ever develop the 'viewport' functionality that Sawfish/Sawmill had? I personally find the 'multiple desktops' functionality counter-intuitive, and miss the ability to slide a viewport around a larger effective desktop.

GNOME and the way forward

dskoll — Sat, 20 Aug 2005 03:24:13 +0000

Here is a fact you people might want to consider: Nobody actually *likes* the unix mail programs with their external editors. Their combined market share is perhaps 2%.

If you are talking about market share of all e-mail programs, you're probably right.

If you are talking about market share of all e-mail programs that run on UNIX, you are completely wrong. Evolution is the only UNIX-based e-mail program I can think of that does not support an external editor, and I'd be amazed if it has more than 25% market share among UNIX e-mail programs.

GNOME and the way forward

sandmann — Sat, 20 Aug 2005 00:52:56 +0000

Here is a fact you people might want to consider: Nobody actually *likes* the unix mail programs with their external editors. Their combined market share is perhaps 2%.

If you try to say that those 98% of all people just need to get used to the unix way and put up with meaningless preferences like "path to external editor", then you need to reconsider who the arrogant twit is ...

GNOME and the way forward

dvdeug — Fri, 19 Aug 2005 07:44:22 +0000

Any desktop environment is not about choice.. it is about usability for a new user.

Most people don't switch desktops frequently. So why design a desktop environment for the few that are switching? That's like making all your keyboards in alphabetical order; sure, it's lousy for typing, and it screws everyone who's already typed a lot, but it's great for the new user.

GNOME and the way forward

njhurst — Fri, 19 Aug 2005 05:56:34 +0000

For another example of the Gnome attitude towards users and UI patches have a look at this bug: 115763

It seems that although nobody can come up with a good reason why the dialog can't provide eject as an option, the nautilus developer has dug in defending the current laughable dialog interaction. The bug has been open 2 years guys!

Fork GNOME?

njhurst — Fri, 19 Aug 2005 05:26:54 +0000

But it was a very nice logo, wasn't it?

Focus stealing

pimlott — Fri, 19 Aug 2005 04:39:33 +0000

>/me goes and bashes his head into the wall as penance

Now, no need to hurt the wall. :-)
Thanks for thinking about what I said, whether it was right or not.
FWIW, I use FVWM, and my alt-tab handler focuses, raises, and warps the pointer to the selected window. Although several other aspects of the alt-tab behavior are sub-optimal, warping the pointer seems to work out fine.

GNOME and the way forward

dskoll — Fri, 19 Aug 2005 02:17:17 +0000

> Do you honestly believe the GTK developers are thinking "Boy, I'd love to implement X, Y, and Z, but because MS doesn't, I guess we can't"?

No.

I honestly believe the Gnome developers believe they can get Windows users to use Gnome if Gnome becomes sufficiently similar to Windows. How else can you explain abominations like GConf, or the one-and-only UNIX MUA that lacks external editor support?

There's no good reason for a lot of the decisions they've made, other than to davka[*] reject the UNIX way.

[*] This Hebrew word is practically untranslatable, but the essence means to do something simply to be obstinate.

GNOME and the way forward

dskoll — Fri, 19 Aug 2005 02:00:34 +0000

> An initial patch is very much not "all the work for you.

The Gnome-vim guy is maintaining his patch, and even maintaining a patched version of Evo on his download site. If he can do it, so can the Evo developers, so that they can cease to be the *ONE AND ONLY* UNIX mail client that lacks external editor support.

> I can easily imagine the poor maintainer having to work around some complicated external editor mess

Software that makes invoking an external editor a "mess" is badly designed.

> As it happens I've already written this argument down too: http://ometer.com/features.html

But IMO, the GNOME developers ignore an important point you make in that article:

"In the presence of good rationale, maintainers should be willing to change their mind often."

OK. Let me follow your article about just this one feature (external editor support where possible.) You want a rationale that:

"Does not apply to all possible features."

OK.

"Contains facts or empirical data rather than speculation."

Every other significant UNIX MUA supports this feature. 80% of the developers I have ever worked with have used this feature.

"Demonstrates that you've done your homework on alternative solutions to the same problem."

The alternative would be to rewrite users' favourite editors within GNOME.

"Demonstrates that you know what the root problem actually is; what motivates the feature? How else could it be approached?"

The root problem is that many people are most efficient editing text in their favourite text editor.

"Demonstrates that you're thinking of all users in the big picture, instead of just yourself and people like you."

All users who like their favourite text editor will benefit. Those who don't care won't be hurt.

"Improves things for a large percentage (50%?) of users, or makes the impossible possible for a smaller percentage (5%?). "Easy things easy, hard things possible.""

I believe this feature request covers the 5%.

"Shows that the feature is genuinely important enough to be worth maintaining some extra code."

One developer is already maintaining the extra code in his own free time.

Happy?

> In the end I think most people who flame passionately about a small feature [...]

I'm not just flaming about one small feature (although it is highly irritating). It's the *combination* of small misfeatures, bad design decisions, and (mostly) incredibly haughty attitude of the developers that has soured me on GNOME. I have to agree with some of the other posters here; the 1.4->2.0 transition really marked a significant decline in GNOME's usability and quality.

GNOME and the way forward

hp — Fri, 19 Aug 2005 01:58:45 +0000

The way you change window managers is:

fvwm2 -replace
gnome-session-save

Replace "fvwm2 -replace" with the equivalent for your WM of choice.

You can also just run any WM in .Xclients prior to launching Metacity (or other WM), and the second-launched WM should silently exit and leave the first one in charge. Basically WMs have a protocol to see if another one is running and to replace another one only if requested.

The way you posted is a gross hack to work around a version of Sawfish without a -replace mode, but most WMs have -replace (and if they don't, that's where the bug lies).

GNOME and the way forward

hp — Fri, 19 Aug 2005 01:49:00 +0000

An initial patch is very much not "all the work for you." Any practicing software developer can tell you that at least 80% of the work is maintenance, not the patch. I don't know a thing about Evo external composer and haven't read the bug, but I can easily imagine the poor maintainer having to work around some complicated external editor mess when implementing features, and having to endure endless bug reports about how external Emacs doesn't quite work in various ways, or vim changed how it works and Evo needs adapting, and so forth.
It could easily be a major time sink.

As it happens I've already written this argument down too: http://ometer.com/features.html

On the "it would be easy if it weren't badly designed" comment, I don't know where you get Magic Programming Silver Bullet(tm) with no tradeoffs or costs, but if you have it by all means come design things for us!

In the end I think most people who flame passionately about a small feature miss the simple point that there are hundreds of people flaming passionately about hundreds of small features. The maintainer is seeing the hundreds, and you are seeing the one.

Maintainers need some way to prioritize that.

GNOME and the way forward

njhurst — Thu, 18 Aug 2005 23:51:26 +0000

Indeed, after working my way through all the gui mail clients out there I returned to Pine, which has by far the best user interface. For a start you can get going knowing nothing about mail systems. It can use an external editor, and it takes minimal system resources.

(I'd use mutt more, but the interface on mutt is far less 'friendly')

I wonder when gui mail apps will approach the simplicity and ease of use of pine.

Focus stealing

zblaxell — Thu, 18 Aug 2005 23:29:19 +0000

From the few things I had read on the matter, though, it doesn't look like toolkit authors are willing to make such a change--perhaps it causes lots of race conditions or other problems? (Man, I'm exposing my ignorance here...)

There are one or two differences, especially in the select-no-entry case. With a grab you can have the user click on some non-menu surface, and keyboard accelerators can be used no matter where the mouse is. I'd imagine some users believe that they'd have to click off-menu to abort a menu selection (I once believed that, and it might be true for some applications with a do-it-yourself toolkit) as opposed to pressing Escape, or clicking on-menu and dragging off. Also, arrowing your way through the menu instead of using the mouse works only if the application that posted the menu already has keyboard focus for other reasons. Some menus in some toolkits will close if focus goes to another application while the menu is active. However, despite all the small changes, no menu that I've ever seen becomes unusable--all possible options, including "none of the above" can be selected with both keyboard and mouse.

I wouldn't be surprised if there weren't a lot of applications out there that are built assuming the GUI toolkit is incapable of receiving input from other widgets while a menu is active. That would probably break a few programs, but none of the ones I've tried.

Focus stealing

newren — Thu, 18 Aug 2005 23:18:53 +0000

FWIW, what I want is this: the window under the pointer has the focus, always. If focus remains when the pointer goes onto the background, that's OK. If some rude application grabs it, there's little to be done - but that should not happen for much of anything beyond things like pulldown menus.

Okay, you reiterated that you want the window under the pointer to always have focus. But then you went and stated two exceptions. So you don't really mean for the rule to apply rigidly--but in what other cases should it not apply, if any? Here's some questions: If the user clicks on an item in the window list on the taskbar, should it be a no-op (sounds like that makes the window list applet useless--should the WM to disallow the existence of window list and window selector applets for your preferred focus mode? or is it okay to break the window-under-the-mouse-has-focus constraints here too?) What if the user tries to use alt-tab or alt-esc to switch which application has focus (no-op and break keyboard navigation? suspend mouse navigation rules temporarily since the user isn't using the mouse to navigate? warp the pointer?) What if the mouse pointer is over the background, the focus is on app A, and the user wants to use the keyboard to move app A from its current workspace and place it two workspaces to the right -- but app B has a window right where the mouse is in the intermediate workspace? In this case, if you focus app B after the first workspace switch (because it is under the mouse after all), then the user will be surprised if they rapidly hit the keybinding twice--they will have expected app A to move two workspaces but instead it only moved one while app B also moved one (yes, this was a real bug report--I'm not making it up). Is it okay to ignore the window-under-the-mouse-has-focus case here too? What about windows that don't take input focus?

I think that what you want is sloppy focus with its invariant (focus should be on the window under the mouse if there is one, otherwise focus should be on the most recently used window) held to be more important than focusing new windows with everything else kept the same, i.e. a don't-focus-new-windows-option. We explicitly decided to break the invariant in the new window case merely because the majority of users are surprised if new windows don't get focus (see our how to get focus right document and search for "strict"), but I believe we could add an option for not breaking the invariant in this case. I'm guessing that's what you want...am I right?

In another posting you said, I believe, that the above was not possible with X. But it used to work that way.

Look a little closer. Try this: bring up the menu in one of your apps, but don't click any of the items. Move your mouse to a different window altogether. Note that the application with the menu open still has focus and the menu is still up, and the window you moved the mouse into doesn't have focus. The application with the open menu has a mouse grab so that the WM doesn't know about the mouse entering the new window and is powerless to enforce the constraint you requested. (Note: there are some apps for which this little exercise won't work as they don't actually do a mouse grab, but most all apps do)

Also, try this: Open up a nautilus window. Pick an item and start dragging it elsewhere, including over other windows as though you were going to drop it on one of them. Notice that none of the windows get focused or raised when you move over them. We would really like to focus and/or raise those other windows when the user drags items over them to help them drop it in the right location (especially since it may be obscured), but we can't because the app where the DnD started has a mouse grab (although maybe if gtk+ sent the client messages for XDND with a nonzero event mask then maybe we could workaround this? I need to get an answer from Owen on that...)

I don't believe that either of those cases worked any differently in past with an X window manager (though there are efforts at fixing the latter via alternative methods and I believe I heard that KWin might have that up and running for QT apps at least...). Yes, we could get closer to having window-under-mouse-has-focus, but we can't make it 100%--and there are many ways in which it's not 100% where even most users of focus follows mouse probably don't want things changed. (And yes, I'll grant that the new window thing apparently is an example of where there's a large number of focus follows mouse users who do want a change to bring it closer to 100%, and that specific case is listed in the how-to-get-focus-right document I referenced above, but I'm not at all convinced that changes are wanted/needed for the other cases--at least, not yet).

GNOME and the way forward

zblaxell — Thu, 18 Aug 2005 23:03:10 +0000

Now, some people have requested a window-is-focused-iff-pointer-is-in-it (which destroys/prevents keyboard navigation

I've used window-is-focused-iff-pointer-is-in-it and keyboard navigation simultaneously since 14 years ago, starting with twm. I've used a few WM's since then, but I don't use window managers that can't do both. The trick is to move the mouse cursor and change the window stacking order when focus changes. Sawfish does the stacking order right--each candidate window is raised, but goes back to its former place in the stacking order if it was not ultimately selected, so keyboard navigation doesn't break the highly organized piles of windows that I build up.

focus-the-new-window-only-if-it-happens-to-appear-where-the-mouse-pointer-is. I don't quite understand why people would want this or if people really do; I'm of the opinion that those who wanted this were probably just really annoyed by all the dozens and dozens of bugs that used to exist...am I mistaken?

You are mistaken. I really want this, and more.

Most of the bugs you refer to arise in the first place when people try to do something complicated with lots of inputs and heuristics, and in my experience the best possible outcome of "intelligent" focus management is something that behaves inconsistently in some cases, provides no benefit over pure focus-strictly-under-mouse, but has failure modes that are only relatively obscure or harmless. Most people who even try do much worse. The annoying thing to me is that so many people seem to consider this to be some kind of problem to solve, when it's not. Just put the focus where the mouse is. Done.

I attest that I've tried both focus-under-mouse and focus-strictly-under-mouse modes or their equivalents on at least half a dozen window managers, and I can tell the difference in practice, and much prefer focus-strictly-under-mouse, and use support or lack thereof for this mode as a discriminating factor when choosing a new window manager. You'd sooner convert an nvi user to vim. ;-)

Where the mouse pointer is, so shall the focus be; conversely, where I want the focus to be, I must move the mouse pointer to. Put another way, all of the right, and all of the responsibility, to decide where input goes, is in my mouse hand. Doing it any other way generally feels like a 2-year-old has plugged a mouse into the USB port on the back of the machine and is now teething on it. If I have to use a desktop configured for "raise on click" combined with "click to focus," I generally refrain from using multiple windows at all, since I can't always organize them as I would like with those management primitives. At the opposite extreme is "autoraise", which I can't use at all.

I have access to information that the window manager could not possibly have. I know in advance where an application is going to appear in a few seconds from now, since I launched it--possibly from a different machine--and I know it's preconfigured to appear there, and I also know if I'm launching a single application or the first of six.

Sometimes (especially on laptops) my mouse cursor strays into "inter-window space", and it's better for input to fail immediately (and preferably noisily), than to continue to work until the cursor strays a little further into "incorrect-window space," where it can do serious damage (imagine typing this sentence into vi...now imagine typing it into a live database application where most changes are immediate, globally distributed, and permanent). This is why sloppy focus is not sufficient--the slop generally manifests itself in apparently random applications getting focus when the mouse cursor is on the root window.

New windows that pop up under where the mouse cursor happens to be are a problem; however, the usual "focus stealing" algorithm is a complex, inelegant, race-prone non-solution. A better idea is something like ratpoison's "rudeness" bits, which apply a filter on which windows can display themselves or raise themselves in the stacking order. Generally if I want to prevent windows from opening at all, it's because I'm doing a specific task that I don't want interrupted, so it would be enough to have a WM command for "allow no windows to be raised until further notice."

With xterm I can lock the keyboard focus on the current application until a magic event is triggered to release the focus lock (the "secure keyboard" mode). It is possible to interact with, even click on other applications in this mode, but keyboard input is unconditionally directed to the xterm. This is really handy and I use it quite often, especially with applications like wish or mplayer which simultaneously use TTY and X11 interfaces. It would be nice if the WM could do this consistently across most applications, so that every application doesn't need to implement the feature. Nothing other than the specific "release focus" command would release the focus from that window once it was locked--not even if the locked window goes away.

The opposite (windows that can't get focus until a specific keybinding or window menu entry is fired) could be useful too: I've often had an xchat window get the focus unexpectedly (e.g. the mouse drifted, or the window obscuring xchat disappeared and the mouse ended up in xchat) and wished that it hadn't received the last few lines of typing. I would be willing--in fact, I'd prefer--to invoke a window manager command each and every time I wanted to enable input on xchat after switching from another window.

GNOME and the way forward

kleptog — Thu, 18 Aug 2005 22:29:35 +0000

Thanks for your responses, it's been nice to have someone who's at least attempting to understand the problem looking at this.

Also, you seem to have ignored placement.

Placement is simple. If there's room on the current desktop, place it there, if there isn't it puts an outline of the window on the screen and I place it with the mouse. Since I arrange for the desktop to be free whenever I start an app the placement is never that hard. I know exactly how long Galeon takes to startup and can jump to the desktop at the right time.

This is only for top-level windows, for subwindows they just popup and like you say, they get focus if and only if I have the mouse there. If it's one of those dialogs that keeps popping up and I need to press no, I can place my mouse at the right place to meet it. If I don't care I'll keep typing in the window behind it and deal with the box when I want to. I don't know how FVWM does it, but it does work well. This does mean that subwindows, whenever possible, should popup in the same place, irrespective of where the mouse is.

What about apps that try to transfer focus from one of their already onscreen windows to another already onscreen window [...] --should such requests just be summarily denied because the user hasn't moved the mouse?

In short, yes. I control the focus, not the application. The app may ofcourse respectfully request the focus be moved and it can just as respectfully be ignored.

As to your questions about the task-bar and alt-tab, I checked and it warps the mouse to the desktop and location so as to make the app have focus. But I never use those things. Like I said I have a 4x4 virtual desktop and my browser / mail client / etc have fixed desktops so with the keyboard I can just jump straight to the app I want. Alt-tab and task-bars tend to get the apps in a random order (that keeps changing) so I can't use them to get to an app in a deterministic way. One app per desktop remember...

The input focus stealing, yes, I've seen that with Netscape 4.x if an app opened just as you were browsing the menu. Nasty stuff. As someone pointed out, why do menus need to steal focus when they don't actually need to. Everything works fine without. I worked out ways to break that focus. If an app I used did that a lot I wouldn't use it...

Anyway, I'm one of those people who dislikes taskbars and desktop icons and I'll probably keep using FVWM no matter how good you make GNOME. I think overall you're doing a good job, I just hope that if I'm ever required to use GNOME somewhere, I'll be able to set it up with strict mouse focus.

Have a nice day,

Focus stealing

newren — Thu, 18 Aug 2005 22:24:34 +0000

Lots of interesting info in your post. Thanks! Some comments:

The applications don't seem to mind, and I didn't have to rewrite them, I just dishonor their input grab requests from the X server. In fact, I often wonder why it ever seemed necessary to grab the mouse or keyboard focus for these operations in the first place, since the menus work just fine without it, and modifying any particular application or toolkit to work that way is trivial. There are really good reasons to not grab the mouse and keyboard--especially if the application is prone to locking up while it has a menu posted.

Really? I had assumed (never actually checked) that it'd be a lot of hard work to modify toolkits to work without mouse and keyboard grabs. From the few things I had read on the matter, though, it doesn't look like toolkit authors are willing to make such a change--perhaps it causes lots of race conditions or other problems? (Man, I'm exposing my ignorance here...)

although if it was technically feasible, I'd try to get the new window to be immediately below the window with the mouse cursor, and first in the Alt-Tab list. Forcing all new windows to be minimized would work too, although I wouldn't be surprised if there was at least one application that would just try to un-minimize itself.

It's not very hard at all to place windows below the focused one and first in the alt-tab list. Also, the WM gets MapRequest events whenever an application tries to map a window (unless it's an override redirect window) and can just deny or delay the request so it could keep apps from un-minimizing themselves for the most part.

as you alt-tab through the windows, it pops up each window to the top--and if you keep going, it pops the window back to its original place in the stacking order.

Try using Alt-Esc in metacity. Other WMs may have something like that too with an alternate keybinding.

There is always a window under the mouse. As far as I know the mouse can't be anywhere except above the root window, and one can't delete the root window.

Yes, I unfortunately used "window" as the user thinks of them instead of as the real X objects. Note that mose focus-follows-mouse users prefer a sloppy style meaning that windows are focused when the mouse enters them but they are not defocused on exit--and users don't consider the root window and other special windows (e.g. the taskbar) to count when the mouse enters them. Saying always keep the focus under the mouse is nice and all but this is just an example of how most people don't really mean that.

Which are those? I've seen some applications (mostly Xaw) that can't get focus with some window managers even when they want it and can get it under twm...I had assumed that was a window manager bug.

See section 4.1.7 of the ICCCM (e.g. at http://tronche.com/gui/x/icccm/sec-4.html). Basically, it's a violation of the ICCCM for the window manager to try to set focus to a window with the input field set to false.

Focus stealing

corbet — Thu, 18 Aug 2005 21:32:18 +0000

No offense taken.

FWIW, what I want is this: the window under the pointer has the focus, always. If focus remains when the pointer goes onto the background, that's OK. If some rude application grabs it, there's little to be done - but that should not happen for much of anything beyond things like pulldown menus. If a window pops up under the pointer, let it have the focus (in this case, there is a lot to be said for predictability of window placement, which metacity pretty much has).

In another posting you said, I believe, that the above was not possible with X. But it used to work that way. It's only with GNOME 2 that I started running into weird focus stuff.

Honestly, to me, the "focus stealing prevention" stuff which tries to figure out if you are actively engaged with another application or not looks like an ugly hack. Something like that will always be problematic to get right. It's a highly modal, timing-dependent interface which seems guaranteed to surprise people. My own experience says that, when you start looking at that sort of approach, you've missed a turn somewhere. In focus-follows-pointer mode, at least, why not just leave the focus under the pointer? It must be possible; the bare X server works that way by default...

GNOME and the way forward

evgeny — Thu, 18 Aug 2005 21:30:24 +0000

> I think the FVWM project could really do themselves a favor by using a default configuration that is more along the lines of what most people expect. The default configuration (last time I tried it) is bizarre.

I used to think this way, too. But then - it's a recurring theme in plenty of fairy tales: you know, one must have a courage to kiss a frog; and be rewarded with a lovely princess to the end of his days. On the other hand, the girls that promise you everything are found in ..., well, let's stop the analogy here.

PS. I might be just lucky to learn about fvwm at the time when it looked, by comparison with other contemporary WMs, THE princess even with the default config (which hardly changed since then).

Focus stealing

zblaxell — Thu, 18 Aug 2005 21:27:13 +0000

While you raise some valid points, I think some of the problems you mentioned have already been solved by non-GNOME projects.

a) Applications can grab the mouse so that the WM isn't notified of mouse entry/exit from windows. Open up a menu in some app, move the mouse to another app--note that the window with the menu open still has the focus. Fixing would require re-writing all applications.

I routinely hit Ctrl-Alt-Divide on the keypad to break these, e.g. when I've popped up 2 levels of menu, then realized I have to go visit some other application to get information required to make a decision. It's usually worth the finger gymnastics on the keyboard to avoid having to describe the curvy path to the Nth level deep menu with a touchpad twice.

The applications don't seem to mind, and I didn't have to rewrite them, I just dishonor their input grab requests from the X server. In fact, I often wonder why it ever seemed necessary to grab the mouse or keyboard focus for these operations in the first place, since the menus work just fine without it, and modifying any particular application or toolkit to work that way is trivial. There are really good reasons to not grab the mouse and keyboard--especially if the application is prone to locking up while it has a menu posted.

b) Imagine this: User starts an application, while waiting they go to interact with some other app and clicks around on it, the launched application window happens to appear and covers the window(s) the user was working with (or do you expect new windows to be placed at the very bottom of the stack of windows?), and then the user clicks before they realize that a new window has appeared and thus initiates some action they didn't want.

Ratpoison has permission bits on raise and display requests that users can grant or revoke at will, with different policies for transients and non-transients. Control over these bits is considered a normal window management operation: users can have key bindings to switch windows, resize windows, and set "rudeness" bits as they like--it's not buried under four levels of user menus and dialogs, it's something that might change as the user switches from one application to another, depending on the user's current task. The feature is also exactly where it belongs--in the window manager, not the application. The effect is nice--no matter how obnoxious your mail client or web browser is, it can't interrupt your work by popping up a window on top of what you're doing, until you explicitly permit it.

In the GNOME or KDE context, there could be a little button in the taskbar, like the keyboard language indicator, which a user can click on when they don't want to be bothered by new windows for a while. It might even be reasonable to provide a mode where new windows appear on the bottom of the stack instead of the top, although if it was technically feasible, I'd try to get the new window to be immediately below the window with the mouse cursor, and first in the Alt-Tab list. Forcing all new windows to be minimized would work too, although I wouldn't be surprised if there was at least one application that would just try to un-minimize itself.

c) Your suggestion breaks the taskbar ("window list applet"), the window selector applet, alt-tab, and all applications that try to transfer focus from one of their windows to another. Effectively, it's impossible to do keyboard navigation.

twm never seemed to have a problem with this. twm did have rules about warping the mouse cursor--if you used keynav to select windows in twm, the mouse cursor moves at the same time. That was annoying, but from a user's point of view, it didn't break the "focus strictly under the mouse" rule, and I'll take annoyingly consistent over consistently annoying any day.

Another quirk is that pointing at the "icon list" in twm (the closest thing to a taskbar) put the keyboard focus on the corresponding application window. I could hit Ctrl-Q repeatedly while panning over the task list with the mouse to get rid of a lot of windows of some application or other. Unlike the usual "Close all" popup menu, I could send any keyboard command to the applications.

Digression: I wish more window managers would implement alt-Tab the way sawfish used to: as you alt-tab through the windows, it pops up each window to the top--and if you keep going, it pops the window back to its original place in the stacking order. This is really handy if there are 20 or so windows on the desktop and I want to pick out three of them in no particular order. I tend to leave a lot of windows lying around with just what I want to see exposed on each, so it's a fairly large investment of my time to fix things if the stacking order gets changed in indiscriminate ways. Sawfish is a little broken now--it moves application focus but no longer moves the mouse cursor, which can result in the mouse cursor on one window but the focus on another.

(d) there's not always a window under the mouse

There is always a window under the mouse. As far as I know the mouse can't be anywhere except above the root window, and one can't delete the root window.

(e) some windows shouldn't get focus ever even if the mouse is over them

Which are those? I've seen some applications (mostly Xaw) that can't get focus with some window managers even when they want it and can get it under twm...I had assumed that was a window manager bug.

f) I understand that among those that use terminals heavily, there are many that like to launch applications in the background and continue working. But most users launch an application and then want to use it; defaulting to not focusing new windows just doesn't make sense.

It's not unusual for me to launch applications two or three at a time, especially if I need to have two or three of them working together on a project. I also have applications that have extremely long startup times (e.g. Galeon after a crash may take up to 10 minutes to become fully usable).

I sometimes do corbet's xv and ^C trick. Sometimes it doesn't work, e.g. when the xv window fills the whole screen and focus goes where the mouse is--on xv. There's an xterm trick which is to put the xterm in "secure keyboard" mode, which is essentially just a permanent input grab. Unlike the way that input grab usually used by menus, an input grab on xterm is actually useful, and AFAICT it's a feature missing from gnome-terminal and konsole.

Ideally the window manager could do this consistently across all applications--e.g. the window menu might have options that mean "lock keyboard input focus on this window until further notice" with options "even if I manipulate other windows or new windows appear" and "even if the window closes, no other application gets focus until I explicitly allow automatic focus selection again."

Focus stealing

newren — Thu, 18 Aug 2005 21:13:39 +0000

Oh, crap. I didn't even realize I was coming across that way. Sorry about that, Jon. /me goes and bashes his head into the wall as penance

For what it's worth, I really did mean to come across as "the request as you've written probably isn't what you mean--could you clarify?" with a really verbose explanation of why I think he might mean something different. (I think he was getting at the fact that he didn't like the default of focusing new windows in the cases where there is no user interaction between launch and appearance of the window or when we don't know enough about when various user interactions occurred, but what he suggested encompassed way more--and I don't know if the extra stuff was intended or not. After working on a WM long enough you find that people request all kinds of variations of things and I really don't know what's being requested without getting more detail)

Other comments in this thread are similar; I think most all of them are getting at that specific default, but actually use examples that are tangentially related and/or include lots of other stuff that may or may not be intended. I really am trying to understand what the real issue is.

Again, sorry for coming across that way.

GNOME and the way forward

newren — Thu, 18 Aug 2005 20:51:16 +0000

I assume you're joking, but humor often doesn't translate well into text.

Actually, no I wasn't. You'd be really surprised what you hear people request when you work on developing a window manager. I really was just trying to get you to clarify. (thanks for doing so).

Focus stealing

newren — Thu, 18 Aug 2005 20:46:29 +0000

It'd be awesome if there was a way to determine where, how, and when an application was launched without something like needing to be launched with startup-notification. But there isn't (okay, 'when' is sort of available if the WM is running on the same machine as the app and uses system calls to determine when the OS started it, but even this time isn't what you really want--you want to know when the user clicked the mouse or pressed enter in order to cause the app to launch which occurred sometime before that; further for apps like firefox/mozilla/nautilus/epiphany/gnome-terminal/gedit/konqueror etc. that forward new window requests to other instances, only the old instance that forwards the request has the appropriate information and if it doesn't get forwarded then you're stuck and have to take wild guesses). Having an app try to determine if it was launched from a terminal somewhere just isn't possible. Anyway, it's just another part of why apps really need to be launched with startup-notification for this freedesktop.org focus-stealing-prevention stuff to work.

GNOME and the way forward

piman — Thu, 18 Aug 2005 20:30:37 +0000

No, nevermind my other post, I want to take more issue with this nonsense:

> [It] merely saddens me to see that the ubiquity of Microsoft has forced even free-software UI developers to bend over backwards to accomodate Microsoft's stale and irritating UI concepts.

Do you honestly believe the GTK developers are thinking "Boy, I'd love to implement X, Y, and Z, but because MS doesn't, I guess we can't"? Do they have a secret project with 300 options and a million revolution features they're keeping hidden from you? You're postulating a vast conspiracy by the GNOME developers to kill the Unix way, whatever that might mean to you. That's bullshit.

They write software they want; I write software I want; you can write software you want. When the kind of software we want converges, we can share it. That, and nothing more, is free software.

Focus stealing

pimlott — Thu, 18 Aug 2005 20:27:03 +0000

> I hope I'm not part of the problem

Please take this message in good faith.

Consider your long reply to Jon ("Maybe because ..."). The tone of that message, as I read it, is, "let me tell you all the reasons that what you want is wrong (and PS you don't really understand what you're asking for)". Why not instead start from the premise that Jon is an intelligent, experienced, and thoughtful user, and therefore that what he wants is reasonable and valuable? Think, "satisfying Jon's request might make GNOME a better desktop", or even "making Jon a happy user could earn some serious karma".

I'm not suggesting you would ever intentionally belittle Jon. But I think many GNOME (and Mozilla) developers tend to read user complaints with a mindset of "correct him" rather than "learn from him".

GNOME and the way forward

piman — Thu, 18 Aug 2005 20:15:59 +0000

> No, it merely saddens me to see that the ubiquity of Microsoft has forced even free-software UI developers to bend over backwards to accomodate Microsoft's stale and irritating UI concepts.

I hear this but I don't believe it; if it was true, I'd find Windows a lot easier to use after using GNOME for the past few years. It definitely borrows more from OS X than Windows, and more from ICCCM/X history than OS X.

> But if they ignore feature requests that are easy to implement (heck, if they ignore patches implementing such features)

100 easy features makes for a complicated program; no patch is without maintenance costs.

> [They're] no better than proprietary vendors who ignore customer requests.

Any software project -- free software or proprietary -- that routinely ignores significant portions of its user group will fail, or a new project to support that group pops up. That's almost tautological, since if the feature doesn't appear, it wasn't that significant in the first place.

> Free Software is about a social contract

The GPL and BSD license, as well as the FSD, OSD, and DFSG, make no promises or even expectations that the application will do exactly what you want. In fact the disclaimer of warranty explicitly says otherwise.

Put your code where your mouth is. Dozens if not hundreds of people continue to do it every day -- which is why software like Window Maker, AfterStep, FVWM, and XFce survive, and projects like GoneME fail.

GNOME and the way forward

jeskritt — Thu, 18 Aug 2005 20:10:20 +0000

I'm running FC4 and don't have this problem with my gnome desktop. Maybe there is an option you need to set?

GNOME and the way forward

loening — Thu, 18 Aug 2005 19:59:20 +0000

I assume you're joking, but humor often doesn't translate well into text.

So just so we're clear. New windows should not take focus if another window has the focus, unless the new window has to pop up over the current window because there's no other spot for it to pop up.

Actual, after reading some of the new posts, an even better policy might be this: New window should not take focus if another window has the focus, and a new window should not pop-up over a window that has the focus. If the new window has to use screen real-estate that the focused window has, it should pop-under the focused window.

Focus stealing

smoogen — Thu, 18 Aug 2005 19:37:51 +0000

Maybe GNOME applications should either be wrapped or self test if they are run from the command line or not. If they are then they could set the desktop notification flag themselves?

GNOME and the way forward

dskoll — Thu, 18 Aug 2005 19:36:28 +0000

Still, you have to admire how faithfully they've re-invented the Windows registry.

GNOME and the way forward

bronson — Thu, 18 Aug 2005 19:28:32 +0000

And *this* is why noboy uses GConf. :)