Criticisms for the 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.


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.


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.


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

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.


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?

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.


  • 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.


Ready for Iceweasel 4?

I updated to Iceweasel 4 today which is in the Debian experimental repository.  The update process was as smooth as can be expected.  A few extensions didn’t update, which required looking into why and finding alternatives.

  1. All-in-One Gestures, which I used for the scrollwheel on tabs behavior, wasn’t updated. I opted for Tab Wheel Scroll, which doesn’t have all the extra features I never used.  The author’s description even leads with, “do one thing and do it well,” so I probably should have switched to it earlier.
  2. Firebug needed updating; no big deal.
  3. CS Lite‘s author has apparently stopped updating, which is a shame. For now I’m using Cookie Monster, which is very similar to CS Lite, but I liked the former’s icon.  The latter also currently doesn’t allow repositioning its statusbar button.

I’d like to not show my Add-on bar in Iceweasel 4, since part of the redesign is to get rid of some of the extra chrome.  But for now I’m stuck with it:

  1. As mentioned, Cookie Monster won’t let you move its button.
  2. Same goes for Greasemonkey.
  3. Firebug puts one there, too, but it also allows you to have a regular toolbar button.

So, until Greasemonkey and a good Cookie tool let me move their buttons, I’ll have to see the Add-on bar.

Finally, it appears (see 616353) that the current nVidia driver screws with Iceweasel’s rendering in several places.  So far, that’s only been an annoyance.  I can’t tell which tab is current, and I’ve seen some other rendering glitches too:

  1. The site identity is munged.
  2. I saw an advertisement stick on the screen regardless of which tab I viewed; it persisted after closing the tab that contained it, and even after I restarted the browser.  Lame.

Hopefully a new driver will be available soon, but until then I shall roll with the punches.

The good news:

  1. The browser is faster
  2. It’s prettier even if I’m still in a half-state waiting to turn on all the goodies (no bottom bar; using the one-button menu; the flawless rendering it should have).
  3. Panorama will make workflows easier to manage.
  4. It lays the groundwork for the best that’s yet to come.

Mozilla rocks, and so does glandium for the hard work he’s done in packaging their work for Debian.  And so does Debian for their hard work.  Hell, even the nVidia guys that introduced this annoying rendering bug deserve a pat on the back.

Tomorrow Firefox 4 will be unleashed on an unsuspecting public, and the web will be even more awesome.

hyperweb linux

The End of Iceweasel?

Not sure how I missed this, but better late than never.

Some years ago Debian forked the Firefox web browser because of copyright issues regarding the Firefox logo.  There were a few other reasons, but that was the main one.  That’s changed, officially as of March of 2010 (mozilla-central – changeset – 39109:99d80bc3f18b), but apparently the actual license changed prior to that.  The logo is still under trademark, but it is free speech now.

A few scenarios exist:

  1. Iceweasel goes away.  In this scenario an agreement on Debian modifying Firefox is made, and Firefox replaces Iceweasel.
  2. Iceweasel continues as is.  In this scenario the other issues don’t budge, and the status quo is maintained.
  3. Iceweasel and Firefox coexist.  In this scenario there isn’t agreement on the issues, but Debian decides to maintain an official Firefox package without changes anyway.

It’s more likely that either of the first two happen than the third, as it would still require extra work in packaging and bug management for the third to occur, and it wouldn’t have that much benefit.  One of the maintainers of Iceweasel ( Mind Blowing News) seems pretty sure that Firefox will return, but time will tell.

While they’re at it, I wish that they would find a solution to the libPNG mess.