The Grumpy Editor's GNOME 3 experience

By Jonathan Corbet
LWN.net

March 15, 2011

The early days of GNOME 2 were characterized by a relentless campaign to hunt down and eliminate any configuration options that seemed unnecessary, for a large and inclusive value of "unnecessary." Strangely enough, this move proved to be unpopular with users, with the result that, over time, many of those options were added back. GNOME 3 shows signs of wanting to repeat this history; the end result may well be about the same.

Configuration options

This all came forcibly to your editor's attention when the font used for various desktop elements (application menu and tool bars, for example) suddenly changed and became larger. That created havoc on a carefully laid-out desktop, creating scrollbars and "more bookmarks" menus where none had existed previously. Anybody who follows GNOME releases knows that there are few things this project likes better than forgetting its users' configuration selections; it was logical to assume that this had happened again, sigh heavily, and go off to fix things up. The assumption seemed valid - blinking cursors in text areas made an unwelcome reappearance at about the same time - but things turned out to be different this time.

One of the more visible changes in GNOME 3 is the new "system settings" window. This window now lacks any sort of font selection utility.  Some searching turned up others who were asking how to change their fonts in this new world; it turns out that there is an answer: go to the "universal access" section. Sure enough, "universal access" has a menu for "text size" with all of three options: "normal," "large," and "larger." Not much help for somebody who wants his old ten-point fonts back. But it seems that anybody who wants to change his fonts (beyond "larger") will have to delve into the GNOME settings registry; there is no plan to restore font selection to the interface. Why is that? Here's what your editor was told [ http://lwn.net/Articles/433414/ ]:

There's two really specific cases where having yet-another-control-panel-applet is not good: discovery of the settings that users *should* want to change and, in the support side of things, users who change the font, don't know what they've done, and then have to call to $linux_savvy_family_member or $corporate_IT_help_desk. We added the a11y mechanism to handle vision-related needs specific to fonts in a way that was simultaneously safe without requiring an entire applet.

Having wandered out of the area of "settings that users *should* want to change," your editor is out of luck. His complaints have led to a suggestion that a "smaller" option might be added, but it has not yet made an appearance as of this writing.

This sort of thinking appears throughout GNOME 3. It will no longer be possible to configure what happens when a laptop's lid is closed. The nice dialog which made it possible to restore the control key to its $DEITY-intended position is long gone; it's a good thing that xmodmap still works. Screen saver configuration seems to have gone entirely by the wayside; it's fade-to-black for everybody now. User-supplied background wallpaper can only come from the "pictures folder," the location of which evidently cannot be queried or changed; in this case it turned out to be the home directory. Evidently nobody wants to enable mouse clicking with touchpad taps anymore. And so on. That is the world GNOME is (once again) aiming for. It is, evidently, seen as an increase in usability that will bring large numbers of new users to the platform. (Update: it turns out that some of these options still exist; see the comments for their new locations.)

gnome-shell

It is in this context that your editor, with some trepidation, enabled gnome-shell on his desktop. Given the changes in the platform, the complaints about gnome-shell seen elsewhere, and some early experiences, he thoroughly expected to hate the whole thing. After two weeks of usage in the doing of real work, things have not turned out quite that way; gnome-shell is not that bad, and there are even some things to like about it. That said, there are a lot of things that could be better, and a return to the "fallback" environment is likely, at least for a while.

The initial gnome-shell experience was harsh indeed; it ran so slowly that the desktop was essentially frozen. Your editor is a fast typist, but, unreasonable person that he is, he still believes that a terminal emulator should be able to keep up with him; that was not the case when running gnome-shell. The problem, as it turns out, is the result of limitations in some Intel graphics chipsets which cannot do 3D rendering if the display width or height exceeds 2048 pixels. The system in question, running with two monitors, had such a display. Disabling the second monitor makes things work, but with an obvious cost; one might describe it as a new form of the classic time/space tradeoff.

One can argue that this particular failure is not gnome-shell's fault, but it is a consequence of the decision to require working 3D support to run gnome-shell at all. It seems likely that, as more users try GNOME 3, the number of people encountering this kind of problem will grow. Systems which work perfectly under GNOME 2 can collapse under GNOME 3. One can only hope that the detection of such systems improves in the near future; gnome-shell should simply refuse to run in such situations. The alternative - a nearly-frozen desktop - is just not the sort of Amazingly Improved Usability experience that users might have been hoping for.

Beyond that, the desktop is not quite as responsive as it was under GNOME 2; there is a perceptible delay when scrolling within windows, for example. Emacs windows get corrupted when compositing is in use; this bug has been reported for a while, but no solutions are in sight. That said, gnome-shell does offer a desktop which is visually pleasing, with nice drop shadows, zooming effects, and such. One can argue about whether it's all worth the cost, but 3D rendering is something that should work well on most Linux systems at this point. The decision to make use of hardware-accelerated 3D rendering in gnome-shell is defensible - as long as the alternatives work properly.

The GNOME 2 panels, which could be configured to appear almost anywhere on the display (your editor's laptop has a single panel running vertically on the left edge) has been replaced by a mostly featureless black bar wired to the top of the screen. Launchers as such are a thing of the past. Instead, one clicks on the "Activities" button (or simply slams the pointer into the upper left corner of the screen); in response, the desktop will zoom back yielding a display of application windows (no longer overlapping), a "dash" on the left side of the display, and a strip representing workspaces down the right side.

The "dash" looks like an application launcher panel, but it is a bit different. Its contents are the union of the applications which are currently running and the user's "favorites." Clicking on an icon will either (1) launch the application if an instance is not already running, or (2) take the user to a running instance if it exists. Getting a second browser window (say) requires right-clicking on the icon and selecting "new window." So, an operation which was previously accomplished with a single click on a panel icon now requires (1) moving to the upper right corner of the display, (2) right-clicking on an icon, and (3) selecting a menu entry - a rather longer and slower sequence of events.

It is not immediately clear this behavior is an increase in usability. The reasoning behind this change is described this way:

For many applications, such as XChat IRC, Telepathy, Evolution, Calculator, or Chess, it makes most sense to only run one instance of the application, so switching to the existing window of the application is what the user wants if the application is already running. However, in GNOME 2, the user had to know whether such application is already running before making a decision to click on a launcher to open a new window of the application. Accidentally opening a duplicate window could mean having an unnecessary extra Calculator window cluttering the desktop or signing in into IRC under a second nick. By combining the application launcher and the application switcher and making switching to the already running copy of the application the default behavior, we give the user confidence that if they just go ahead and click on the application icon, the right thing will happen.

Your editor, having been blissfully unaware of the scourge of unnecessary calculators just waiting for their opportunity to overwhelm his desktop, has not yet come to love the new way of doing things.

Happily, gnome-shell has not done away with the concept of workspaces, despite some claims that workspaces confuse inexpert users more than almost any other feature. They have become more dynamic, though, and do not really exist until windows are dragged into them. Anybody who uses workspaces heavily may come to miss the old scheme where workspaces were fixed. In your editor's world, workspace 2 is where LWN writing gets done, workspace 3 is for programming, and email is hidden in workspace 1 where it can be ignored for extended periods. Photo editing tends to happen in workspace 4, and so on. Gnome-shell makes it harder to know where everything is without having to go looking for it; one learns to be careful in the initial population of the workspaces.

Switching between workspaces involves moving the pointer to the upper left corner to zoom back, then going all the way to the right side of the display to select the workspace of interest, then clicking on a window (or hitting escape) to zoom back in - a lengthy ritual. The good news is that it is still possible to designate keystrokes for moving quickly between workspaces, so it's not necessary to do the zoom-back-and-click dance every time.

As has been discussed elsewhere, gnome-shell has done away with the "minimize" and "maximize" buttons on window titlebars. Your editor never found any use for either and, thus, does not miss them at all. On the other hand, the maximization of windows by dragging them to the top of the screen is unintuitive, surprising, and unwelcome. It's easily undone, but it's annoying.

In summary

There are a number of other weirdnesses perpetrated in the name of usability. For example, there's no "power the system off" option in sight. To turn off the system, the user must click on one's own name at the upper right and hold down the "Alt" key while the menu is visible. Clicking on one's name may be more intuitive than stopping the system with the "Start" button, but it seems a little strange and possibly narcissistic as well. Hiding a useful menu item (we all turn off our systems sometimes) behind the "Alt" key, instead, seems intended to confuse.

All of these complaints notwithstanding, it must be said that gnome-shell is not an unpleasant environment to work in most of the time. It looks nice, and most of the needed functionality is not that far away. It is also said to be designed for easy enhancement via extensions written in JavaScript; very few of these extensions exist now, but one can imagine that developers will use this capability to improve the gnome-shell experience considerably in the future.

For now, your editor will be switching back to the fallback environment so he can have his second monitor and Emacs back. But, if a properly functioning gnome-shell were the only alternative available, it would not be that bad a fate. Around GNOME 3.4 or so, when the important configuration options come back, GNOME 3 has a good chance of being a pleasant, flexible, and powerful desktop. But the road between here and there may be a little rough in spots.

(Finally, your editor would like to thank the numerous GNOME developers who have responded to his questions. We did not always agree with each other, but they were always more than willing to answer questions and to help get things working.)

Copyright 2011