LWN.net News from the source
Certainly, the GNOME desktop offers enough annoyances to make just about any user grumpy. Your editor is burned daily by the metacity "a new window gets the keyboard focus regardless of the pointer position" policy; having the focus yanked away in the middle of a sentence does not seem like the most user-friendly policy. Why can't gthumb's forms do the right thing when the user hits "enter," rather than forcing another trip back to the mouse? Where, exactly, is the little option to get emacs key bindings? Clicking on a window does not mean the window should be raised; there is a separate combination for that. The new, "electron cloud" busy-cursor behavior in the Rawhide version of GNOME 2.12 is distracting and annoying, requiring a trip to an external site for a new cursor theme. Dia's aggressive use of "tool tips" makes a nice drawing application almost unusable. Why is there no easy way to move settings from one system to another? And so on.
Annoyances are part of using a computer, however. It is hard to imagine that a desktop as complex and featureful as GNOME would be free of glitches. These things can be smoothed out over time to make room for new bits of obnoxious behavior. The GNOME debate goes beyond the current set of misfeatures, however, and into a couple of fundamental issues which are worth a look.
One of these is: to what extent is GNOME a "Unix" desktop, and to what extent should it preserve the traditional Unix way of doing things, whatever that might be? At the 2000 Ottawa Linux Symposium, Miguel de Icaza delivered his famous "Unix sucks" talk. Unix, he said, had gone stale and had not been the source of any significant innovation for quite some time. The GNOME project intended to move beyond hidebound Unix ways and deliver something new. Miguel's vision, which seemed to involve switching over to hidebound Microsoft ways, does not appear to be driving the GNOME project at this time, but the project does appear willing to break from the past - even its own past - if that offers hope of a better desktop.
And that is how it should be. The Unix way of doing things worked well in a different era, when users were clueful, systems were small (in capability, if not in actual size), and an ADM 3 terminal in one's office seemed like a major step up. How do many of the fundamental Unix ideas - writing programs as small, text-oriented filters, for example - fit into the creation of a modern, graphical desktop? Clearly, developers wishing to pull Linux forward into a larger world with a broader user community have to be willing to do some things differently. One may not agree with everything that the GNOME project has done, but the GNOME hackers are (like their counterparts at KDE and elsewhere) trying to change the world for the better.
It would be surprising indeed if there were a consensus on what "better" is, especially before it has been implemented and pounded on. The GNOME idea of "better" may or may not win out in the end, but, because the developers are working at it, we will have the opportunity find out. And that is a good thing.
The other issue which comes up with some regularity is a perceived arrogance from some in the GNOME camp. Experimentation with the desktop will go best when accompanied by careful attention to the resulting cries of agony from the user community. Users have often been heard to complain, however, that the GNOME hackers Know Too Much to listen to those cries as they follow the One True Course. A tendency by some developers to describe user requests as "crack" probably has not helped in this regard. Recent posters have complained about the refusal by the Evolution maintainers to accept a patch enabling the use of external editors.
There is a hard line to follow here; the maintainer of any successful free software project must learn to say "no" to features and requests much of the time, or that project will likely collapse under its own weight. Say "no" too often, however, and both users and developers will leave for a more accommodating environment. The GNOME developers may well be guilty of occasionally erring on the "no" side of that line, however. The project probably hit its low point early in the 2.x series, when configuration options were being jettisoned in a seemingly indiscriminate manner and few apologies were forthcoming. The situation seems to have improved, however, even if work remains to be done; chances are that 2.12 will be the best GNOME release yet.
The nice thing about all this is that we are dealing with free software. Using GNOME is not required to get the most out of Linux. The KDE project is out there, and several other desktops as well; it should not be hard to find one to suit the needs of any particular user. One can even still operate a Linux system via an ADM 3 terminal, using the traditional key bindings. The GNOME hackers are doing the right thing in a general sense by pushing toward their vision of a better desktop. If they fail to meet the needs of the user community - or to listen to that community's feedback - there are plenty of alternatives to choose from. Or even the option of forking the project, should that seem like the best course. For the time being, however, this project has made major progress in the creation of a powerful Linux desktop, and the whole thing is free software. There are limits to how much one should complain about that.
[As a footnote, it's worth noting that long-time GNOME release manager Jeff Waugh is stepping down; his replacement will likely be Elijah Newren. Congratulations are due to Jeff for heading up several smooth, on-time GNOME releases.]
GNOME and the way forward
Posted Aug 18, 2005 1:00 UTC (Thu) by arcticwolf (guest, #8341) [Link]
It is hard to imagine that a desktop as complex and featureful as GNOME would be free of glitches.
Well, you have just given a sample list of some annoying behaviour in GNOME above, so imagining a desktop free of glitches is as easy as taking that list as a list of bugs that should be fixed. :)
The real problem, though, is not that GNOME is doing things a certain way, or the specific way it seems to be choosing (that is, doing things like Windows does instead of the way they're traditionally done on Unix). Rather, the underlying problem lies in the complexity of a system such as a desktop environment - there will always be people who dislike the current behaviour and wish to change it. Fortunately, though, this is a problem that can be dealt with - by making things configurable, it can be made possible for everyone to adapt the environment exactly to their needs, while at the same time making sure that the learning curve for first-timers is not too steep.
It is important to note, however, that the complexity is inherent in the system and cannot be gotten rid of. This is what Windows tries to do, and why it ultimately fails to provide a good desktop environment; GNOME seems to be emulating this, getting caught in the same trap where the product and its interface are dictated by marketing rather than being based on a rational evaluation of what can be done and what makes (or doesn't make) sense.
It has often been said that systems should be made as simple as possible, but not simpler than that - oversimplification ultimately creates more problems than it solves, and that goes for desktop environments just as for everything else.
I'm always somewhat sad that the GNOME developers (still) do not seem to understand this. But fortunately, in an open source world, there are viable alternatives - you aren't forced to use what some company thought would be best for their bottom line.
GNOME and the way forward
Posted Aug 18, 2005 2:43 UTC (Thu) by coulamac (guest, #21690) [Link]
Deciding what the boundary line for "too simple" is the tricky part of what you're saying. Different users will have different boundaries for as simple as possible/too simple.
This trickiness is compounded by figuring out who gets to decide what is "as simple as possible." The developers and maintainers do, of course, but as this article pointed out, if the developers and maintainers do not listen to their user base, the project might fail. So, who do the developers listen to?
That is, who is the targeted user base? If it is the power user, you might end up bewildering the casual user with too many options, bells, and whistles. If it is the casual computer user (i.e. non "power" user), then a simple desktop without too many distracting options is a good thing. Even some power users find this refreshing.
Some users, especially power users, on the other hand, enjoy fiddling with their desktop until it's just right. These users will become frustrated with the very simple desktop targeted at casual users. It appears that some vocal LWN readers (and many KDE users) fall into this latter group.
The next question is how you satisfy both groups. GNOME has tried (and at least partially failed, obviously) to satisfy the power users by placing many configuration options in a place hidden from the casual user but hopefully accessible to the power user: gconf-editor. Whether it is the fact that these options are partially hidden or whether it is the design of gconf-editor, power users do not appear to be satisfied. If it is the latter, one would hope that some power users would pitch in to make gconf-editor more user-friendly to the power users. It should also be noted that there are other, very under-publicized GNOME tools out there for the power user. See GNOME Power User Tools.
Lastly, making everything configurable-- even with hidden configuration options-- comes at a cost to the developers and can make the software unusable. See an article by Havoc Pennington with a section entitled The Question of Preferences. See also the recent blog by Matthias Ettrich, the founder of KDE, regarding having too many preference options, with the header entitled Configurability. So, having "too many" options (whatever that is) is also not the answer.
Getting the desktop just right for both casual users and power users is very, very tricky. OSX seems to do this well, by all reports. Does anyone have any insight as to why?
GNOME and the way forward
Posted Aug 22, 2005 19:19 UTC (Mon) by utoddl (subscriber, #1232) [Link]
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.
GNOME and the way forward
Posted Aug 18, 2005 1:21 UTC (Thu) by walters (subscriber, #7396) [Link]
"Your editor is burned daily by the metacity "a new window gets the keyboard focus regardless of the pointer position" policy"
You'll be happy to know then that focus stealing preventing will be in GNOME 2.12.
GNOME and the way forward
Posted Aug 18, 2005 1:39 UTC (Thu) by newren (subscriber, #5160) [Link]
It was in Gnome 2.10 as well--is Jonathan just running an out-of-date version? ;-)
GNOME and the way forward
Posted Aug 18, 2005 3:16 UTC (Thu) by corbet (editor, #1) [Link]
I'm running 2.11.90, according to RPM. I'll run a test again in the morning; I know 2.10 still had the problem. I was once told it was my problem, that new windows should get the focus always regardless or most users will get confused...
GNOME and the way forward
Posted Aug 18, 2005 4:17 UTC (Thu) by elanthis (guest, #6227) [Link]
I would think that whoever told you that certainly wasn't in any way a speaker for the GNOME project. (Keep in mind that the mailing lists and forums are almost entirely filled with people who are NOT GNOME developers, but just proponents or users. This post itself is from someone who is NOT a GNOME developers.)
Focus stealing prevention was present in 2.10, but was not entirely mature. 2.12 has quite a few improvements. I can attast at the very least that on both my Ubuntu Breezy-devel and Fedora Rawhide boxes that focus stealing prevention works. New windows popup without stealing focus.
Sometimes. The rules are that new windows get focus baed on user interaction with the system. The idea being that if I click a button which results in a new window opening, I probably wanted that new window to have focus. There are still a few glitches with all this as applications that are not updated to provide proper hints to the window manager may behave improperly as Metacity has to make some guesses on the user's intent.
Focus stealing
Posted Aug 18, 2005 4:28 UTC (Thu) by corbet (editor, #1) [Link]
With 2.11.90 it still happens. Easy example: type "gnome-terminal &" in a terminal emulator in the lower right corner. The new terminal window will appear in the upper left. Focus will move to the new window (whenever it appears) even though the pointer remains in the original window. If the new window is slow to appear, the focus will move at an unpredictable time in the future. It's annoying as hell. I use focus-follows-pointer and do not wish the system to ever do anything else.I also have a hell of a time with firefox snarfing the focus if the pointer passes over it briefly on the way to some other window. That problem has not gone away either.
Focus stealing
Posted Aug 18, 2005 4:53 UTC (Thu) by newren (subscriber, #5160) [Link]
type "gnome-terminal &" in a terminal emulator in the lower right corner...Focus will move to the new window (whenever it appears) even though the pointer remains in the original window. If the new window is slow to appear, the focus will move at an unpredictable time in the future.Yeah, focus-stealing-prevention requires apps to be launched with startup-notification to work, and launching them from the terminal doesn't do that. Sorry. Haven't been able to come up with a better solution (if you can think of one, let us know on wm-spec-list). Do a "export DESKTOP_STARTUP_ID=_TIME0" before launching as a hacky workaround.
I also have a hell of a time with firefox snarfing the focus if the pointer passes over it briefly on the way to some other window.Um, you moved the mouse over the firefox window and are using focus-follows-mouse; why shouldn't it get focus? Or are you saying that firefox keeps the focus despite you continuing to move the mouse into other windows? (If the later, I've never seen it--is there any way you can find of more easily reproducing it?)
Focus stealing
Posted Aug 18, 2005 12:49 UTC (Thu) by corbet (editor, #1) [Link]
Yeah, focus-stealing-prevention requires apps to be launched with startup-notification to work, and launching them from the terminal doesn't do that. Sorry.
That has been my mode of working since I first discovered X10. A common pattern, for example, is to fire off xv to look at an image file, then try to just make it go away with ^C. Doesn't work now, but it always used to work in older environments.
Rather than using elaborate schemes involving race conditions between the user and new applications, why not just have the focus be on the window under the pointer, always?
Um, you moved the mouse over the firefox window and are using focus-follows-mouse; why shouldn't it get focus? Or are you saying that firefox keeps the focus despite you continuing to move the mouse into other windows?
That's what I'm saying. My desktop tends to be a mess; image two emacs windows both of which are over a firefox window. Move the pointer from one emacs to the other, crossing over a small strip of the buried firefox window, and the focus may well end up on firefox. Then I usually do something like hit ^N half a dozen times and, rather than seeing the cursor move down, I'm rewarded with a pile of new firefox windows to clean up. Makes an editor grumpy, I tell you...
Focus stealing
Posted Aug 18, 2005 14:00 UTC (Thu) by Klavs (guest, #10563) [Link]
Not to be a troll, but that exact feature in KDE, is one of the things that keeps me running KDE.
So it seems it should be doable for Gnome as well.
Focus stealing
Posted Aug 18, 2005 16:37 UTC (Thu) by newren (subscriber, #5160) [Link]
In KDE with focus-follows-mouse - you can give a delay - so if you jump past a window (like firefox) the focus is not taken - as long as it is within that configurable delay.Also works for focus-under-mouse and focus-strictly-under-mouse modes, right? Kind of defeats what he requested, though ("why not just have the focus be on the window under the pointer, always?").
Also - if I in konsole start xclock - and the mouse stays over the konsole - xclock does not get focus, simply because it started.
KWin has four focus modes, IIRC. Which of them are you using (please check closely as three of them have very similar names)? Also, again IIRC, KWin's level of focus stealing prevention is configurable to 5 levels. To which level have you set it? (If I were to take a guess, I'd say you're using the default level of focus-stealing-prevention and using either the "Focus under mouse" or "Focus strictly under mouse" modes which totally destroy keynav (as claimed by KWin itself). I think adding a "strict" mode to metacity that doesn't focus new windows might make sense but I'd make it somewhat different as I don't think keynav should be ruined in any focus mode)
Secondly, note that you can use KWin under Gnome and Metacity under KDE. People have done both. I just point this out because technically you should have said "KWin" instead of "KDE" in your post, though it's unlikely you caused any confusion. ;-)
Focus stealing
Posted Aug 18, 2005 16:17 UTC (Thu) by newren (subscriber, #5160) [Link]
Rather than using elaborate schemes involving race conditions between the user and new applications, why not just have the focus be on the window under the pointer, always?
Maybe because (a) that's not actually possible in X (though yes, we could get much closer), (b) it also suffers from race conditions the way you've described it, (c) it inherently causes breakage with various other parts of the UI, (d) there's not always a window under the mouse (okay, so I'm being picky--we do have both sloppy and mouse focus modes after all for users that have different preferences in this situation), (e) some windows shouldn't get focus ever even if the mouse is over them, and (f) it is counter-intuitive for most users?
A little more explanation for those points that might not be obvious:
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.
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.
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.
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 is possible that a preference could be added (and one was proposed before by Havoc under the name "strict pointer mode", which I've talked about elsewhere in the comments here and the problems with understanding it), but I really need to know what it means. The comments in this article are helping, but if you read through it you'll probably find why it's hard to figure out what people really want (you described it first as "don't have windows take away focus while I'm busy with some app" which we can mostly get assuming apps are launched with startup-notification; now you describe it as focus-on-window-under-mouse-always which isn't quite possible and might entail more than you mean (do you really want keynav and window applets to be totally broken and to break apps that shouldn't take focus and to make an effort to rewrite all apps? or do you just want new windows to not be given focus? what about window placement and stacking for such new windows?); someone else tried to describe it in terms of what should happen when switching workspaces (probably alluding to an old Metacity bug) which is unrelated to new windows appearing.
image two emacs windows both of which are over a firefox window. Move the pointer from one emacs to the other, crossing over a small strip of the buried firefox window, and the focus may well end up on firefox.
This sounds like something that trying to have the WM enforce window with pointer has the focus may not fix; it's most likely some other deeper bug. I'd love to see a verbose debugging log:
Focus stealing
Posted Aug 18, 2005 16:36 UTC (Thu) by tjc (guest, #137) [Link]
> But most users launch an application and then want to use it; defaulting to not focusing new windows just doesn't make sense.You missed a step.
1. Launch application.
2. Drink coffee or pop for 10 seconds while you wait for all the shared libraries to load.
3. Use application.
Skipping step 2 results in a lot of frustration, which leads to criticism. Maybe this problem is more acute than it used to be, now that software takes so long to load. If no-one has the will to address the 10-second load time, then maybe the UI needs to be altered to accomodate it.
Focus stealing
Posted Aug 18, 2005 16:49 UTC (Thu) by newren (subscriber, #5160) [Link]
Hehe ;-)
Honestly, though, the 10 second load time is being addressed; that's what focus-stealing-prevention is for. Perhaps you were trying to use this as a reason to request never-focus-new-windows but like others here, you're not really addressing the issue and just listing cases that it looks like we've already covered.
Now, if you said, "Yes, launched windows shouldn't steal focus if the user works with another app between the time the window is launched and when it is shown--but that doesn't work without apps being launched with startup-notification which may not be feasible for us terminal users and we'd really like a preference, even if a kludge, to just not focus new windows" or if you said "Yes, most users launch an app then use it but us terminal users like to launch multiple apps without using them until a delayed time later so could we have a way to make the WM behave smart given our different usage scenario?" (see also bug 151818 comment 22, second half of point 8 for where I addressed this exact case) then I'd have an easier time understanding. In particular, though, I'd like to know more about the "behave smart" in the latter case--what do should be done relative to focus? placement? stacking? interaction with keynav? etc., etc.
Focus stealing
Posted Aug 18, 2005 18:02 UTC (Thu) by tjc (guest, #137) [Link]
> Perhaps you were trying to use this as a reason to request never-focus-new-windows but like others here, you're not really addressing the issue and just listing cases that it looks like we've already covered.No, I'm not. I've learned from experience that requesting anything from the Gnome development team is pretty much a waste of time.
> Now, if you said, "Yes, launched windows shouldn't steal focus if the user works with another app between the time the window is launched and when it is shown--but that doesn't work without apps being launched with startup-notification which may not be feasible for us terminal users and we'd really like a preference, even if a kludge, to just not focus new windows"
Depending on well-written apps to deal with the problem just about eliminates any chance that the problem will be completely fixed, ever.
> or if you said "Yes, most users launch an app then use it but us terminal users like to launch multiple apps without using them until a delayed time later so could we have a way to make the WM behave smart given our different usage scenario?"
Forget about launching from a terminal, launching from Gnome panel is a problem. It still takes 10 seconds to load some apps, and I don't want to sit around doing nothing for 10 seconds while I wait, and I sure don't want to be interrupted by a new window stealing the focus.
I know this problem is difficult to fix, but that doesn't mean that it isn't a problem. The fact that Windows XP handles this better than X should be some motivation to bite the bullet and fix the problems with X before writing a lot more software for a broken architecture. If it's a lot of work and disruption now, it will just be a bigger mess 5 years from now. The time to fix this is before Gnome gains widespread enterprise deployment, not after.
The alternative is to hire a bunch of marketing people to try and tell us that it's not really broken, all our friends like Gnome, it must be you, etc.
Focus stealing
Posted Aug 18, 2005 18:24 UTC (Thu) by newren (subscriber, #5160) [Link]
I've learned from experience that requesting anything from the Gnome development team is pretty much a waste of time.I'm sorry you feel that way. I hope I'm not part of the problem (though I probably am--I can't even get a small amount of the stuff done that I'd like to do myself), but for what it's worth I personally am trying to both (a) get things to work right for the default case (the normal "Gnomeish" response) and (b) cover extra important edge cases and smaller usage scenarios where merited with additional options (that's the whole reason for my lengthy posts here--I'm not sure I fully understand strict pointer focus and the requests for it but I would like to).
Focus stealing
Posted Aug 18, 2005 19:16 UTC (Thu) by tjc (guest, #137) [Link]
> I hope I'm not part of the problemNo, your not. My dissatisfaction dates back to the transition from Gnome 1.x to 2.x.
Focus stealing
Posted Aug 18, 2005 20:27 UTC (Thu) by pimlott (guest, #1535) [Link]
> 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".
Focus stealing
Posted Aug 18, 2005 21:13 UTC (Thu) by newren (subscriber, #5160) [Link]
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.
Focus stealing
Posted Aug 18, 2005 21:32 UTC (Thu) by corbet (editor, #1) [Link]
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...
Focus stealing
Posted Aug 18, 2005 23:18 UTC (Thu) by newren (subscriber, #5160) [Link]
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).
Focus stealing
Posted Aug 22, 2005 5:03 UTC (Mon) by EricBackus (guest, #2816) [Link]
newren wrote:
Focus stealing
Posted Aug 30, 2005 6:04 UTC (Tue) by newren (subscriber, #5160) [Link]
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. :-)
Focus stealing
Posted Aug 19, 2005 4:39 UTC (Fri) by pimlott (guest, #1535) [Link]
>/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.
Focus stealing
Posted Aug 18, 2005 21:27 UTC (Thu) by zblaxell (subscriber, #26385) [Link]
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 mouseThere 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 themWhich 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
Posted Aug 18, 2005 22:24 UTC (Thu) by newren (subscriber, #5160) [Link]
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
Posted Aug 18, 2005 23:29 UTC (Thu) by zblaxell (subscriber, #26385) [Link]
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
Posted Aug 18, 2005 19:37 UTC (Thu) by smoogen (subscriber, #97) [Link]
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?
Focus stealing
Posted Aug 18, 2005 20:46 UTC (Thu) by newren (subscriber, #5160) [Link]
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.
Focus stealing prevention
Posted Aug 25, 2005 8:24 UTC (Thu) by stuart (subscriber, #623) [Link]
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
Posted Aug 18, 2005 4:29 UTC (Thu) by newren (subscriber, #5160) [Link]
It's possible that different issues have been confused, in particular focus-stealing-prevention and a strict pointer focus or a never-focus-any-window-preference. I'll try to explain each to possibly make it easier for you to understand what's going on, but I'm just taking wild guesses. If you file a bug I'll look at it and have a better chance of finding out what your expectations are and what's actually happening.
Basically, Metacity's goal is that windows should not be focused if between launching the window and its appearing the user has started using another application. That's what the focusing stealing prevention stuff is (whose mechanism is a freedesktop.org spec pioneered by Lubos Lunak of KWin and KDE fame, btw). This feature, though, depends on apps cooperating to work correctly. For the most part, apps using QT or GTK should work fine. Other apps, such as emacs, may cause some problems and defeat focus stealing prevention--because for such apps the WM has no way of knowing if the user is interacting with them (other than mouse clicks) and it also has no way of knowing at what xserver time the user caused them to be launched in order to figure out if the user has interacted with other apps while waiting for the window to appear. (Well...Soeren has suggested a workaround for the latter of these problems but we haven't gotten around to trying it out yet). There are also special cases where app authors need to help out (e.g. those apps that when launched don't actually open a window but instead tell a different instance of the same app to open a window for them). The final kink is that app authors can lie to the WM and/or use X calls to attempt to forcefully steal focus anyway (which it appears some do--sigh). That's all kind of a long-winded explanation of possible bugs, but yes the basic idea idea is to focus new windows if the user "isn't busy doing something else".
Now, some people have requested a window-is-focused-iff-pointer-is-in-it (which destroys/prevents keyboard navigation and potentially other things if followed 100%), for which "strict" pointer mode patches have been written. For the most part, though, these patches were really designed to fix dozens of bugs that used to exist in metacity in mouse and sloppy focus modes. But there is one issue left that wasn't just cop-out-workaround-for-ugly-bugs from such patches, namely a 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?
Also, there are people who are proponents of a never-focus-new-windows-no-matter-what behavior. This one I understand (lets you launch lots of applications or windows but keep working with your current one) but it doesn't exactly fit the normal user. Most users will launch an application and then want to use it as soon as it appears; if it's not focused they'll be annoyed that they have to move the mouse to the window and (for click-to-focus users) click on it before they can begin typing when the window appears.
Anyway, there's a long winded explanation to try to explain what you might be expecting and what might be occurring. But I'm just taking wild guesses here. File a bug and I'll take a look at it.
GNOME and the way forward
Posted Aug 18, 2005 6:35 UTC (Thu) by sfeam (subscriber, #2841) [Link]
Different strokes / different folks. I'm of the school that says nothing should ever steal the focus from a window I am typing in. Ditto for windows I am interacting with via mouse clicks. Basically I *never* want a new window or new app to steal focus. Are you saying I have to file a bug report in order to request that behaviour?
GNOME and the way forward
Posted Aug 18, 2005 7:02 UTC (Thu) by jamesh (guest, #1159) [Link]
The two constraints people usually want honoured for new window behaviour are:
The rules the focus stealing prevention code uses are essentially the following:
The idea here being to do the right thing without a preference. Unfortunately, some applications need modification to function correctly in this system (e.g. specifying where in the event stream a particular window was requested, or telling the window manager not to focus a new window that is not the result of a user action).
GNOME and the way forward
Posted Aug 18, 2005 10:05 UTC (Thu) by jschrod (subscriber, #1646) [Link]
If a user starts an application, they want to use it so it should be focused.
I beg to differ. If I want to use an application, I move my mouse to it. I often start an application in the background, and will come back later to it. *I* decide when I come back to it, not the window manager's developer.
This behaviour of GNOME is one of the main reasons why I don't use it, though I tried it several times.
Cheers, Joachim
GNOME and the way forward
Posted Aug 18, 2005 10:07 UTC (Thu) by kleptog (subscriber, #1183) [Link]
1. If a user starts an application, they want to use it so it should be focused.Interesting idea, but I disagree. I'm in front of my computer and if I want to use an app I will point my mouse at it.
I'm probably not the target audience though. I'm running FVWM with 16 virtual desktops in a 4x4 matrix, one app per desktop. I use MouseFocus/SloppyFocus. When I switch to a new desktop (with the shortcut keys) I expect wherever the mouse lands to be the window with focus. If it lands on the background then the focus doesn't change i.e. it's off screen.
You may find this strange but it's a 100% deterministic system and I can control my focus perfectly to acheive exactly what I want. What you describe is non-deterministic because it depends on the apps doing things I can't see.
What I find most amazing is that strict-mouse-focus is the easiest system of all. Detect what the mouse is over, that window has focus. And no, clicking on it doesn't raise it either.
GNOME and the way forward
Posted Aug 18, 2005 17:15 UTC (Thu) by newren (subscriber, #5160) [Link]
Interesting idea, but I disagree. I'm in front of my computer and if I want to use an app I will point my mouse at it.Note that James said "two constraints people usually want honoured". See also bug 151818 comment 22 (second half of point 8 of that post), where I discussed this issue and the usage scenarios that would lead to whether users wanted new windows focused in addition to how they should be placed. Also, you seem to have ignored placement. What if the new window is big enough that it can't be placed onscreen without being placed where the pointer is? Should the window not be focused anyway? Or is it okay to focus it in that case? Should the WM attempt to avoid where the mouse is for window placement in general (that's racy if the user happens to be moving the mouse at the time the window appears...)? Should the new window be placed at the top of the stack of windows? Below the focus window in stacking (but hopefully as disjoint as possible in location)? Below all other windows to avoid races? Should it just not be shown until the user clicks on a button in the taskbar? What about apps that try to transfer focus from one of their already onscreen windows to another already onscreen window (and which may be needed in order for keynav to work correctly)--should such requests just be summarily denied because the user hasn't moved the mouse? What about alt-tab, the taskbar, and the window selector applet--should these all become no-ops and appear to be broken to the user unless the user moves the mouse at the same time? People are complaining but no one seems to be addressing all these other issues that would be needed in order to understand how to make the environment sane with a new preference.
I'm probably not the target audience though. I'm running FVWM with 16 virtual desktops in a 4x4 matrix, one app per desktop. I use MouseFocus/SloppyFocus. When I switch to a new desktop (with the shortcut keys) I expect wherever the mouse lands to be the window with focus. If it lands on the background then the focus doesn't change i.e. it's off screen.Workspace switching behavior with existing windows isn't related to the decision about what to do with entirely new windows. It sounds like you're complaining about an old Metacity bug.
You may find this strange but it's a 100% deterministic system and I can control my focus perfectly to acheive exactly what I want. What you describe is non-deterministic because it depends on the apps doing things I can't see.
Actually, no it isn't 100% deterministic; windows can steal focus anyway. XSetInputFocus requests by apps are unconditionally granted by the XServer with the WM given no chance to prevent such focus changes (this is a bug in the X11 protocol--google for "Why X is not our ideal system" written in 1990 by some of the people who came up with the ICCCM; no, their suggestions for fixing this aren't part of X today). Granted, most apps won't do this to you but unless you've completely audited all the apps you are using (meaning the exact version of the apps that you are using), it isn't 100% deterministic.
Further, you misunderstood what James said if you think that what he wrote "depends on apps doing things I can't see". Both your method and what he outlined should be deterministic modulo bugs.
What I find most amazing is that strict-mouse-focus is the easiest system of all. Detect what the mouse is over, that window has focus. And no, clicking on it doesn't raise it either.Why should you be amazed that an environment which you are used to is the easiest for you? ;-) Also, making the window under the mouse always be the one with focus isn't actually possible under X--see my response to Jonathan elsewhere in the comments to this article. You can get an implementation that is closer than what Metacity currently allows, but all the ones I've seen destroy keyboard navigation which doesn't make sense to me (do people really want that? Or did no one consider the possibility of inbetween behavior that gets as close as possible without destroying keynav? I could implement either but I don't know what people really want). (I discussed orthogonality of raise with other actions elsewhere in comments under this article as well so I won't repeat here)
GNOME and the way forward
Posted Aug 18, 2005 22:29 UTC (Thu) by kleptog (subscriber, #1183) [Link]
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,
GNOME and the way forward
Posted Aug 27, 2005 16:07 UTC (Sat) by ekj (guest, #1524) [Link]
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
Posted Sep 2, 2005 21:36 UTC (Fri) by renox (subscriber, #23785) [Link]
>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..
GNOME and the way forward
Posted Aug 18, 2005 15:29 UTC (Thu) by newren (subscriber, #5160) [Link]
Hehe, your explanation of your requested behavior doesn't quite match:I'm of the school that says nothing should ever steal the focus from a window I am typing in. Ditto for windows I am interacting with via mouse clicks.Translates as "don't transfer focus to a new window if I'm busy with another window (implying that a transfer of focus is okay if you're not busy with another window)". Note that Metacity does this.
Basically I *never* want a new window or new app to steal focus.Translates as (rather obviously) "don't transfer focus to a new window regardless of whether I'm busy with another window". Metacity has no option for this, currently.
A "strict" mouse focus has been proposed and in fact patched in by RHEL, Debian, and Ubuntu so it may well end up in Metacity itself. But the patch (in bug 152004) that proposed it was kind of muddied by the fact that it uses lots and lots of kludges to workaround dozens of other bugs that no longer exist so it was hard to differentiate between a real request and just a workaround for old bugs...
GNOME and the way forward
Posted Aug 18, 2005 18:58 UTC (Thu) by loening (guest, #174) [Link]
I'm also of the school that says nothing should ever steal the focus from a window that I'm typing in. But by "typing", I mean that I have been typing in that window, not that I necessarily have managed to type anything else between the time a new app has been started and the 0.2s it takes to popup a window on the screen.For the gnome-terminal example, if I type "gnome-terminal &" in the terminal window, I don't want the new terminal to grab the focus, even through the new window (at least on my 2GHz box) pops up faster then I can type another key.
After reading through this very insightful thread, I now understand how the current behavior has been arrived upon in GNOME. But I would personally love an option to enable "new window doesn't steal focus unless it pops up under the cursor" behavior.
GNOME and the way forward
Posted Aug 18, 2005 19:20 UTC (Thu) by newren (subscriber, #5160) [Link]
So in other words we just have to place new windows where the mouse currently is and then you're fine with the new window taking focus?
GNOME and the way forward
Posted Aug 18, 2005 19:59 UTC (Thu) by loening (guest, #174) [Link]
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.
GNOME and the way forward
Posted Aug 18, 2005 20:51 UTC (Thu) by newren (subscriber, #5160) [Link]
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).
GNOME and the way forward
Posted Aug 18, 2005 8:30 UTC (Thu) by spitzak (guest, #4593) [Link]
Keyboard navigation can be made to work in a strict focus-follows-pointer
GNOME and the way forward
Posted Aug 18, 2005 18:03 UTC (Thu) by newren (subscriber, #5160) [Link]
Keyboard navigation can be made to work in a strict focus-follows-pointer by *moving* the pointer. I have done this in flwm and it seems to work very well. When shortcuts are used to move the focus the mouse is moved to the nearest point in the window, plus a few pixels.Fair point and sounds like a fine criteria for you; we considered it but didn't really like the idea of warping the pointer around.
People really are thrown off if a focus-follows-pointer if at times the focus and pointer do not match. Do not do it.I understand in general, but there's a number of caveats:
First, this just isn't possible due to application grabs of the mouse, windows that should not get focus at all, and windows that shouldn't be focused except in special circumstances (e.g. desktop windows that covers the entire screen or taskbars/panels).
Second, not all people are surprised by this (in fact, many focus-follows-mouse users are surprised if applications they launched don't get focused; yes there was a time when Metacity didn't focus new windows and lots of users, including those using focus follow mouse, who got surprised).
Third, it'd make clicks in the wrong place on the window list/taskbar really damaging as the user would then have to move the mouse a long ways to go and click where they really meant to on the taskbar. It's a tradeoff; and one where we picked allowing mouse navigation constraints (focus is under the mouse) to be temporarily suspended instead of warping the mouse.
Fourth, if users are so confused by the focus not being under the mouse, why then do most focus follows mouse users seem to prefer don't-defocus-on-window-exit-unless-entering-a-new-window? It matters in more ways than you probably notice at first; in particular think about this hairy condition for users who use keynav to move a window a few workspaces away: if the pointer wasn't on any window in the first workspace but after switching a workspace it is on a different window than being moved, what should happen? Should the window that the mouse is over get focus? That would likely result in the user moving that new window to a different workspace when they meant to move the original window more than one workspace. Should the WM then warp the mouse to the window that moved workspaces? Seems really weird that the user can interact with the window for a while but the warping of the mouse doesn't happen until then. (Personally, I treat this as a "user is using the keyboard to navigate instead of the mouse so mouse navigation invariants are temporarily suspended until the user starts using the mouse again"--seems to work great and gracefully handle the conflict between keynav and mousenav without warping the pointer; haven't had complaints with this method so far, other than the "don't focus new windows ever" thing which can be an added option)
GNOME and the way forward
Posted Aug 18, 2005 15:56 UTC (Thu) by tjc (guest, #137) [Link]
> Also, there are people who are proponents of a never-focus-new-windows-no-matter-what behavior. This one I understand (lets you launch lots of applications or windows but keep working with your current one) but it doesn't exactly fit the normal user.This behavior is fairly close to Windows XP, so I don't think it would confuse "normal" users.
If one starts a program in Windows XP and then gives the focus to an existing window (by clicking on it) before the new window is mapped, the new window is placed in the stacking order just below the focused window, and the current window retains focus. This seems to work well enough that most people don't even realize that it's happening.
Extending this to focus-follows-pointer mode, it seems reasonable to assume that if a user chooses focus-follows-pointer that they are not likely to be confused by windows retaining focus no matter what. Mapping the new window second-from-the-top is nice too, since mapping a "dead" window over the top of the currently focused window is almost as bad as stealing focus.
GNOME and the way forward
Posted Aug 18, 2005 17:31 UTC (Thu) by newren (subscriber, #5160) [Link]
If one starts a program in Windows XP and then gives the focus to an existing window (by clicking on it) before the new window is mapped, the new window is placed in the stacking order just below the focused window, and the current window retains focus. This seems to work well enough that most people don't even realize that it's happening.This is what we do in Metacity as well. It's an implementation of the focus stealing prevention spec pioneered by Lubos Lunak.
Mapping the new window second-from-the-top is nice too, since mapping a "dead" window over the top of the currently focused window is almost as bad as stealing focus.Ugh. Others who have requested a never-focus-new-windows have also requested a always-place-new-windows-on-top-even-if-not-given-focus. This is already a niche group. Why this explosion of options (and no, it's not just one more--you are only one of the people requesting just one more)? WMs that are the union of all features of all other WMs (e.g. Sawfish) aren't maintainable. Sorry to give this rant again, but N features toggles results in 2^N testing and maintenance workload which is just not realistic. I think it's worthwhile to try to add options to cover the larger of the niche usage groups (a strict focus option that causes new windows to not get focus, as proposed by Havoc in bug 152004 and heavily requested here, sounds reasonable). However (I hope I don't come across as offensive here), Metacity just isn't going to cover every case. Openbox, flwm, KWin, sawfish, fvwm, etc. (most of which can and have been used by users under Gnome), exist for users whom we can't satisfy with the preferences we are willing to add.
GNOME and the way forward
Posted Aug 18, 2005 18:16 UTC (Thu) by tjc (guest, #137) [Link]
> Ugh. Others who have requested a never-focus-new-windows have also requested a always-place-new-windows-on-top-even-if-not-given-focus.Just to clarify, what I'm suggesting is to *not* place new windows on top. Mapping them second from the top like Windows XP seems to work well. It's non-intrusive, and it doesn't seem to confuse new users.
GNOME and the way forward
Posted Aug 18, 2005 18:28 UTC (Thu) by newren (subscriber, #5160) [Link]
Right, I'd prefer to do things the way you suggest for a strict focus policy as I think it makes more sense, but I was just pointing out that others in months past have simultaneously requested a never-focus-new-windows AND always-place-new-windows-on-top.
GNOME and the way forward
Posted Aug 18, 2005 23:03 UTC (Thu) by zblaxell (subscriber, #26385) [Link]
Now, some people have requested a window-is-focused-iff-pointer-is-in-it (which destroys/prevents keyboard navigationI'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
Posted Aug 18, 2005 15:30 UTC (Thu) by tjc (guest, #137) [Link]
> I was once told it was my problem, that new windows should get the focus always regardless or most users will get confused...Yeah, I've talked to the same person, and was told that these users are also confused by horizonal/vertical window mazimize options. I hope that moving windows doesn't confuse anyone, or we'll all be in trouble.
GNOME and the way forward
Posted Aug 18, 2005 19:04 UTC (Thu) by bronson (subscriber, #4806) [Link]
Ah, many of us have talked to the same Red Hat employee. His refusal to accept a simple patch to toggle horizontal and vertical maximization is what drove me to use the KWin window manager to show my Gnome desktop (works great, btw). Basically, he required that the h/v-maximize patch also "fix" the current atom behaviour, turning clean tens of lines patch into a few hundreds of lines of gobbledygook. If this continues to be the case, I'm skeptical that Metacity will EVER support toggling h/v-maximization.
GNOME and the way forward
Posted Aug 18, 2005 20:10 UTC (Thu) by jeskritt (guest, #4092) [Link]
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
Posted Aug 18, 2005 2:12 UTC (Thu) by newren (subscriber, #5160) [Link]
Your editor is burned daily by the metacity "a new window gets the keyboard focus regardless of the pointer position" policy; having the focus yanked away in the middle of a sentence does not seem like the most user-friendly policy.
What version of Metacity are you running? That shouldn't happen any more with focus stealing prevention. If you're using a recent version it sounds like you found a bug; if so, I'd love to see a bug report if you have the time. Further, your comment about "regardless of pointer position" is puzzling. If the window happens to appear where your current one is, you don't care if the window takes focus away while you're in the middle of typing a sentence? Sounds strange to me. ;-)
Clicking on a window does not mean the window should be raised; there is a separate combination for that.
I have a patch if you want it. It also turns out that this specific preference has been patched in by RHEL, Ubuntu, Debian, XD2, SUSE, Novell, and perhaps others though I haven't checked (however, all of them have botched the patch to varying degress); I intend to propose the patch for the 2.13 development cycle predominantly on this basis (I only found out about XD2, SUSE, and Novell doing recently when Federico hunted me down to ask some questions about it, so it's too late for 2.12).
GNOME and the way forward
Posted Aug 18, 2005 2:42 UTC (Thu) by jwb (guest, #15467) [Link]
Most people's complaints seem to center around bad window management. It's now wonder why:
XFWM4's behavior is the ultimate expression of Fitts' Law. The window itself is a huge target, so
why not use the entire area for move and resize commands? And I think when people see these
changes in Gnome they think X11 is reverting back to the terrible Windows and MacOS behavior. In
other words, they see changes that make Gnome more Windows-like or more Mac-like as being a
severe inconvenience.
Luckily those of use in the know can just use XFCE :)
GNOME and the way forward
Posted Aug 18, 2005 3:15 UTC (Thu) by jamesh (guest, #1159) [Link]
Metacity seems to have similar behaviour: alt + left button moves, alt + middle button resizes and alt + right button shows the WM menu for the window.
GNOME and the way forward
Posted Aug 18, 2005 3:33 UTC (Thu) by jwb (guest, #15467) [Link]
I wasn't trying to pick on Metacity, I only use XFWM4 as an example because that's my favorite. I think Metacity is also a fine WM. My only point was that, in GNOME development, simplification frequently means removing some feature that some users have been using for a decade. Hence I can understand the whining.
GNOME and the way forward
Posted Aug 21, 2005 8:05 UTC (Sun) by amikins (guest, #451) [Link]
That's pretty much been my experience with Gnome since 2.0 started.
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
Posted Aug 18, 2005 2:27 UTC (Thu) by dskoll (subscriber, #1630) [Link]
The problem is that the GNOME developers seem to think that their way is the Right Way (tm) and are unwilling to accept that maybe they should give people choices.
Let's face it, a Windows user switching to GNOME will suffer all kinds of jarring discontinuities. So I think it's pointless to try to make GNOME appeal to some mythical user base if that means alienating its existing user base, which is pretty much UNIX/Linux geeks.
My pet peeve is Evolution's lack of support for an external editor. I've been told that "nobody sane" cares about that.
Why, then, does every UNIX mailer I can think of (Pine, Mutt, kmail,
Sylpheed, Balsa, Mahogany, Thunderbird) support an external editor? Are all of those developers stupid enough to spend time implementing a feature that "nobody sane" cares about?
No, the problem is that an external editor is something that no GNOME developer cares about, and therefore by extension, only whingers and bearded UNIX hackers care about it, and they don't matter.
That is why GNOME is becoming irrelevant to me, and why I hope it fades from the scene if the developers don't change their attitude.
And I do not agree when you state "There are limits to how much one should complain about that." Because of the state of the Linux market, the GNOME developers have considerable influence in the future of Free desktop software. I certainly didn't embrace Linux to be trapped in another limiting Windows clone. Unfortunately, that's the way GNOME is heading.
GNOME and the way forward
Posted Aug 18, 2005 2:53 UTC (Thu) by coulamac (guest, #21690) [Link]
Your disagreement with the Evolution maintainer should not be a basis for tarring the entire GNOME developer community. If Evolution is not your cup of tea because of the external editor issue, free free to use other mail programs. Maybe Balsa will satsify your needs (http://balsa.gnome.org/). Maybe, you should use a non-GNOME mail program. That would be fine: there's no law saying every program you may want to use should be GTK+/GNOME based if you're using GNOME. Similarly, there are KDE users that use GTK+/GNOME programs frequently.
Good luck! :-)
GNOME and the way forward
Posted Aug 18, 2005 3:15 UTC (Thu) by whiprush (guest, #23428) [Link]
Dude, really, if an external editor for your MUA is a hugely important feature, then you are not GNOME's target audience.
GNOME and the way forward
Posted Aug 18, 2005 6:24 UTC (Thu) by JoeBuck (guest, #2330) [Link]
How does an optional capability to interface an external editor to Evolution harm users who are not interested in such a feature?
GNOME and the way forward
Posted Aug 18, 2005 9:27 UTC (Thu) by job (guest, #670) [Link]
It is an extra configuration option, which is what the whole 2.x tree was about minimizing. (Just guessing from the previous thread here.)
GNOME and the way forward
Posted Aug 18, 2005 10:10 UTC (Thu) by jschrod (subscriber, #1646) [Link]
Thank you for asserting that approach to user satisfaction.I tried GNOME several times and found it annoying at best. You explain perfectly well the root cause of that observation.
Cheers, Joachim
GNOME and the way forward
Posted Aug 18, 2005 13:11 UTC (Thu) by nix (subscriber, #2304) [Link]
If you care about how your text editor works and use any but its very simplest features, you probably want consistency in editor behaviour. (You know: consistency? Supposed to be a *good* idea in UI design?)
If I send a mail in Evolution but do all my other editing in vim or Emacs, I'm currently being unnecessarily forced to use an inconsistent (and, IMHO, grotesquely feature-poor) editor for *only some* things.
*That* is why every other program on the face of the Unix earth supports $EDITOR and $VISUAL. (I fail to see why reading the values of two environment variables would confuse newbies, either. They're invisible if you don't know they're there.)
(Well, except for Emacs apps, and they're somewhat special, running as they do *inside* an editor.)
What you're saying is that if you care about your user interface or care about the job you spend most of your time doing when interacting with a mail program (i.e., writing mail), then you're not in the target audience for GNOME. Fine, but this, it seems to me, removes every reason to ever use GNOME email programs in the first place. (Why would you use an easy-to-use user interface's email program if you don't care about ease of use or writing email?)
GNOME and the way forward
Posted Aug 18, 2005 19:15 UTC (Thu) by bronson (subscriber, #4806) [Link]
Damn. Apparently I'm not in Gnome's target audience even though I've been using it since 1999. Pray tell, Whiprush, what is Gnome's target audience?
I absolutely loathe Evolution's editor. It almost always reformats the mail so what you think you're sending is not at all what actually gets sent. You can't use it for more than a day without running into multiple quotation or copy/paste bugs. But, despite Whiprush's suggestion, I'm not ready to dump the Gnome desktop quite yet.
GNOME and the way forward
Posted Aug 18, 2005 23:51 UTC (Thu) by njhurst (guest, #6022) [Link]
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.
GNOME and the way forward
Posted Aug 18, 2005 2:56 UTC (Thu) by mem (subscriber, #517) [Link]
Part of the problem is that while GNOME developers bitch about "an inconsistent user experience" they have gone out of their way to provide a consistent user experience that's *inconsistent* with the rest of the only environemnt where GNOME actually runs.
Take middle click pasting. Sure, it's not Microsoft Windows, but it *is* the way the X Window System works. The X way is non-intuitive for long-term Microsoft Windows users, but it's expected behaviour for long-term Unix users. The argument against the X way, at least the one put forward by GNOME developers, is that in the X way selecting with the mouse destroys the information in the current selection. A short trip to the X Window documentation reveleas the difference between "selection" and "cut buffer". When you select something with the mouse you destroy the information in cut buffer 0, but the other buffers remain intact.
Sure, there's stuff that can be fixed in the system and there *is* stuff that's broken (cut and paste of complex data just doesn't work -- e.g. selecting something in the Gimp and pasting it in Inkscape -- mostly because the programs can't agree on an interchange format, and IIRC Jim Gettys came with a proposal for fixing that). The point is that that isn't a reason to go ahead and plain ignore it.
Try for example Epiphany. It's a TOTAL MESS. Sometimes you have to go to the location bar, select and hit copy, sometimes selecting is enough. Selecting in another program and pasting to Epiphany is even *worse*. Why this? Because GTK+/Gnome just can't play nice with the rest of the environment.
GNOME's "consistent user experience" actually means "to comply with the expectations of the users of a different environment."
GNOME and the way forward
Posted Aug 18, 2005 3:22 UTC (Thu) by hp (subscriber, #5220) [Link]
For the specific example you cite (clipboard, cut-and-paste) there are guidelines that pretty much everyone has agreed on:
These guidelines are believed to spell out the intent of the ICCCM version 2 from 1994. So blaming GNOME isn't really accurate. The cut buffers you mention were considered deprecated in the ICCCM at that time, replaced by the CLIPBOARD selection for a variety of reasons.
All the recent GNOME/KDE/Mozilla/OO.org stuff works the same way as documented at the above URL, modulo any remaining bugs but my experience is that stuff follows the guidelines. Even on old UNIX systems, there were a number of apps that used these cut-and-paste guidelines, they are not exactly new.
Finally, as documented in the first point in the GTK+ 2.0 release notes in 2002, there is a config option to turn off the select-text-on-focus behavior and the ctrl+c/ctrl+v keybindings if you like.
GNOME and the way forward
Posted Aug 18, 2005 3:58 UTC (Thu) by jamesh (guest, #1159) [Link]
You realise that the X selection mechanism was designed to replace the idea of cut buffers in X? Quoting from the 1988 O'Reilly Xlib Programming Manual:
Cut buffers are provided as a simple but limited method of interclient communication. Cut buffers are sometimes used by applications that use the Andrew toolkit. The concept (but not the implementation) of cut buffers was inherited from Version 10 of X. The selection mechanism is superior for many applications since it allows communication regarding the type of the data transferred.
So it isn't surprising that a toolkit written after 1988 would be written to use the selection mechanism in preference to cut buffers.
As with cut buffers, you can have more than one selection. The two most commonly used ones are PRIMARY and CLIPBOARD, both of which GTK uses. When you select a piece of text, the application acquires the PRIMARY selection. When you middle click in another application, that application requests the contents of PRIMARY in the form it wants. When some other application acquires the PRIMARY selection, the first app deselects its text.
The CLIPBOARD selection is used for the traditional cut/copy/paste operations, and should not interfere with X-style select/middle-click. This all works correctly in GTK if you are using the standard widgets. If an application uses custom widgets or has complex data to cut/paste it will need to have custom selection code, which may have bugs in it (although it is a lot easier to implement with the GtkClipboard interface added a few versions back).
With regard to Epiphany, note that it embeds Mozilla. Mozilla's selection behaviour seems to be quite broken: conflating PRIMARY and CLIPBOARD, not deselecting text when someone else acquires PRIMARY, etc. This just confuses matters, and there is a limit to what Epiphany can do until Mozilla is fixed.
GNOME and the way forward
Posted Aug 18, 2005 3:03 UTC (Thu) by hp (subscriber, #5220) [Link]
Lots of times people don't appreciate the efforts that were made. For example, this 100-post LWN flamewar was about Emacs-style keybindings...
The GTK+ team went to a significant extra effort to offer an Emacs key theme when GTK+ 2.0 came out, it's been there ever since, and the GNOME usability team even documented it in the Human Interface Guidelines:
http://developer.gnome.org/projects/gup/hig/2.0/input-key...
In fact, how to choose the Emacs key theme is the first item in the GTK+ 2.0 release notes in 2002:
http://www.gtk.org/gtk-2.0.0-notes.html
GNOME does have a lot of accomodations and features designed for people used to UNIX, and more of these features have been added over time.
One suggestion is to move them all to a "UNIX Stuff" control panel so they are easy to find, and so more of them can be visible in the GUI without hosing up the other control panels with clutter.
That said, the goal is a "mainstream" rather than "UNIX" desktop and that goal has always been explicit. So _when_ there's a tradeoff or conflict the needs of office workers will win out over those of a 20-year UNIX sysadmin. Not a secret.
GNOME and the way forward
Posted Aug 18, 2005 4:04 UTC (Thu) by piman (subscriber, #8957) [Link]
Havoc,
Thanks. I've been using the GTK 2.0 Emacs bindings since they were the GTK 1.3 Emacs keybindings. I seriously didn't understand the flamewar that was happening in the other thread. I've also had no serious problems with clipboards; X primary selections have been that ephemeral for as long as I've been using Unix.
One of the biggest problems in free software is that there's no an easy way to file an "it-works-great report".
GNOME and the way forward
Posted Aug 18, 2005 4:55 UTC (Thu) by iabervon (subscriber, #722) [Link]
The problem with the Gtk emacs keybindings is that Gtk implements them differently from how emacs does. Consider, for example, Ctrl-K.
I will note that OS X's emacs keybindings actually get Ctrl-K right, so it is possible. (Pressing Ctrl-K cuts to the end of the line, unless the cursor is at the end of the line, in which case it cuts the line break, and pressing it again without intervening keypresses appends the removed text to the clipboard rather than replacing it.)
GNOME and the way forward
Posted Aug 18, 2005 12:28 UTC (Thu) by hp (subscriber, #5220) [Link]
Maybe the bindings can be improved, nobody is against it in principle afaik. Someone has to do the work though.
Obviously we aren't going to fully implement Emacs, so they will always be sort of limited vs. Emacs itself.
GNOME and the way forward
Posted Aug 18, 2005 14:10 UTC (Thu) by ajross (guest, #4563) [Link]
I think the poster was a little confused. The ^K behavior he describes for OS/X is identical to the one I see in FC4's 2.10 gedit. The other complaints are about the lack of GNU Emacs's selection and copy behavior, which have never been traditionally part of "emacs keybindings" (e.g. the Motif widgets didn't support them either), which actually predate the GNU program by quite a bit.The collision between the window keybindings and the emacs ones, though, is a good point. I have the emacs cursor movement keys in my synapses and they (^P ^N, ^F, ^B) tend to have very surprising effects when they get sent to non-emacs windows. Maybe someone could hack at the event precedence so a text field with focus can intercept them selectively, as part of the theme?
GNOME and the way forward
Posted Aug 18, 2005 16:47 UTC (Thu) by dskoll (subscriber, #1630) [Link]
So _when_ there's a tradeoff or conflict the needs of office workers will win out over those of a 20-year UNIX sysadmin.
Why does such a tradeoff or conflict exist? Could I have an example? Here where I work, the developers use Linux, and the salespeople use Linux, and I don't think either group feels particularly restrained by the other. Linux desktops work pretty well for both groups.
Assuming such a tradeoff is necessary, any UNIX-based desktop system that cannot allow a user to choose which way to resolve such a tradeoff, but instead hard-codes it, is badly designed.
GNOME and the way forward
Posted Aug 18, 2005 17:09 UTC (Thu) by hp (subscriber, #5220) [Link]
The most obvious form of the tradeoff is that you have two very different lists of requests and priorities from the different users, and you have to allocate developer time between working on one list vs. the other. No way around that. The only world without tradeoffs is one with infinite resources.
Another easy-to-understand tradeoff is that lots of people here seem to be requesting the UNIX behavior _by default_ and all defaults are a tradeoff vs. the other possible defaults.
Some other tradeoffs are mentioned in http://ometer.com/free-software-ui.html for example
It's tough to really have a feel for why there are tradeoffs until you've worked on the software for a while and seen how a design is done and how the maintenance issues unfold over time.
But while we can nitpick I don't see how some of these tradeoffs are arguable. There's obviously only finite developer time, and there's obviously only one set of default settings.
GNOME and the way forward
Posted Aug 18, 2005 17:32 UTC (Thu) by dskoll (subscriber, #1630) [Link]
The only world without tradeoffs is one with infinite resources.
Agreed. So when a developer does all the work for you, and presents you with working code that does something useful for UNIX geeks, why not include it? Apparently, the Evo. developers just ignore such submissions unless it fits into their view of the world.
But while we can nitpick I don't see how some of these tradeoffs are arguable.
They are absolutely arguable. The kinds of things I'm looking for, and other UNIX geeks are looking for, are things like standard X cut/paste behaviour, ubiqitous support for external editors and adherence to long-established UNIX software traditions. These are all easy to implement (in fact, some of them take effort not to implement), and have been implemented quite successfully by KDE. They also don't affect newbies who don't want or care about them -- just don't use an external editor if you don't want to, for example. Use ^C/^V if you want for cut-and-paste.
If Gnome wasn't planned right from the start to permit these kinds of things easily, then as I said before, it's badly designed.
GNOME and the way forward
Posted Aug 19, 2005 1:49 UTC (Fri) by hp (subscriber, #5220) [Link]
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.
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
Posted Aug 19, 2005 2:00 UTC (Fri) by dskoll (subscriber, #1630) [Link]
> 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
Posted Aug 20, 2005 0:52 UTC (Sat) by sandmann (subscriber, #473) [Link]
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
Posted Aug 20, 2005 3:24 UTC (Sat) by dskoll (subscriber, #1630) [Link]
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
Posted Aug 25, 2005 9:16 UTC (Thu) by k8to (subscriber, #15413) [Link]
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.
GNOME and the way forward
Posted Aug 25, 2005 13:03 UTC (Thu) by zdzichu (subscriber, #17118) [Link]
There is not need to put this preference in Evolution.
HP's "Good UI" article.
Posted Aug 18, 2005 17:38 UTC (Thu) by dskoll (subscriber, #1630) [Link]
Regarding http://ometer.com/free-software-ui.html
There's no such thing as a universally "good" UI. That's like saying yellow is a "good" colour. The only definition of a "good" UI that counts is:
A good UI lets the user get things done quickly, easily, accurately and with a minimum of fuss.
By that definition, a good UI for me is the Nirvana of a Bash prompt, whereas for others, a good UI might be Windows 3.1 (because that's what they're used to, dammit!)
So trying to design an objectively good UI is doomed to failure. The best we can do is design a UI that's "OK" by default, but that lets individual users tune it until it becomes their personal "good" UI.
The way GNOME is going, we'll all be using an OK-by-default UI without the ability to make it a good UI.
GNOME and the way forward
Posted Aug 18, 2005 3:49 UTC (Thu) by rknop (guest, #66) [Link]
The Unix way of doing things worked well in a different era, when users were clueful, systems were small
I must be from a different era.
I used to use GNOME, but I found that as it got more and more "user friendly" (or so the assertion was), it was becoming more and more "geek hostile."
As a clueful user, I found GNOME harder and harder to get configured the way I wanted to. I got sick of poring through config applets and menus trying to find the right button, I got sick of gconf making it difficult to log into two different computers that shared the same home directory at the same time, I got sick of the configuration every so often geting so screwed up that the only option I had was to remove all the dot files in my home directory, I got sick of not knowing which files to copy or edit in order to save or update my configuration.
FVWM -- FVWM is geek friendly. Configuring it is *NOT* user friendly. You have to figure out the fvwmrc file structure and edit it. But if you are good at that sort of thing... sheesh, it's so much nicer to deal with than GNOME or KDE. It does what you tell it to, it's easy to know what files to back up to preserve your configuration, it starts up really fast and doesn't run a lot of cruft, it doesn't care if you have two instances running at once sharing the config directory... and it works without pain on 550MHz (or even 266MHz) machines (which I still use, and which are getting kinda noticably slow for KDE and gnome).
As long as geek friendly stuff like FVWM ,stays around, I guess I don't really personally care what GNOME does. Except when I need something out of GNOME... for a while, I couldn't figure out how to get evolution to run without the gnome panel gratuitously starting up. And, evolution seems to want to run this data server which has gotten in the way of my keeping my calendar file synced on different computers. (I have my whole home directory in Subversion, 'cause I'm just that much of a geek.) I'd love to find something that works well enough and is lighter weight than evolution I could use... and which could import the data out of evolution, but I haven't really tried to do so yet.
I do have to admit I avoid running GNOME or KDE applications, becaues they do want to start up gconf and all sorts of other scary background processes that may not even be relevant to the program I want to run. That kind of thing... well, OK, the Unix Way may be the Old Way, but there's something to be said for not over-integrating. Just because HTTP is newer than NNTP doesn't mean that web forums are the best way to do message groups; older isn't always worse.
-Rob
GNOME and the way forward
Posted Aug 18, 2005 18:22 UTC (Thu) by tjc (guest, #137) [Link]
> FVWM -- FVWM is geek friendly. Configuring it is *NOT* user friendly.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.
GNOME and the way forward
Posted Aug 18, 2005 21:30 UTC (Thu) by evgeny (guest, #774) [Link]
> 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).
GNOME and the way forward
Posted Aug 18, 2005 7:33 UTC (Thu) by tajyrink (subscriber, #2750) [Link]
I do think I'm a geek and have been using computers for ca. 20 years. Still, GNOME's simplicity is what pleases me most of all the the graphical desktop environments I've used (including Mac OS X). It's not too simple either.. many times where the configuration options have been "missing", I've thought after a while that what's the point of actually tweaking each parameter to the maximum.. I've learned during my usage of computers that tweaking is oh-so-fun and I've had the urge to check all the settings available in all the programs before I'm satisfied. With GNOME, I can concentrate on more important things, and the dialogs and options that are shown to me are usually actually _relevant_. But maybe I'm just slowly un-geekying or something...
Then if I need to do something that requires more complicated fiddling, I just use command-line or install some less user-friendly program with more options. But it's quite rare that I find myself in that situation, so it's good that the programs I use everyday are from GNOME project.
I used to use KDE for many years and liked it a lot - but now I find it a bit strange when I look at eg. Konqueror's complex look with millions of icons, menus that overlap in functionality, four "settings" dialogs etc. And the same with many KDE programs like Amarok (which resembled me of horrible commercial Windows media players), K3B (very nice program but UI could be better), Control Center etc. KDE is _still_ very nice, but I just found that GNOME stays more neatly in the background of what I'm actually doing (work or hobby) with its clean look. Then there are things like XFCE, but I never liked CDE, and IceWM ("windows 95") etc. FVWM2 is actually quite nice to use if someone has configured it for you.
So, all in all, thank you GNOME for the good efforts! I look forward to Gnome 2.12 and Ubuntu 5.10.
This was partly an answer to the one post that mentioned that it's easier to open your mouth when you've something bad to say... without seeing that post I wouldn't have posted this as I'm mostly thinking just positively about GNOME. And then when all the people just complain, the random reader thinks that it seems that "most" people are unhappy with product X.
GNOME and the way forward
Posted Aug 18, 2005 10:42 UTC (Thu) by hensema (guest, #980) [Link]
The problem with gnome seems to be that is isn't aimed for the experienced user. They seem to be making the desktop suitable for your grandma and forget the experienced (and demanding) user.
Meanwhile gnome isn't used by your grandma. It's used by unix folk. It's used in corporations with trained personnel. Why ignore these groups?
I've always used KDE and always found it to have bad usability. Way, way too many options. However this also means KDE can actually DO what I want. KDE never has annoying focus stealing -- if you configure KDE that way. It also means KDE has lots of focus options. Too many for an inexperienced user.
But I'm experienced. I've got the hardware to compensate for bloat. I can get used to overcrowded toolbars. Why on earth would I want to run gnome?
GNOME and your grandma
Posted Aug 18, 2005 16:53 UTC (Thu) by dskoll (subscriber, #1630) [Link]
Meanwhile gnome isn't used by your grandma
A data point: My parents use Linux (because I refuse to support Windoze, even for family members.) My kids use Gnome, and my parents were horrified by its complexity. My parents are really neophytes when it comes to computers.
So my parents run Debian Sarge, with the XFCE3 desktop (XFCE4, alas, has become too Windoze/Gnomish for their tastes.) It's a nice, clean simple desktop. It does everything they need, which consists of precisely three things: Read and send e-mail (Thunderbird), Surf the web (Firefox) and do word processing (WP 5.1 for DOS in Dosemu.)
Now that's a desktop for Grandma. :-)
GNOME and your grandma
Posted Aug 18, 2005 17:49 UTC (Thu) by rknop (guest, #66) [Link]
My wife has a similar experience.
She needs to surf the internet and read email (both with Mozilla at the moment), and do some writing (with Emacs at the moment). She also listens to some online radio streams (gmplayer).
I set her up with FVWM. Works. She didn't set it up herself-- that would be asking too much. But once I set up the dock buttons and the menu items, she was good to go. And, it works well enough on her 266 MHz PC. (OpenOffice.org is a dog on that, at least starting up, but the window manager is just fine.)
I used to set up new student accounts on my machines at work with KDE, under the theory that it's enough like Windows that they will figure it out more easily. Nowadays-- FVWM. Preconfigured to do most of what they want. It's just so much cleaner and simpler and faster. It gets them going, and they'll need to be doing Unix things from the command line anyway. (You can't run IRAF from a menu-- or if you do, it opens a terminal in which to run it anyway.)
-Rob
Fork GNOME?
Posted Aug 18, 2005 10:48 UTC (Thu) by rossburton (subscriber, #7254) [Link]
Or even the option of forking the project, should that seem like the best course.
Been there, done that. Remember Gonome? That was started by people who wanted to make major changes, but the mailing list was full of people chosing a logo and nobody actually did any coding.
Fork GNOME?
Posted Aug 19, 2005 5:26 UTC (Fri) by njhurst (guest, #6022) [Link]
But it was a very nice logo, wasn't it?
GoneME?
Posted Aug 18, 2005 11:07 UTC (Thu) by BenR (guest, #30999) [Link]
I'm surprised nobody has mentioned GoneME yet: a fork of GNOME intended to take GNOME back to its UNIX Desktop roots because the founder of GoneME was dissapointed in the "average user" direction of GNOME. All that's left of GoneME now is a stub Wikipedia article and a parody. Clearly, nobody is that interested in changing GNOME's direction.
GNOME and the way forward
Posted Aug 18, 2005 14:01 UTC (Thu) by dmantione (guest, #4640) [Link]
Actually my experience with Linux newbies and KDE is that they enjoy
KDE/GNOME and the way back
Posted Aug 18, 2005 15:15 UTC (Thu) by cdmiller (subscriber, #2813) [Link]
As I type this on my AfterStep desktop I am amused. I use gnome and kde apps, but I don't run gnome or kde. Most less cluefull users I set up get an icewm desktop with a windows like theme. They just want to find their applicatoin via an icon or a menu and run it. After they discover the multiple workspaces and some X mouse behavior like middle click pasting, they tend to ask what I run and how it works. As some become more clueful they expirement with some of the other desktops available, and end up running a more "traditional UNIX" type of desktop, generally not gnome or kde, and use settings like mouse autoraise and focus. The extent of their keyboard shortcut use tends to be for cut and paste and making menu choices within their favourite set of applications. After a while they wonder why windows is so limited. I for one sit here amused at all the debate and energy over dubious features bloating the gnome and kde desktops, and the decrying of the traditional X desktop features.
GNOME and the way forward
Posted Aug 18, 2005 15:16 UTC (Thu) by tjc (guest, #137) [Link]
> Where, exactly, is the little option to get emacs key bindings?I'll like to know what happened to the option to change window managers.
Back in 1999 all one had to do to change window managers in Gnome was select an alternate from a list. Now it's 2005, and we have to open a terminal window and type something like:
This assumes that the user has already visited Computer -> Desktop Preferences -> Sessions -> Current Session and changed the metacity session from Restart => Normal so that metacity doesn't beat sawfish to the punch and restart before sawfish loads.
That's not really progress.
GNOME and the way forward
Posted Aug 18, 2005 16:30 UTC (Thu) by smoogen (subscriber, #97) [Link]
Any desktop environment is not about choice.. it is about usability for a new user. KDE makes decisions for you, GNOME makes decisions for you, AfterStep makes decisions for you... if you dont agree with those decisions there are lots of other people who may have written something that you will agree with. And you can always get someone (or spend the time yourself) to package it up for you in that way.
I have seen these arguments going on for 17+ years... how FVWM dumbed down TWM.. and how the keybindings in FVWM were superior than TWM. And then there were guys who argued that the X system was a hack of stuff they had done with ASCII in the 70's ..
GNOME and the way forward
Posted Aug 18, 2005 16:45 UTC (Thu) by tjc (guest, #137) [Link]
>Any desktop environment is not about choice.. it is about usability for anew user.Is this an agreed upon definition, or did you just make this up? I think the matter is still open for debate, and probably always will be.
GNOME and the way forward
Posted Aug 18, 2005 16:58 UTC (Thu) by dskoll (subscriber, #1630) [Link]
Any desktop environment is not about choice.. it is about usability for a new user
GNOME and KDE are approaching duopoly status, to the point where it's becoming increasingly difficult to do useful work without running at least some GNOME or KDE applications. If this forces us to lose the ability to make choices about our desktop, then we might as well abandon this silly Free Software enterprise and all use Windows.
GNOME and the way forward
Posted Aug 18, 2005 18:04 UTC (Thu) by piman (subscriber, #8957) [Link]
> [It's] becoming increasingly difficult to do useful work without running at least some GNOME or KDE applications.
Maybe that should tell you something about how much the people doing the actual work hate dealing with the non-GNOME/KDE (meaning obsolete standards, X10, unbounded configuration options, arbitrary requests to shell out to external programs -- none of which are really "Unix", IMO) way of doing things. There's not some group of developers sitting on piles of time and money going "Let's see what features we can rip from the hands of the peasants today!" There's people with limited time and resources who, largely, are writing the kind of applications they want to use themselves, and companies with limited time and resources who are writing the kind of applications people will buy.
> If this forces us to lose the ability to make choices...
You have the same option you've always had: Write your own applications, the way you want them. Are you going to deny GNOME developers the same just because they write more applications than you?
Whatever happened to "rough consensus and working code"? That's the Unix way. Write (and maintain) the code, show that there's a large enough user group to care, and if they still don't listen fork -- if you're right, you win. But empirical evidence (GoneME) would suggest that's not the case.
GNOME and the way forward
Posted Aug 18, 2005 18:30 UTC (Thu) by dskoll (subscriber, #1630) [Link]
Maybe that should tell you something about how much the people doing the actual work hate dealing with the non-GNOME/KDE (meaning obsolete standards, X10, unbounded configuration options, arbitrary requests to shell out to external programs
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.
You have the same option you've always had: Write your own applications
If I had a nickel for every time a Gnome supporter told me that, I'd be quite well off. That's the attitude I despise.
Sure, Free Software authors write software to scratch their own itch. But if they ignore feature requests that are easy to implement (heck, if they ignore patches implementing such features), then they're no better than proprietary vendors who ignore customer requests. Free Software is about a social contract, not just about technology, and if Gnome developers display the same arrogance as Microsoft, then what's the point?
GNOME and the way forward
Posted Aug 18, 2005 20:15 UTC (Thu) by piman (subscriber, #8957) [Link]
> 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
Posted Aug 18, 2005 20:30 UTC (Thu) by piman (subscriber, #8957) [Link]
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.
GNOME and the way forward
Posted Aug 19, 2005 2:17 UTC (Fri) by dskoll (subscriber, #1630) [Link]
> 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
Posted Aug 26, 2005 15:52 UTC (Fri) by mightyduck (guest, #23760) [Link]
> Do you honestly believe the GTK developers are thinking "Boy, I'd love
GNOME and the way forward
Posted Aug 19, 2005 7:44 UTC (Fri) by dvdeug (subscriber, #10998) [Link]
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
Posted Aug 18, 2005 17:03 UTC (Thu) by cortana (guest, #24596) [Link]
Try the following GConf key:
Key name: /desktop/gnome/applications/window_manager/current
Key owner: gnome
Short description: User window manager
Long description: Window manager to try first
Mind you, I don't know exactly how changing this key will interact with gnome-session's desire to restart Metacity, because I've never tried it.
GNOME and the way forward
Posted Aug 18, 2005 19:28 UTC (Thu) by bronson (subscriber, #4806) [Link]
And *this* is why noboy uses GConf. :)
GNOME and the way forward
Posted Aug 18, 2005 19:36 UTC (Thu) by dskoll (subscriber, #1630) [Link]
Still, you have to admire how faithfully they've re-invented the Windows registry.
GNOME and the way forward
Posted Aug 18, 2005 17:42 UTC (Thu) by newren (subscriber, #5160) [Link]
The gconf key /desktop/gnome-applications/window_manager/default may come in handy for you. You could also try gnome-session-remove, or editing /usr/share/gnome/default.session or /usr/share/gnome/default.wm or /usr/bin/gnome-wm.
Note also that the same issue occurs trying to run a development version of metacity, for which metacity has the --replace option in order to try to replace the current WM (so I can just run "./src/metacity --replace"). Other WMs probably have a similar option, which would probably be easier than the above; I believe being able to replace another WM is part of the EWMH freedesktop.org spec, though, and I don't know if sawfish supports that or not.
GNOME and the way forward
Posted Aug 19, 2005 1:58 UTC (Fri) by hp (subscriber, #5220) [Link]
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
Posted Aug 19, 2005 5:56 UTC (Fri) by njhurst (guest, #6022) [Link]
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!
Copyright © 2005, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds