Submit News Alternative Tip Form

Feature Wishlist: Progress Bars in GNOME Shell

gnome shell progress bars mockup

Bug 701402 calls on GNOME developers to ‘implement progress bars in GNOME Shell’.

This is absolutely the sort of bug I can get behind.

See, for me, coming from the Unity desktop to set up camp in GNOME, I’m far too reliant on to being able to use visual indicators on my desktop to be informed of what is happening around me.

These range from transient desktop notifications (for which GNOME has an equivalent) to app indicators, on-app badge counts, and progress bars (for which GNOME doesn’t have an equivalent).

So this is absolutely the kind of feature I’d love to see introduced.

This post isn’t the first time I’ve publicly whined about missing my visual short-hands. Back in April I tweeted this mock-up. It shows how unread badge counts could look on GNOME extensions like Dash to Panel should GNOME implement some sort of API to support them:

Unsurprisingly a number of Twitter followers replied to that tweet to say they also dig the idea, agreeing that a similar feature baked into GNOME would be a most welcome one.

As equally useful as on-app unread counts are progress bars:

Progress bars provide a fuss-free way to keep an eye on downloads, renders and encodes while working elsewhere, or on a different workspace.

There’s Currently No Spec for This

The way GNOME Shell’s workflow feels out-of-the-box, it sort of has a “you should only see what you’re working on” ethic. As such there’s currently no spec or API relaying or displaying indicator counts, progress bars and the like.

And it makes sense why.

GNOME Shell does not display app launchers on the desktop, so there are no app launchers or shortcuts to place progress bars and unread badges on.

Indeed, to see the icons these overlays would be placed on you have to open the Activities Overlay, and if you’re doing that you get to gawp at thumbnails of all your open windows anyway, rendering the need for visual indicators rather (but not entirely) moot.

Transfers App

GNOME devs did propose a sort of alternative to progress bars: a separate app called Transfers.

But ssh, keep it to yourself, as this app thankfully hasn’t seen any development yet — and I’d rather it stayed that way! The idea that I’d need to run a second app to keep an eye on what’s happening in my other apps defeats the convenience of progress bars, which are useful precisely because I don’t have to switch to a different app window.

Oh For an API…

Simpls status indicators for the GNOME Dash (what it calls the dock) through a nimble API that other extensions (like Dash to Panel, Dash to Dock, and Dash to Frog) can also make use of — that’s the dream, right?

Ubuntu has had just such a spec for a while called libunity. It’s decent enough for some third-party apps, like Plank, to make use of it too.

Reader Owais L. (thanks) recently pointed out a bug report in which a GNOME dev responds to a query querying the possibility of progress bars on icons in the GNOME Dash (again, their name for the favourites bar/dock).

Writing back in May, GNOME’s Florian Müllner said that users who ‘want to see progress on this issue’ need to:

  1. Com[e] up with a DBus API that allows applications to relay progress information to the shell
  2. Propose patches that expose that API in GIO/GTK
  3. Provide proof-of-concept patches for gnome-shell and an app, so people can play around with it
  4. Repeat any of 1-3 according to the feedback you receive

Coming up with an API that matches this requirement is only half the battle, of course.

The other half will be in trying to get GNOME to adopt it!