The site uses cookies that you may not want. Continued use means acceptance. For more information see our privacy policy.

Criticisms for the GNOME Shell

A look at the few things that bug me about GNOME Shell.

GNOME Shell gets a lot of flack from people that wish it was more like GNOME 2.x series, ranging from lamenting the difference to disgruntled rants that it’s a ruinous step towards Armageddon.

I’ve been using GNOME Shell since 3.x landed on Debian, and I enjoy it. But there are some things I don’t like about it (very few). Some of them are my own lack of relearning the desktop, failure to install appropriate extensions, etc.

Messaging Tray

This is my least favorite thing about the Shell. The Messaging tray is the area at the bottom of the screen that lets notifications be added, while sometimes acting like the old tray area where applications can add icons.

The problem is that it’s auto-hidden, which wouldn’t be a problem except for the fact that it’s way too shy. I believe in recent versions it’s better, in that it will pop-up and stick around, but it’s still difficult to open if you’re on multiple monitors with the Shell on the left monitor. I run my mouse down, and miss it several times before getting it to show.

There’s supposed to be a kind of hidden bump at the top and bottom right, but those are both ineffective and annoying (ie, they don’t work when I want them to and do work when I don’t want them to).

Snapping Windows

Another feature of the Shell is snapping windows to three places: left-screen and right-screen both take up half of the screen when snapped. This is a kind of easy-tile system where you can have two windows side-by-side. The third snap is maximizing a window on the current screen.

I almost never use any of these on purpose, but do run into them accidentally more often than I’d like. This is especially common with the top-right mouse trap.

Multiple Desktops

My main complaint here is that it’s a pain in the ass to use multiple desktops. I either have to keep a mental map of my desktops, or keep going back to the Shell overview. There’s no normal workflow that automatically makes use of additional desktops. (I have a little more to say about that last sentence, see Workflow below.)

This is partly my fault, as I could probably learn to manually build these into my workflow.

Overview

The fact I’m avoiding the overview in dealing with multiple desktops points to the fact that I almost never touch the overview. In the course of a day, 90% of my overview use is in the first minutes of starting my computer. That’s usually to open a terminal, browser, and mail client. Maybe a few other things get opened/closed during the day (eg, wireshark), but these are rare.

I could have my common processes open on login, but then I’d really neglect the overview.

But this is less a criticism of the Overview/Shell, than the way I’m using it and that it’s meant to stay out of the way.

Things I Don’t Care About

I press Alt when I’m going to shut down. It doesn’t bother me. I understand that it would be trouble for discoverability reasons, and would see it fixed (I believe there’s some further work on changing it already?).

I open new windows from the application itself. As said above, I tend to avoid the Overview anyway, so making it easier to launch multiple windows for apps wouldn’t buy me anything.

Workflow

I mentioned not using multiple desktops due to workflow problems. That’s the same reason I only sparingly use Panorama in Iceweasel/Firefox.

In general, I’m conservative in my computing. I keep the number of visible tabs in Iceweasel below 10. But that’s based on experiencing frustration when I have too much around. There are people who regularly speak of having hundreds of tabs open.

My guess is that they would rather find the tab they want than navigate to a new tab.

But the point is, there’s an opportunity to have things like Panorama and multiple desktops automated into the workflow. If I could open 50 tabs without managing them (building and pruning the set), it would be entirely common.

For Panorama, that would probably involve some sort of on-screen/non-dedicated group mechanism.

For multiple desktops, seeing the other desktops might be part of it, but that would add clutter to the desktop. Better might be to do away with the concept and instead have some other way of managing what windows are on the screen(s) at once.

In any case, having features that aren’t part of the workflow requires the user to build their own extra steps into their work.

Summary

If you look, you’ll see all my (minor) complaints are regarding places where GNOME Shell gets in my way. It doesn’t do it very much.

I’m rather happy with what’s here. It can be better, but for all of the grief it receives, it’s a stable desktop experience. I honestly believe that the complaints tend more to the feelings of betrayal at the loss of GNOME 2 than any deep complaints at the state of Shell.

Looking Forward to the Future of Iceweasel

Just a short look at some of the things I’m looking forward to seeing in the future versions of Firefox/Iceweasel.

Mozilla Persona

The biggest feature that I really hope takes off will be Mozilla Persona, which is will bring the ability to replace all the Login with Facebook and OpenID and remembering a million passwords with a system that allows you to have multiple managed identities with your choice of identity provider.

In many ways BrowserID is an evolution from OpenID, but as it gets built-in to the browser, it should bring an easier adoption curve with it. This can’t happen soon enough, with more and more major sites being cracked and the user data being strewn across the web.

Australis

The visual refresh of the browser (see mockups: Mozilla: shorlander: Australis Design Specs for Linux) is going to be great. My favorite part of this is the non-active tabs having low-volume to their appearance. This gives a much nicer feel and the impression that they are truly in the background; your active tab is what everything below it is about.

That will be improved over time as other features of the browser enhance that contextual choice.

GCLI — the Graphics Command Line

This is a developer tool, which allows you to easily access developer tools and commands so that you can try things out while developing on the web platform. It should allow for things like color manipulation, screenshot creation (great for documentation), and other tasks. Documentation at MDN: Tools: GCLI, which leads me to the final thing about Mozilla I’m really looking forward to:

MDN Kuma Switch

This isn’t really in the browser itself, but it’s just as important: the Mozilla Developer Network (MDN) is moving to a different platform, which will allow it to boldly go where no wiki has gone before. I use MDN a lot for learning about the browser and the web, and I’ve even made some minor edits to it before. But the current (soon-to-be-old) platform has what I consider a clunky interface for editing articles, and it’s likely it’s deterred some people from contributing.

The new MDN is based on the same codebase as the awesome Mozilla Support (SUMO), which means that further progress can be shared between both sites.

Really, some great work is afoot. I look forward to seeing what’s next.

Slow JavaScript in My Browser?

I look at a case of finding bad performance in ECMAScript/Javascript benchmarks, leading to a hunt for what’s wrong with my browser.

Another short one for November. Firefox 9 beta is now out, and that means the awesome package manager for Iceweasel has already got it packaged for Debian Unstable. In reading up on what’s new in Firefox 9, people mentioned Type Inference being added to its JavaScript engine, bringing some nice performance gains.

That led me to want to see how fast my browser is these days. For that I hopped on to the Kraken benchmark and V8 benchmark (separately, of course, to prevent one from slowing the other). Then I became concerned.

My everyday browser and profile:

  • Kraken: 12008ms
  • V8: 1522

When I tried Kraken from Firefox Safe Mode, it actually got so bad that the imaging: gaussian-blur portion of the test was timing out. For the sake of consistency/thoroughness, I’ve repeated the benchmarks from Safe Mode:

  • Kraken: 59363ms
  • V8: 583

(Note that on the Kraken tests where it caused the ‘slow script’ dialog to pop up, I had to manually tell it not to issue the warning the first time, which means a score even worse than it would have been (humans are slow).)

[Edit: Mozilla Bugzilla: Bug 453642 shows that Just In Time (JIT) compilation of JavaScript is disabled in Firefox Safe Mode, which clears that up.]

As my local builds of Firefox are on version 11 (the current nightly), using one of them won’t give me the exact same code to test against, but it’s a start. I can also download a copy of the Firefox 9 beta as compiled by Mozilla, and run that, to give me another datapoint.

Why am I doing this? Because at this point, it’s not obviously a bug. It could be caused by some other problem with my system, and even if it is a bug in Iceweasel, the extra data can prove useful.

So:

  • Iceweasel with my original profile:

    • Kraken: 12008ms
    • V8: 1522
  • My local build:

    • Kraken: 3612ms
    • V8: 5476
  • Official Firefox 9 beta:

    • Kraken: 3439ms
    • V8: 6324

So we know that there’s a problem. Now the question is whether it’s with the package itself or something else on my system.

Here I try Iceweasel with a fresh profile:

  • Kraken: 3711ms
  • V8: 5696

Okay. So now I know, no doubt, that it’s my profile. What’s disturbing is that the problem still showed itself in safe mode.

My first step in tracking down my profile’s problem will be to disable all add-ons:

  • Kraken: 3693ms
  • V8: 5691

Ouch. Still not sure why safe-mode would have degenerate behavior, but at least I can now do a binary search (disabling half the add-ons, and test, etc. until I narrow it to a single add-on) to find which add-on is causing my problem.

And the winner is… Firebug. Firebug is an excellent extensions that lets the user inspect the web they use every day, but to do that it has to have its hands in the pie of the web, which can slow things down. Let’s see what we can tweak about my current settings for Firebug to hopefully leave it enabled while getting acceptable performance.

And a search turns up Mozillazine Forums: TM and PM Performance Thread: Comment by phuzi0n:

Is Firebug killing javascript performance after TI landed for anyone else? I tried updating to the latest stable Firebug 1.8.2 and then to 1.9.0a1 but it still slows down v8 benchmark by ~4x and sunspider by ~2x. I made sure that Firebug’s javascript profiling is disabled (with Firebug profiling enabled v8 is ~10x slower).

So, the current vintage of Firebug has some issues with the changes to JavaScript. That’s unfortunate, but knowing is half the battle.

In retrospect, I should have tested with a fresh profile before worrying about other builds of Firefox, as it would have highlighted the source of the problem much faster, but I was thrown off by the really bad performance in safe-mode, which led me to believe it couldn’t be an add-on.

For the time being, I am going to keep Firebug on, but if I run into pages that seem slow, I can always turn it off.