GNOME Shell, panel applets, and eating your cake

One of the complaints doing the rounds about GNOME Shell is that it has no panel applets. This is technically true. It's also entirely the wrong way of looking at things: I hope this post will make it clear why this is, and make some people happier with the road GNOME is going down. So, to start with, let's take a step back and ask ourselves what exactly panel applets are, and what we mean by GNOME Shell not having them. On a superficial level, it's simple enough. Panel applets are processes that paint little widgets into the panel. They tell us stuff. Maybe we can interact with them. There are thousands of them for GNOME 2, to show the weather, stock prices, hardware status, all sorts of other things. Do each of these bits of code hook themselves into gnome-panel from scratch? Of course not. That'd be silly. No: in GNOME 2, there is a standard interface for panel applets, provided by the libpanelapplet library. This library provides all the hooks into gnome-panel; you just write your applet following the standards laid down by libpanelapplet. So, let's take a step back and a higher-level look. What's really going on here? GNOME 2 provides developers with a very specific interface for extending its functionality, this idea of a 'panel applet'. It's a single, very limited way in which you can extend GNOME 2. GNOME 2 didn't provide many other ways of doing this, and for all sorts of little things that people wanted to add to GNOME 2, the panel applet concept was the best one available. So all these thousands of little GNOME 2 extensions are written as panel applets, using libpanelapplet, not because that is the only or even necessarily the best way such an extension can possibly be presented, but because that's what GNOME 2 gave you as a way to extend it: you got to write a panel applet, or nothing. So, let's wind forward a bit, to GNOME 3. When we say GNOME 3 does not have panel applets, what we mean by this is that it does not have libpanelapplet. GNOME 3's 'panel' doesn't interface with libpanelapplet and let you extend its functionality in that way. All those third party addons currently implemented as panel applets via libpanelapplet do not work with GNOME 3. And right here and now, that kinda sucks if you really like using one or more of them. But hold on! Let's take a step back and look at things from a higher level again. This idea of GNOME 3 'not having panel applets' is only valid on that boring little narrow-minded level from that last paragraph. From up here, if you squint a bit, GNOME 3 does have panel applets. In fact, it has panel applets and a whole lot more. Why? Because GNOME 3 doesn't just give you one boring, narrow, restricted way of extending itself. GNOME 3 gives you Shell extensions. The Shell extension interface is a way cooler way of extending GNOME 3's functionality than libpanelapplet ever was a way of extending GNOME 2's. It's not compatible with libpanelapplet's APIs, no. So you can't just rebuild your existing panel applet and have it work. But you can write something as a Shell extension which works exactly like a panel applet. It'll look like one, walk like one, and quack like one. So if you as a developer are absolutely convinced that a panel applet is the exact correct UI for your little add-on to GNOME, you can simply re-write it as one using the Shell extensions interface. In that sense, hey, GNOME 3 really does have panel applets! But it has so much more, too. Maybe a panel applet wasn't really absolutely the best way of implementing your add-on's functionality: maybe you only wrote it as a panel applet because, really, that was the only way GNOME 2 let you do it. What if your little add-on should live in the clock? Or the overview? Maybe it should make the whole panel change color when the system's getting too hot? Good luck doing all of that with libpanelapplet; with GNOME Shell extensions, you can. If you look at it from the core GNOME developer's side, once you've made this awesome Shell extensions interface available, why would you worry about updating an interface which only allowed one very specific type of extension, and did it in a technically problematic way? There's just no reason. If you really look at things from the right angle, this is a great story of GNOME 3 providing a massive improvement on GNOME 2. Yes, Shell extensions are not backward compatible with panel applets. Your old panel applet code won't run in GNOME 3. But that's the point of a 3.0 release: it gives the developers the freedom to change things for the better and lose backwards compatibility where it's necessary. This leads to short-term pain - the same was true with 2.0 - but long-term gain. You can already see extensions doing things with GNOME 3 that a third-party add-on could never have done to GNOME 2 (or at least not without major, unsupported hackery with GNOME internals that add-ons were never meant to mess with). Someone's written an extension that adds quick launchers to the Shell panel and makes the Activities button launch a nested menu system. Is this how the GNOME designers think Shell should work? No, but so what? The point is the power of the extensions interface. There are extensions to change alt-tab behaviour, an extension to add the Power Off button back to the User menu, and many others - already. As a developer, right now you have far more flexibility to change GNOME's functionality in an add-on than you ever did with GNOME 2. As a user, you can already benefit from some extensions that would not have been possible in GNOME 2, and by the time GNOME 3.2 or 3.4 rolls around, I predict the range of extensions will make the panel applets from GNOME 2 look dull in comparison. (edit: I was going to mention having your cake and eating it in here somewhere, hence the title, but I forgot. So it turns out that the cake is a lie!)