systemd comparison with GNOME 3 is slightly unfair

Posted Jun 21, 2011 21:55 UTC (Tue) by mjg59 (subscriber, #23239)
In reply to: systemd comparison with GNOME 3 is slightly unfair by paulj
Parent article: Fedora, systemd, and changes

What's ridiculous about this discussion is that the feature's no more broken than it has been in any other release of Gnome for 5 years. There's been no deliberate attempt to break it. It's been missing from the UI for a long time. It's never worked properly with applications with custom text widgets. It's only ever worked in Firefox (which is not written by Gnome developers) if you install an extension. Even when it does work properly it means that your shortcuts do wildly different things depending on which widget has focus. And, of course, your emacs keybindings still work absolutely fine in console applications and emacs itself. Have people really been using these bindings heavily in their daily activities? If so, in which applications?

systemd comparison with GNOME 3 is slightly unfair

Posted Jun 22, 2011 6:03 UTC (Wed) by paulj (subscriber, #341) [Link] (11 responses)

I use emacs keybindings in my browser all the time, ctrl-e & a especially.

However, my comment wasn't about emacs keybindings particularly.

systemd comparison with GNOME 3 is slightly unfair

Posted Jun 22, 2011 14:39 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (10 responses)

Which means that "Select all" suddenly no longer works, despite it being logically useful in a text entry widget. I appreciate that that's a tradeoff you might be willing to make, but having this as exposed UI without having a logical mechanism for handling colliding shortcuts is just a bad idea. You can still enable the functionality via dconf, and it still works as well as it ever did. As far as I can tell, nothing has changed regarding emacs key shortcuts other than that the configuration isn't automatically carried over from gconf to dconf. Yet people insist on using it as a basis for criticism of the Gnome 3 development effort. What is actually going on here?

systemd comparison with GNOME 3 is slightly unfair

Posted Jun 22, 2011 15:08 UTC (Wed) by paulj (subscriber, #341) [Link] (9 responses)

mjg59, it seems you're entirely missing the point of my comment. Note the use: "The emacs-keybinding minority" - it's being used as a label for a certain group of people, simply because emacs-keybindings came up earlier here. The comment you're replying to has otherwise nothing to do with the technical merits or problems of it - indeed, I would readily accept that ctrl+a has a better established meaning to a much larger group of users.

The comment was actually about which users GNOME is trying to appeal to, and possible other reasons why they have failed to attract that group.

(As an aside, the few younger Linux desktop users that I know of seem all to have eschewed GNOME entirely and are using much more esoteric setups (xmonad, etc) than the few older, grumpier Linux desktop users here - who use GNOME. Anecdotal / very limited data-set though, of course).

systemd comparison with GNOME 3 is slightly unfair

Posted Jun 22, 2011 15:28 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (8 responses)

I know. I just don't understand it. Nothing has changed for the emacs-keybindings people (and I was one for some years). They're no more or less catered to than they were in most releases of Gnome 2. Using it as a shorthand for a specific set of users who now feel marginalised doesn't help anyone understand what the causes of those feelings are.

systemd comparison with GNOME 3 is slightly unfair

Posted Jun 22, 2011 15:52 UTC (Wed) by paulj (subscriber, #341) [Link] (5 responses)

Ah ok. I also mentioned the focus-follows-mouse burial (which could be an unofficial deprecation), is there a good technical reason for that? What about the impossibility of being able to add/remove icons from the panel bar? (Strangely, this *is* possible by loading in extension code to your shell: i.e. simple, controlled user-modifications are gone, but more sophisticated modifications that can greatly impact on the UX feel and stability are encouraged? Though, the API for this is unversioned and still in flux?)

systemd comparison with GNOME 3 is slightly unfair

Posted Jun 22, 2011 16:25 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (4 responses)

I should make it clear that while I work with Gnome developers fairly regularly, I'm not really involved in Gnome development these days so anything I say should be interpreted as my impression rather than any kind of canonical truth. With that said:

Modern desktops are pretty different to the traditional X11 environment. For a bunch of reasons (including an increased number of situations in which applications need passwords, websites that pop up timeout windows on idle sessions, a wider range of things that provide notifications) it's now far more likely that a window of some description may appear under your mouse. It's not clear what the right thing to do in that situation is, and most of the traditional approaches can result in awkwardnesses like you suddenly typing your password into an IM client. Getting this right is important, and if it's something you provide in a visible UI then you have to be sure that you can get it right - exposed options shouldn't work for the 99% case and be pathological in the 1% case.

Having said that, while I don't think focus-follows-mouse is a high priority for people right now, I'd be kind of surprised if we don't see a certain degree of what happened between Gnome 2.0 and 2.2. Some features that vanished were reworked to an acceptable level and reappeared again. In this case I think if someone were willing to work through the problems inherent in focus-follows-mouse and come up with an implementation that doesn't utterly fail in awkward corner cases then that would stand a good chance of integration in some form. Again, not speaking for the developers or designers or anything.

The panel bar stuff is (as far as I understand it) a deliberate design decision rather than a technical limitation. Having it be modifiable via extensions is intended to indicate that you're deliberately diverging from the intended environment, and as a result things may behave slightly differently and if so that's your problem rather than upstream's problem. But yes, the extensions API is still unfinished. I think the aim is for it to be considered stable in the 3.2 timeframe.

systemd comparison with GNOME 3 is slightly unfair

Posted Jun 22, 2011 17:17 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> For a bunch of reasons (including an increased number of situations in which applications need passwords, websites that pop up timeout windows on idle sessions, a wider range of things that provide notifications) it's now far more likely that a window of some description may appear under your mouse. It's not clear what the right thing to do in that situation is, and most of the traditional approaches can result in awkwardnesses like you suddenly typing your password into an IM client.

I solve this by having it so that no window can *ever* steal keyboard focus (the exception is if the currently focused window disappears, but with tiling, it is usually pretty apparent from the windows changing for the new geometry). I use sloppy focus and one of the things that I did not like about GNOME 2's (CentOS 5.6) FFM implementation is that it will change focus if the mouse moves over a window some minimum distance (though not if it's stationary) where I'm used to it only happening when crossing into a window across one of its borders and click-to-focus was the better choice. I could see where if the previous behavior was kept, this problem would happen, but if better focus stealing prevention existed (even just "Default", "When different application", or "Never") or sloppy focus were used, it wouldn't be that much of an issue.

systemd comparison with GNOME 3 is slightly unfair

Posted Jun 22, 2011 21:26 UTC (Wed) by paulj (subscriber, #341) [Link] (2 responses)

Re password stealing, yes that's a massive concern. If a WM lets random apps paint over arbitrary windows - other than perhaps children - and steal focus without user-acknowledgement, that doesn't seem a sensible WM. Old school WMs used to require that the user explicitly place new windows with a click - which avoided the problem of focus being stolen unawares. So it's perhaps not right to say FFS is a security risk of itself, and it seems more a problem of WM window placement policy and/or how/when new windows are given focus that should be addressed, and probably regardless of focus policy. (However, this is far from my area of expertise ;) ).

Re the panel bar, if that's a temporarily missing feature, does that seem like good release engineering to you? We've seen since this "Ah, but that will be added back later" intent before, e.g. GDM and the configuration tool for it, but I bet there are more examples. It turns out that intentions don't always result in code.

OTOH, if it's a deliberate design decision then I remain confused at how GNOME 3 aims for consistence while effectively encouraging massive code divergence amongst its users!

systemd comparison with GNOME 3 is slightly unfair

Posted Jun 22, 2011 21:35 UTC (Wed) by me@jasonclinton.com (subscriber, #52701) [Link]

Re the panel bar, if that's a temporarily missing feature, does that seem like good release engineering to you? We've seen since this "Ah, but that will be added back later" intent before, e.g. GDM and the configuration tool for it, but I bet there are more examples. It turns out that intentions don't always result in code.

OTOH, if it's a deliberate design decision then I remain confused at how GNOME 3 aims for consistence while effectively encouraging massive code divergence amongst its users!

It's the later case. Like people who install Firefox extensions, installing a GNOME Shell extension should be the kind of activity that is well understood as being essentially unlimited in its power to change everything, is the kind of activity which can not be accidentally activated, and has the benefit of being undo-able by simply disabling the extension in the UI for extensions. At least, that's the broad plan. We'll see what makes it in for 3.2.

systemd comparison with GNOME 3 is slightly unfair

Posted Jun 22, 2011 21:40 UTC (Wed) by marcH (subscriber, #57642) [Link]

> We've seen since this "Ah, but that will be added back later" intent before, e.g. GDM and the configuration tool for it,

Aaaahh... the "great GDM rewrite", one of the best free software stories ever. Glad you mentioned it

https://bugzilla.redhat.com/show_bug.cgi?id=433649

systemd comparison with GNOME 3 is slightly unfair

Posted Jun 24, 2011 17:29 UTC (Fri) by rwmj (subscriber, #5474) [Link] (1 responses)

You're actually wrong about emacs keybindings too. They DID work fine for me in GNOME 2 and Firefox under GNOME 2 without any extensions.

Loss of emacs keybindings is very annoying, and sadly it's something that my move to XFCE can't fix.

systemd comparison with GNOME 3 is slightly unfair

Posted Jun 24, 2011 18:10 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

They work precisely as well under 3 as they did under 2, in rawhide at least.