One Week With GNOME 3 Classic: Day Three (Coarse Correction)

(That’s a pun in the title, not a typo)

Home, Home on the Range

Today marked my first work-from-home day since I started this little experiment. Working from home is notable insofar as it means that there is a period of time after login before I have access to my internal work network. This is relevant because I am logged into both internal and external IRC servers at all times during my workday. However, since I’m not on the internal network until I fire up the VPN and perform the dark and secretive rites necessary to authenticate to it, there’s a period of time where access to internal features will be unavailable.

What I discovered this morning is that Empathy will attempt to sign me into all of the configured services immediately upon login. Because there are services that are unreachable, it means that at login time I’m essentially struck in the face by a series of messages about how my services are unreachable or there has been an error, etc. This is somewhat annoying, so I went looking for the Empathy preferences. Oh hey, what do you know. There are two applications that hide their option menus in the application name in the top bar. I probably wouldn’t have thought to check there if not for the situation with Software yesterday, but at least I found it.

Perfect, there’s an option “Automatically connect on startup” and it’s checked “on” by default. I’ll just uncheck that and reboot to test it… Why am I still getting error notifications at startup? Hmm, it appears that Empathy doesn’t actually honor this option. I guess I’ll file a bug on that.

After having spent all of yesterday with Empathy as my IRC client, I had pretty much decided that it wasn’t for me. It had too little opportunity to configure it the way I wanted to and was just missing some of the niceties I had come to expect from Pidgin, like being able to assign aliases to channel names so I could tell apart channels named the same on different IRC servers. Adam Williamson had suggested trying out XChat in a comment on one of the earlier posts in this series, to I took his recommendation and converted my IRC usage over to XChat-GNOME.

The first thing I noticed was that XChat-GNOME was producing a lot of noise that was hard to sift through. A quick query lead to Kashyap Chamarthy teaching me about

/set irc_conf_mode on
/gui apply

This option eliminated most of the noise of the constant join/part messages. I’m still looking for a way to clear out the nick changes, though. Comments welcome below.

I looked into the preferences and found remarkably few knobs to turn. However, when I dug into the preferences file I found several options related to highlighting that improved my situation. I took a look at the regular XChat as opposed to the XChat-GNOME variant and found that it was significantly more configurable, but that since 99% of my needs were being met by XChat-GNOME, I would stick with it for the time being.

I decided to stick with Empathy for my non-IRC connections, since all of those are available on either side of the firewall and I can probably live with those occasionally throwing me an error if I start up without any connection at all (at least until that bug is fixed).

I found XChat-GNOME to be a significant improvement over Empathy for pretty much every aspect of IRC life, so even when the autostart bug is fixed, I will probably stick with XChat-GNOME. So far, I still think Pidgin provided a better all-around experience (and access to all of the protocols in a single application), but since its notifications do not jive with GNOME at this point (and I can’t find any Pidgin plugin that alleviates this for IRC, only for direct messages), as long as I’m functioning in the GNOME environment, I will be forced to settle for other tools. That being said, the combination of XChat-GNOME for IRC and Empathy for Google Talk, AIM, etc. is sufficient for my day-to-day use without any real complaints. (Except for those nick-change notifications. Any tips?)

As a general rule, I disconnect myself from my workstation over the weekend to spend time with my family, so this series will be on hiatus until Monday, where I will hopefully find time to update it with further musings. Thank you once again for reading.


  1. does not honor disabled “Automatically connect on startup”

One Week With GNOME 3 Classic: Day Two (Reorientation)


After my experience on Day One, I decided to make two significant changes to my working environment in order to adapt to the GNOME Way. Despite many years of using Pidgin as my primary communications application (since way back when it was still called gAIM… get off my lawn), I decided that the lack of notification availability was a significant detriment to my ability to get things done in my day job, so I bid it a tearful farewell and started looking for an alternative.

I settled on Empathy, because at first glance it was offering me the most complete replacement. It has support for connecting to multiple communication protocols, including Google Talk, AOL Instant Messenger (believe it or not, some of my contacts still use this) and Facebook Messenger. So I configured all of my services and tried it out.

The first problem that I encountered with Empathy was that it failed to recognize my Google Apps hosted domain name for Google Talk. It failed attempting to find the appropriate server. (TODO: file a bug and add it here). Oh well, being reasonably tech-savvy, I added Google Talk as a standard Jabber account and it worked fine after that.

The second issue I encountered with Empathy was that I could not exit it. When I selected “Quit” from the file menu, nothing happened. I was able to exit all IRC rooms by closing the window containing all of my tabs, but Empathy continued to run in the background. Furthermore, if I tried to kill it with fire the ‘kill’ command, some process somewhere started it right back up again in the background. My assumption here is that some part of the Empathy subsystem must be necessary to GNOME Shell, so I decided to just shrug it off.

For the most part, Empathy worked reasonably well as an IRC client. I missed a few nice features from Pidgin (namely the ability to have it notify me of certain keywords, not just my name), but on the whole it appeared to be a mostly acceptable solution. I went through my day without any particular complaints.

Throw Away the Key

The other major change I settled on yesterday was switching my window manager from KDM to GDM, in order to address the other serious limitation that I had faced on Day One: the inability to lock my screen. After a quick Google search, I was reminded that there is a handy package in Fedora by the name of ‘system-switch-displaymanager’ (and the GNOME variant, ‘system-switch-displaymanager-gnome’). I installed the GNOME variant through GNOME’s “Software” application, which then prompted me to run it immediately if I wished (I did). I was presented with a very simple interface with a radio button allowing me to select between KDM and GDM (the two display managers I had installed). I did this, and it informed me that it was switched, but that I’d need to restart the X server for it to take effect. I opted for a full system reboot (after running a set of available updates).

When the system had come back up, I was presented with a new login screen that was largely unimpressive. My username was on display in the middle of the screen, the Fedora logo appeared at the bottom and everything just floated in a sea of uninteresting grey. Now, I realize that most people don’t spend much time staring at their login screen (unless of course they have forgotten their password or the authentication server is down), but at the same time the screen is so bleak that I can’t help feeling like a new user who saw this as their first greeting would similarly expect the rest of the Fedora experience to be similarly bland and tasteless.

I went ahead and logged in, of course. The very first thing I tested was whether I could immediately lock my screen. This worked, and I was pleased to discover a small but meaningful change in the lock screen. In GNOME 3.6, where the gnome-shell-based lock screen made its debut, one needed to either drag the window shade upwards with the mouse or else strike the “esc” key (which was not visually indicated) in order to be able to start entering the password. As of GNOME 3.8, you can simply start typing and this will trigger the window shade to get out of the way. This also allows me to return to my classic (admittedly oddball) mechanism of starting to type my password by hitting backspace a couple times, in case I had accidentally hit the keyboard previously.

With the lock screen validated, I went to look for the “Switch User” option, but it was no longer there. It seems that when I logged in with GDM, it detected that mine was the only active user on the system and did not give me this opportunity. While this is interesting on a single-user system, it’s a bit puzzling that it should behave this way on a system that is joined with a central identity store (such as mine is to an LDAP server). The workaround here is to lock the screen, then select “Log in as another user” from there. I have not bothered to report this as a bug because it really is an edge case. It would only be an issue for the second user attempting to use the machine, after which the option would be there.

My Daily Nitpick

Making Space In my Head

Throughout this second day, I had very little trouble to report. This is a good sign. I encountered only two problems (one of which I had mentioned as a problem with GNOME 3 since its inception in my Prologue entry). Specifically, it takes some time to adapt from my traditional horizontal workspace arrangement (which in KDE or GNOME 2 could also be a two-dimensional grid) to the strict vertical arrangement of GNOME 3.

I mentioned it in passing in the Prologue, but the vertical arrangement of workspaces is more of an issue to the “feel” of the environment than it should be at first glance. It does what it’s supposed to do, and the keyboard shortcuts that control it behave in alignment with their horizontal counterparts (ctrl-alt-left/right becomes ctrl-alt-up/down, sensibly). But it doesn’t line up with the way my brain is wired to process things. This is my own interpretation, backed by my own philosophy and absolutely zero user-experience design work, but to me it seems like the human mind and eyes are designed very explicitly to perceive the universe more or less along a single plane.

Putting on my (extremely) amateur anthropologist hat, throughout history, human beings have largely evolved to deal with other land-based threats. Barring certain legends about rocs, griffins, dragons and Sarlacc pits, humanity has never faced a consistent predator that attacked from the sky or the earth beneath their feet. As a result, our eyesight was designed around providing us with a much larger view of our periphery than of above and below us (approximately 1.6 times larger, following the so-called golden ratio). I attribute this basic understanding of the world to why it feels so unexpectedly alien to be shifting up and down to get access to additional work in my workspace.

Ultimately, this is something that I know I will adjust to. I did so when I switched to GNOME 3 the first time. However, I remember that it took me almost a month to adapt to thinking about my environment that way in the first place, and then when I switched away again to Cinnamon and then KDE, I took to returning to the horizontal placement immediately. It just came more natural to me. I don’t know how much of this can be attributed to natural tendency versus many years of conditioning, but I know that it did not go unnoticed.

“Software” is an Adolescent Joke

The other nitpick I encountered yesterday was when I went to use the “Software” tool in GNOME. I’m not sure where exactly to begin with it, but it is perhaps the most poorly designed tool (from a user-experience point of view) that I have ever used. And I’ve used Oracle products.

To begin with, the application presents the user with a single window with a search box, a frame containing a set of collections and a larger frame containing an enormous set of options with check-boxes. Scanning through these hundreds of choices is daunting, and the search box is only useful if you already know what it is you are looking for.

Furthermore, there is no immediately visible way to configure the Software tool. I had to ask someone and be told that, unlike nearly every other application on the system, the options for the Software tool were hidden in a menu under the application name in the top bar. While I recognize this as a standard practice in OSX, it’s such a jarring discontinuity from the rest of the Fedora operating system that it makes no sense whatsoever.

The first thing I tried to find in the options menu was a way to configure it similarly to Apper from KDE (which I love). Specifically, I wanted to have it automatically download all of the packages that I would want for updates and then tell me about it so that I could update them at a time of my choosing. No such luck: with the Software tool, it is apparently all or nothing. I noticed that occasionally my user menu would grow another option underneath it that read “Reboot and install updates”, which I assume is probably accomplishing this behavior, but I have no real way to verify that.

The second thing I wanted to do with Software was configure it to automatically install security updates immediately. No such luck, it’s all or nothing.

Finally, I went to “Check for Updates” which unexpectedly launched a new window of bizarre proportions. It filled my entire screen from top to bottom, but only about one-fourth of the width. Moreover, it offered a truly bizarre layout. I could resize the window in either direction, but the only pane that would grow larger was the one listing the set of packages to be installed. Meanwhile, the “Details” pane remained locked at two lines wide, meaning that for packages that bothered to write decent update notes (which is a different issue for another blog post sometime), it was an extremely painful chore to attempt to read them.

All in all, the Software application experience is one that I would like to forget and I can only hope that the GNOME folks are planning to significantly overhaul it in the near future. As it is, I will not be using it and will stick to Apper if I want a graphical interface with decent searching or the basic yum command-line if I already know what I need.


Yesterday was an adjustment period. On Day One I had identified what I saw as major problems and yesterday I set about finding workarounds to them. I don’t love that I was forced out of my comfort zone in order to find applications that worked more cleanly in GNOME Classic, but I’m willing to explore my options. Perhaps I’ll find something I like better. Time (and the next installation of this series) will tell.

One Week With GNOME 3 Classic: Day One (Paradigm Shift)

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[1], 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.

  1. 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.
  2. 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.
  3. 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 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.


  2. Notification icon should not count permanent systray entries
  3. – [RFE] Notify user that some functionality is unavailable when not using GDM
  4. [RFE] Classic mode should have “Workspaces only on primary monitor” set to False by default
  5. [RFE] Do not hide classic systray icons in the message-tray
  6. Clicking on the X on popped up notifications should not add them to the message tray
  7. – The close button on notification popup does not remove the notification from history
  8. alt-tab should not switch workspaces

One Week With GNOME 3 Classic: Prologue

Over the next 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 first post will be mainly to identify my use-cases and history with desktops. 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).

I am a fickle user. As a general rule, I don’t tie myself to one particular brand when choosing my tools. Throughout the years, I’ve used a variety of desktop environments for doing work. Let’s go through the last six years of my desktop use.

Six years ago, I was a very happy user of the KDE 3 desktop environment. While sgallaghit was maybe not the fastest, prettiest desktop environment on the market, it was stable and customizable and over the previous two or three years I had turned it into a lean, mean workstation. Then, in 2008, KDE 4 landed on Fedora and my workflow was stood on its head. I tried to love it, I gave it about six months and a new Fedora releases with 4.1 before I finally decided that KDE, while getting better over time, was just not the right desktop for me.

Around the summer of 2008, which coincides with my employment at Red Hat, I switched over to GNOME 2 (which a quick Wikipedia search reminds me was GNOME 2.22). I found that I missed having access to some of the customizability options that KDE 3 had provided to me, but for the most part the defaults were acceptable to me (minus the top-and-bottom system panels; I removed the one at the top to get back a few pixels).

While I was never as much in love with GNOME 2 as I was with KDE 3, I found it to be a good fit for my workflow. It had excellent virtual workspace support (I could set up the number of workspaces that I wanted, label them and move between them very quickly). It was clean and largely uncluttered (minus the extra panel that I removed) and generally got out of my way and allowed me to work with the applications that I preferred. I stuck with GNOME 2 as my exclusive desktop from 2008 through 2011 and I don’t have any regrets. While I kept an eye on KDE 4 and acknowledged that over time it had evolved much further intosgallagh

In 2011, GNOME 3.0 was released, and I had flashbacks to KDE 4.0. My first impression of GNOME 3.0 was that it was trying too hard to decide for me what choices I should be making. For example, it took away my choice to use a panel at the bottom of the screen instead of the top. This was a purely aesthetic change, but one that irked me. Beyond that, the designers threw away a decade of workspace workflow and took away my fixed workspace arrangement and replaced it with dynamically-created ones. It broke my muscle-memory by forcing vertically-aligned workspaces, where I preferred horizontally-aligned ones (side-note: I don’t have research to back this up, but it’s always felt more natural to me that humans, like other animals, tend to process information on either side of their view more instinctually than that which is above or below).

The two most serious problems that I encountered in GNOME 3 were with message notifications and with multi-monitor support. Now that I was working at Red Hat, my daily workflow necessitated very heavy use of IRC to communicate with my team members and other upstream communities. The client that I was using however did not use the libnotify mechanism for alerting the user of waiting messages, but instead changed the system tray icon to indicate it.

Multi-monitor support was the other case with which I experienced problems. I traditionally use a laptop with an attached monitor (at work, I attach a smaller secondary monitor that I use as “extra space”; at home I attach a much larger monitor and use it as the primary source). With GNOME 3, the default behavior of multi-monitor support was to enable changing workspaces only on the primary monitor, which meant that the other monitor was always fixed in place. Since I have a different multi-monitor configuration at home and at work, this meant being forced to constantly switch which monitor was treated as primary, and I still didn’t have the opportunity to use all of my screen real-estate on each workspace.

I found a hidden option that enabled workspaces on all monitors, but as of GNOME 3.0 it was thoroughly broken and caused a lot of crashes (which I was told by the GNOME developers they weren’t going to look at, since it wasn’t a supported configuration), so I was forced to revert.

At this point, as a Red Hat employee, I decided to give GNOME 3 more time to get on its feet (and to do my part to try to help it there), so I stuck with it and filed bugs, went to the Gnome Summit to discuss it, etc. It took a couple months, but I was finally able to adapt my workflow to more-or-less work with the “GNOME Way” (this amounted to dedicating my second, non-primary monitor to always displaying my IRC program, since that was the only way I would be able to get updates when I was being pinged).

I stuck with GNOME 3 through 3.0, 3.2, 3.4 and 3.6, but I began to be disheartened. Each release came and went and GNOME upstream continued to ignore (or fail to improve upon) the two most serious user experience problems (as described above). I got disheartened, and decided to explore some of the other options in Fedora. I spent a couple weeks with Cinnamon, which I found to be fairly decent, but lacked polish. I then decided to switch back to KDE to see if the previous few years had been good to them.

I discovered – to my delight – that they had indeed. KDE had become a very solid, stable platform with none of the instability or jarring UI that had plagued it at the beginning. After tweaking one or two things (a few preferred keyboard shortcuts, mainly), I settled into using KDE for my primary desktop environment. That was a few months ago (on Fedora 18), and I continue to believe that KDE is a very strong choice and should be seriously considered by any individual using Fedora to do serious development work.

One of the major new features of Fedora 19 is a modified version of GNOME 3 – supported by the GNOME upstream, unlike Cinnamon – intended to address some of the concerns that the GNOME 3 user experience is too much of a departure for users of classic desktop environments to latch onto. Now that Fedora 19 is in beta and GNOME Classic mode is basically ready (in what I will treat as its 1.0 release), I decided that it was my duty to the open-source community to explore this new variant and give it a complete investigation. To this end, I have decided to use it as my exclusive desktop for at least a week and document my experiences each day. I began this undertaking yesterday, and my first day’s summary will follow shortly.

Well, this prologue has now grown to a prodigious length (over 1200 words), so I think I’ll stop here and move on to documenting yesterday’s and today’s experiences. If you have read this far, thank you. Give yourself a pat on the back.

EDIT (2013-06-06): Hello Slashdot!

I notice from the Slashdot comments that not everyone is aware of the other articles in this series, so here’s a Table of Contents for the rest of them: