It is hard to be passionate about something that everyone does! I was reminded of this by a blog about a survey, which found the WebOS users as the most passionate about their platform.
This isn’t surprising, because if you are going to buy a product used by a small minority, you are likely to be passionate about it. So, it is nice that Ubuntu is bringing some competition and passion into the desktop world, by differing from the standard GNOME desktop. The difference may be only skin-deep, but it is the skin that users see. There are, however, differences in applets and extensions.
Unity on Ubuntu 11.04
The Unity interface of Ubuntu 11.04 was not a surprise; I have been using it with the Ubuntu 10.10 Netbook Edition. On the desktop, unlike on the netbook, the application did not start with a maximised window. The Unity interface uses the “global menu” — i.e., the menu bar for the active window is displayed in the top panel. On the netbook, in particular, this is very attractive since it saves vertical space. However, I love the KDE Plasma Netbook interface even more, as it removes the title bar and hides the panel.
There was a slight surprise when I used 11.04 on the netbook (where applications typically start maximised). However, unlike on Ubuntu 10.10, the dock slides out of the window and hides, making more space available for the active window. The window manager decides on the policy by examining the screen resolution, and there is no separate netbook/desktop option in the GDM menu. In case the hardware does not support 3D effects, Unity falls back to the traditional GNOME desktop.
Behind the scenes, though, there is a major change. The earlier version of Unity used Mutter as a compositing window manager; Ubuntu has switched to using Compiz instead. In case the hardware does not support Compiz, the desktop falls back to the GNOME panels.
GNOME Shell on Arch Linux and Fedora 15
Unlike the Ubuntu Unity interface, the first reaction to GNOME Shell was negative. The panel showed, and the rest of the screen was blank. I waited for something more to happen, but that was it. So, about the only thing that made sense was to click on “Activities” — and then the few preselected favourite applications showed up. You can find some details about the GNOME Shell design here.
The dock for favourites and active applications is not very different from Unity. You can search for an application and add it to Favourites, or start an application and keep it in Favourites. As more applications are added, the size of the icons decreases. It does keep a sanity check on the minimum size, though the small size could get to be too small, especially if you are using a touchscreen.
In the case of Unity, the size of the icons remains fixed, but you can scroll and select an icon. In Unity, there is a small arrow on the left to indicate that an application is running. An arrow on the right indicates that it is the active application. Clicking an icon makes the application active — starting it, if necessary.
In GNOME Shell, there is no difference between the icons of running applications and favourite applications. Clicking on Activities displays images of the available windows, and you click one to activate it. The differences are cosmetic, and I do not believe anyone would find either one hard to use. However, if you are used to one, you will find the other a little disconcerting, at first.
At present, there aren’t any convenient utilities for customising GNOME Shell. The Arch Linux wiki page is a very good starting point for what you may wish to do. I found out how to reduce the size of the excessively fat title bars in this wiki. In case the hardware does not support the Mutter window manager, there is a fallback mode, which is similar to the GNOME 2 panels.
What about all the little System Tray, oops, Notification Area icons?
Frankly, I had never paid much attention to the icons in the GNOME panel’s notification area. Of course, they were useful. They provided easy access to connect to a wireless/3G network, made it easy to control the volume, and provided a minimal interface to pause music, replay the previous track or skip the current one.
Like any good thing, though, you were afflicted with far too many of them. GNOME had switched from a single panel to two of them, to accommodate all you may want to access easily on the panel. Ubuntu switched back to one, particularly for the smaller netbook interfaces. Ubuntu also introduced indicator applets to consolidate some of the applications using the notification area, under a common icon.
GNOME Shell has a hidden panel (a message tray) at the bottom, for some of the icons that would have been in the notification area. As I tried to figure out what happened to various icons that used to end up in the notification area, I was reminded of a scene in Five Easy Pieces, in which Jack Nicholson wants bread, but the restaurant does not have bread on the menu. So he orders a chicken sandwich, and asks the waitress to hold the chicken, the mayonnaise, the lettuce…
This scene certainly reflected my frustration at trying to cope with solutions that, at least to me, do not seem simpler or more intuitive. I can certainly assert that my mother would not be able to use them, and I wasn’t comfortable with them either — and all this fuss over a feature that’s quite incidental. I must be missing something.
You may search for the controversies around libappindicator as used in Unity. (A few links: blogs.gnome.org, aseigo.blogspot.com.)
The comments in this Telepathy ticket make for interesting reading, to get a perspective from the application’s developers. This conversation about the Ayatana project bringing the Unity interface to openSUSE 11.4, and the notification area protocol of GNOME Shell, may also be of interest.
Back to Notification Area icons
One group that will not be supported by GNOME Shell or Unity are the GNOME Panel applets. GNOME 3 will provide a way to migrate the applets to GNOME 3; however, they will only be available in the fall-back mode.
The next group is user applications that minimise to the notification area. These are expected to use the desktop notification specifications. KDE4’s notification system also supports them.
The applications may also be using the “Status Tray Protocol” specifications implemented by GNOME 2 and KDE. These specifications use X11 protocols and do not use DBUS, and are not supposed to be used in GNOME 3 — though they seem to be available in the message tray as legacy Xembed notification icons.
Unity wants applications to use appindicator, which implements the DBUS status notifier specification, also used by KDE 4. Unity includes the system tray only for a few specific applications via a “white-list”. You can use the command gsettings to enable the notification area for all applications.
The last group is system applets like NetworkManager or Volume Control. These are expected to be managed by the desktop manager. In both GNOME Shell and Unity, they continue to appear in the panel; GNOME Shell uses JavaScript to make this happen. You may wish to explore /usr/share/gnome-shell/js/ui/panel.js to know more about the fixed status icons.
For GNOME Shell to treat system applets differently from applets that use the message tray, bothers me. You should not have to think whether it is a system icon or an application icon, and then look in the appropriate area. Once the network is working, why do you need the icon to be visible? In fact, if some icons do not need to be always visible, I would have voted for the system icons to be out of sight.
GNOME Shell Extensions, Unity Indicators
One of the ways in which GNOME desktop functionality got extended was with GNOME Panel applets. However, GNOME Panel is not used by either GNOME Shell or Unity — and neither has support, or plans for supporting panel applets. However, GNOME Panel is used by both GNOME Shell and Unity in the fallback mode. Also, GNOME Panel for GNOME 3 is being modified substantially. So, are applets going to be obsolete? It makes no sense to develop or maintain even small applications, if they are to be used only in the fallback mode.
A major change in GNOME Shell is the introduction of extensions written in JavaScript, which are much better integrated with the Shell than GNOME applets. A fair number of extensions have been developed: e.g., to add the Places menu and a dock which remains visible. At least at present, it does not seem as if the GNOME Shell extensions will run on Unity — but then, they will not run in the fallback mode of GNOME Shell either. Furthermore, the WebOS example indicates that the use of JavaScript to write extensions does not necessarily guarantee success.
It took some time for KDE4 to settle. The same is undoubtedly going to be the case for Unity and GNOME Shell. You can look forward to Unity on GNOME 3 and, most likely, someone will bring Unity indicators to GNOME Shell using Javascript extensions.
