Skip to main content

Linux: GNOME Shell

I decided to give GNOME Shell a try.
The GNOME Shell redefines user interactions with the GNOME desktop. In particular, it offers new ways for the user to find and open applications and documents, switch between various activities, and view incoming information such as chat messages or system notifications.
To say that I love it would be an understatement. It's exactly the sort of user interface innovation I was hoping would happen in the Linux world. What I like is that it isn't just eye candy. Instead of just being a badly done knockoff of Windows or OS X, it's new, clever, and interesting. It simplifies my desktop, while at the same time making me more efficient and powerful.
  • Here are the screencasts.
  • Here's a cheatsheet that explains all the features, in case they aren't obvious.
  • Here's how to install it on Ubuntu.
I did have one problem. If you switch to GNOME Shell completely, your mouse may disappear when you click the Activities button. Remember, this is still a preview release of GNOME Shell, so bugs are to be expected. The simplest way to fix this issue is to type Alt-F2 and then "restart".


jjinux said…
Using Alt-F2 and "restart" also helps if you switch from your laptop display to an external display, and they have different resolutions.
Alex Conrad said…
(was that previous comment spam?)

I tried Gnome Shell with Karmic running in a VM Player. It's very sluggish. From the very low frame rate I seem to have, it looks like it only uses OpenGL, right? I'll try that on a real install later.

Thanks for pointing this out. It looks nice.
dm said…
haven't tried GNOME Shell, but it does look interesting...

After watching the screencasts, I'm still wondering if and how it handles multiple instances of the same application. Some apps you only want the one instance, other apps multiple instances might be preferred. Is it easy to find and switch between the multiple instances?

Related: how well does it handle the GIMP with its multiple windows?
jjinux said…
> Is it easy to find and switch between the multiple instances?

Yes, there's intelligent handling for apps with multiple instances, especially when you hit Alt-Tab.

> Related: how well does it handle the GIMP with its multiple windows?

It's not a tiling window manager, so there's less to go wrong. I just tried it out, and it handled the GIMP perfectly sensibly.
jjinux said…
> (was that previous comment spam?)

Yeah, sorry about that. I just deleted it.

> I tried Gnome Shell with Karmic running in a VM Player. It's very sluggish. From the very low frame rate I seem to have, it looks like it only uses OpenGL, right? I'll try that on a real install later.

Yeah, I wouldn't use it on VM Player. If I were going to use VM Player, I'd use OpenBox or Xubuntu or something like that. I got tired of waiting for VMWare Fusion, which is why I installed Linux natively on my MacBook.

Since I have a MacBook with 2 cores and 2 gigs of memory, I've been playing with things that can actually make use of all that hardware in a useful (not merely wasteful) way. I think GNOME Shell does. I.e. it's not just eye candy, but is actually pretty useful.

> Thanks for pointing this out. It looks nice.

You're welcome! :)
Unknown said…
Hey JJ. Just came across this old post of yours. In any case, are you still using Gnome Shell? It's my preferred DE as well. One itch that has been scratching at me lately is that the Shell has JavaScript bindings (in fact the shell itself is written in Javascript). I'm curious what it would take for js-interop to get it to work with Dart.
jjinux said…
Oh wow! I haven't played with GNOME Shell in a while, so I never thought of using it with Dart. In theory, it should indeed work with clever use of JS interop.

Popular posts from this blog

Ubuntu 20.04 on a 2015 15" MacBook Pro

I decided to give Ubuntu 20.04 a try on my 2015 15" MacBook Pro. I didn't actually install it; I just live booted from a USB thumb drive which was enough to try out everything I wanted. In summary, it's not perfect, and issues with my camera would prevent me from switching, but given the right hardware, I think it's a really viable option. The first thing I wanted to try was what would happen if I plugged in a non-HiDPI screen given that my laptop has a HiDPI screen. Without sub-pixel scaling, whatever scale rate I picked for one screen would apply to the other. However, once I turned on sub-pixel scaling, I was able to pick different scale rates for the internal and external displays. That looked ok. I tried plugging in and unplugging multiple times, and it didn't crash. I doubt it'd work with my Thunderbolt display at work, but it worked fine for my HDMI displays at home. I even plugged it into my TV, and it stuck to the 100% scaling I picked for the othe

ERNOS: Erlang Networked Operating System

I've been reading Dreaming in Code lately, and I really like it. If you're not a dreamer, you may safely skip the rest of this post ;) In Chapter 10, "Engineers and Artists", Alan Kay, John Backus, and Jaron Lanier really got me thinking. I've also been thinking a lot about Minix 3 , Erlang , and the original Lisp machine . The ideas are beginning to synthesize into something cohesive--more than just the sum of their parts. Now, I'm sure that many of these ideas have already been envisioned within , LLVM , Microsoft's Singularity project, or in some other place that I haven't managed to discover or fully read, but I'm going to blog them anyway. Rather than wax philosophical, let me just dump out some ideas: Start with Minix 3. It's a new microkernel, and it's meant for real use, unlike the original Minix. "This new OS is extremely small, with the part that runs in kernel mode under 4000 lines of executable code.&quo

Haskell or Erlang?

I've coded in both Erlang and Haskell. Erlang is practical, efficient, and useful. It's got a wonderful niche in the distributed world, and it has some real success stories such as CouchDB and Haskell is elegant and beautiful. It's been successful in various programming language competitions. I have some experience in both, but I'm thinking it's time to really commit to learning one of them on a professional level. They both have good books out now, and it's probably time I read one of those books cover to cover. My question is which? Back in 2000, Perl had established a real niche for systems administration, CGI, and text processing. The syntax wasn't exactly beautiful (unless you're into that sort of thing), but it was popular and mature. Python hadn't really become popular, nor did it really have a strong niche (at least as far as I could see). I went with Python because of its elegance, but since then, I've coded both p