There are advantages and disadvantages to running a development
distribution like Rawhide. One of those is that users often get to
experience new software well ahead of all but the most dedicated developers
and testers. Whether this feature qualifies as an
"advantage" or not will be left for the reader to determine. While
(sometimes unwelcome) bits of GNOME 3 have been slipping onto your
editor's desktop for a while, he has, thus far, avoided engaging with the
full GNOME 3 experience. Nothing
lasts forever, though, especially when it comes to development
distributions. As the features slowly drained out of the GNOME "fallback"
environment, it seemed to be the right time to jump in with both feet.
What follows are some impressions of where GNOME is going.
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.
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
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:
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.)
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
graphics chipsets which cannot do 3D rendering if the display width or
height exceeds 2048 pixels. The system in question, running with two
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
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
of Amazingly Improved Usability experience that users might have been
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.
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
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
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
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
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
to post comments)