tl;dr GNOME Classic has some polish problems, but it’s a solid desktop and a significant improvement in workflow over GNOME standard.
Over the course of a week, I’m going to be experimenting with the new GNOME Classic desktop in Fedora 19 beta. I will be recording my experiences (hopefully) daily on this blog. This series of blog entries are entirely my own opinion and do not reflect the opinions of my employer, the Fedora community or anyone besides myself (though I hope my findings will be useful to all).
As explained in my Prologue post earlier today, I switched to GNOME 3 Classic mode from KDE. I did this by running
yum install gnome-classic-session
I then logged out of KDE back into KDM and signed in, selecting GNOME Classic as the session type. My initial impression was that the new look was very reminiscent of GNOME 2. Back were the twin bars, one at the top and one at the bottom. They’d restored the ability to see active tasks on each workstation on the lower bar. I noticed immediately the circled “1” in the lower right hand corner as being an indication of an awaiting notification. This cheered me greatly, as the lack of such an indicator was one of my primary issues with the GNOME 3 “standard” implementation.
However, when I clicked on the notification icon, I discovered that the “notification” was in fact a persistent system tray icon (specifically, the krb5-auth-dialog applet). I further discovered that there is no way to “dismiss” this “notification”, because the systray is permanent. So as long as I am using an application with a system tray icon, I will always have an apparent notification awaiting (and therefore training my eye not to pay as close attention to the blue circle in the corner).
For now, I decided to simply turn off the krb5-auth-dialog indicator, since it isn’t really needed on my setup. I mostly have it installed as a reminder when I’m tinkering with SSSD to let me know if I currently have Kerberos credentials. So I decided I could live without it (especially since GNOME itself will now let me know when the credentials are nearing expiration, thanks to Gnome Online Accounts and an excellent job done by Ray Strode, Stef Walter and Ray Debarshi).
So I decided from there that I would start up my usual workloads and see how they measured up. My first stop was to start up Thunderbird, Firefox and Pidgin for my email, web browsing and IRC needs, respectively.
Uh oh. Pidgin has a persistent system tray icon as well. Ah well, so much for notification-area purity. I took a note to file an RFE to have the notification applet not include system tray icons in its count and continued on.
One of the next things I discovered as I got up to see to the call of nature was that my familiar keyboard shortcut “ctrl-alt-l” didn’t work to lock my screen. Ok, maybe that’s not the keystroke command for GNOME? I’ll just go up to the user menu in the upper right and… no “Lock” entry? That’s strange. Ok, I’ll try “Switch user”. No response?
Ok, at this point I begin to suspect that there may be some issues with Classic mode, since I’ve seen plenty of people (including myself) able to lock the screen or use fast-user switching. So I took a note to file some bugs here and resorted to just shutting down my machine instead of locking it. Thanks to a solid-state disk and systemd, my boot up is very fast anyway, and shutdown is more secure than screen-lock anyway, since I’m using disk encryption. Of course, I can’t get IRC messages during this time, but that was the trade-off at the moment. I discussed this later with some of the GNOME developers and learned that his was not a GNOME Classic issue, but a PEBKAC. It turns out that some GNOME functionality is absolutely dependent upon using GDM as the display manager that starts the desktop session. Since I had been using KDM, this functionality was lost to me. The recommended workaround was to install XScreensaver and use that to lock the screen instead. I filed an RFE asking them to add a notification at startup if the session was not launched by GDM to warn users of this lack of functionality, since it would otherwise be off-putting to the casual experimenter.
Continuing on with my investigation, I discovered that some useful features have been added to the gnome-tweak-tool (a handy tool that provides some configuration tweak settings that are not included in the basic gnome-settings dialogs). For one excellent example, the “Shell” tab in the gnome-tweak-tool now has a simple toggle button for “Workspaces only on primary monitor”, which defaults to “On”. I promptly toggled this to “Off” to see how my experience compared to when I had been doing this in GNOME 3.0 (with a difficult-to-discover gconf setting). When I had set this option in GNOME 3.0 (and possibly tried again in 3.2, but I don’t clearly recall), I had encountered many crashes and odd visual distortions when using the second monitor. I was thus very pleased that I have had absolutely no issues so far with this option in GNOME 3.8. Windows behave properly, snapping to place as expected, and even in my oddball work setup (where my secondary monitor is rotated 90 degrees for a vertical workspace), GNOME treats everything on it properly. Given this excellent experience, I opened another RFE for making this the default behavior on GNOME Classic (but probably not on GNOME standard), mostly because this behavior would be much closer to the expectation of a person transitioning from another desktop environment such as GNOME 2.
As I continued to go about my day, I discovered that I had one major problem with my workflow. When I’m at work, I mute my laptop in order to avoid annoying my fellow coworkers. However, what I discovered was that this meant I was very regularly missing summonses on IRC for various topics (and if you’re reading this and were wondering why it was taking me a half-hour or more to reply to you yesterday, this is why). The reason for this is that My general view is that if something is working forthe Pidgin IRC client uses changes to the system tray icon as the mechanism for alerting a user to pending messages and IRC “mentions”. Unfortunately, because in GNOME (both Classic and standard) the system tray icons are hidden until you go look for them, there is no indication that a message has been received. I tried using the pidgin-libnotify plugin to work around this, but that only worked for direct “/msg” pings, so that wasn’t a good enough workaround. This revealed to me a greater problem than just the waiting message-counter issue I My general view is that if something is working fordocumented above.
There are a great number of applications out there that rely on system tray icons to either provide user interaction or inform the user of important events. I understand that the GNOME people are trying to discourage this practice, as they view this as a legacy mechanism with many flaws. I’m not really going to argue this point either way. However, hiding this information strikes me more as a tactic to force your view, rather than a mechanism for convincing other upstreams to adopt it. That impression is hard to shake off. Furthermore, there are a great many applications out there that do useful work, and not all of them are going to be willing to adapt themselves (possibly writing massive amounts of changes to their notification infrastructures) just to support GNOME. It’s reasonable to assume that some of these upstreams will never adopt GNOME’s preferred signaling mechanism. In order to accomodate users that require sensible interaction with these legacy applications, I think that GNOME Classic should permit the display of these system tray applets by default somewhere on one of the two menu visible bars. I’ve opened yet another RFE for this.
This was not my only concern with notifications, either. One thing that puzzled me and I found extremely unintuitive was that when notifications appeared at the bottom of the screen, I was given only one obvious way to interact with them (out of three actual options) and it did not behave the way I intuitively would expect.
- Wait for the message to disappear, which would occur after a few seconds. This placed the message into the message tray, so I could review it again later. That’s behaving perfectly from my perspective.
- Click on the message. This would immediately change the active window to the workspace and window referenced by the alert. It would also dismiss the alert so that it does not appear in the message tray. It was not obvious that I would want to click there, but its behavior when I did was pretty much what I would want it to do.
- Click on the big (X) in the upper-right corner. This is the only obvious interaction element, and it did not do anything like I would expect it to. My natural expectation when clicking (X) would be to indicate to the message tray that “yes, I’ve seen this and don’t need to be reminded of it”. However, the effect of clicking on the (X) is merely to hasten the behavior of waiting for it to disappear. This was highly unintuitive and I filed a bug on it. The discussion on that bug and related bugs seems like no one knows exactly how to handle that, but in my experience I can certainly say that this is the wrong way. Not having a way to immediately dismiss a notification (and forcing me to go into the tray and remove it manually as an extra step) is disruptive to my workflow. I’d also like to point out that KDE had an identical bug recently that was immediately fixed in the way I’m describing here.
I have one final issue that I encountered on my first day, and that was with the behavior of “alt-tab”. The default behavior in GNOME Classic was much closer to the behavior I’d come to expect from most desktop environments, but had one significant jarring behavior. By default, alt-tab will move to the last used window, no matter what workspace it was on. This is extremely disconcerting if, for example, you just paged into a workspace and try to use “alt-tab” to find a particular window in it (which is a behavior so long coded into my muscle-memory that I expect my two year old daughter probably does this instinctually). I filed a bug recommending that we make alt-tab in GNOME Classic behave more like it did in GNOME 2. One of the upstream developers pointed me at a workaround to change a low-level setting that would have this effect. I recommended that this should be the default when using GNOME Classic. We’ll see what the decision on that becomes. At minimum, I think this option should be added to the gnome-tweak-tool.
gsettings set org.gnome.shell.window-switcher current-workspace-only true
I realize that the above sounds like a real bitch-list, and that’s somewhat the side-effect of the first day operating in a new environment. I want to say in closing that, despite the above (most of which are nitpicks, other than the notification issues I pointed out), I find GNOME Classic thus far to be a very usable and highly-enjoyable environment to work in. It offers me both the classic environment that I’m accustomed to while also offering me all the power of the GNOME Shell (including the overlay with intelligent search, which was the piece I missed the most when switching to KDE). On Day 2, I’m going to try switching my IRC client from Pidgin to Empathy to see how things behave with a more native notification mechanism.
All in all, my first impressions of GNOME Classic are actually largely positive. There are a few rough edges, but I’m giving that some leeway given that it’s effectively the 1.0 of the environment. I think if we clean up these remaining hurdles, GNOME Classic will end up being my preferred operating environment.
- https://bugzilla.gnome.org/show_bug.cgi?id=701213 – Classic: Notification icon should not count permanent systray entries
- https://bugzilla.gnome.org/show_bug.cgi?id=701212 – [RFE] Notify user that some functionality is unavailable when not using GDM
- https://bugzilla.gnome.org/show_bug.cgi?id=701217 – Classic: [RFE] Classic mode should have “Workspaces only on primary monitor” set to False by default
- https://bugzilla.gnome.org/show_bug.cgi?id=701216 – Classic: [RFE] Do not hide classic systray icons in the message-tray
- https://bugzilla.gnome.org/show_bug.cgi?id=701215 – Clicking on the X on popped up notifications should not add them to the message tray
- https://bugs.kde.org/show_bug.cgi?id=311413 – The close button on notification popup does not remove the notification from history
- https://bugzilla.gnome.org/show_bug.cgi?id=701214 – Classic: alt-tab should not switch workspaces