Ubuntu TV: the case for Unity

By now you should have heard that Canonical is branching out from the desktop and has begun work on getting Ubuntu on TVs.   Lost in all the discussion of OEM partnerships and content distribution agreements is a more exciting (from my perspective) topic: Ubuntu TV shows why Unity was the right choice for Canonical to make.

The Unity Platform

Ubuntu TV doesn’t just look like Unity, it is Unity.  A somewhat different configuration, visually, from the desktop version, but fundamentally the same.  Unity isn’t just a top panel and side launcher, it is a set of technologies and APIs: Indicators, Lenses, Quick Lists, DBus menus, etc.  All of those components will be the same in Ubuntu TV as they are on the desktop, even if their presentation to the user is slightly different.  When you see Unity on tablets and phones it will be the same story.

The Developer Story

Having the same platform means that Ubuntu offers developers a single development target, whether they are writing an application for the desktop, TVs, tablets or phones.  There is only one notifications API, only one search API, only one cloud syncing API.  Nobody currently offers that kind of unified development platform across all form factors, not Microsoft, not Google, not Apple.

If you are writing the next Angry Birds or TweetDeck, would you want to target a platform that only exists on one or two form factors, or one that will allow your application to run on all of them without having to be ported or rewritten?

The Consumer Story

Anybody with multiple devices has found an application for one that isn’t available for another.  How many times have we wanted the functionality offered by one of our desktop apps available to us when we’re on the go?  How many games do you have on your phone that you’d like to have on your laptop too?  With Ubuntu powered devices you will have what you want where you want it.  Combine that with Ubuntu One and your data will flow seamlessly between them as well.

A farewell to Gnome 2

None of this would have been possible with Gnome 2.  It was a great platform for it’s time, when there was a clear distinction between computers and other devices.  Computers had medium-sized screens, a keyboard and a mouse.  They didn’t have touchscreens, they didn’t change aspect ratio when turned sideways.  Devices lacked the ability to install third party applications, the mostly lacked network connectivity, and they had very limited storage and processing capabilities.

But now laptops and desktops have touch screens, phones have multi-core, multi-GHz processors.  TVs and automobiles are both getting smarter and gaining more and more of the features of both computers and devices.  And everything is connected to the Internet.  We need a platform for this post-2010 computing landscape, something that can be equally at home with a touch screen as it is with a mouse, with a 4 inch and a 42 inch display.

Unity is that platform.

This entry was posted in OpenSource, Programming, Work and tagged , , , , , , , . Bookmark the permalink.

54 Responses to Ubuntu TV: the case for Unity

  1. shnor says:

    Why does Ubuntu make people use a platform on their desktop that was intended to be used on TVs?

    • Michael Hall says:

      It wasn’t intended for just TVs. Or just desktops. Or just tablets. It was intended to be able to work well on all of them with minimal changes.

      • shnor says:

        I appologize for this comment. It was meant as a joke.
        In the end I’m happy about the success of ubuntu/linux regardless of the used desktop platform/toolkit.

  2. tom says:

    The developer story is?

    Compiz, GTK or Qt or what? A very clear recommendation like: If you want fast starting beautiful modern apps you have to use Qt or something would be nice, but there is none of that.

    • Daeng Bo says:

      This is the argument that I try to get across to Canonical / Ubuntu: You need a development environment — an IDE / toolkit / language combination that has tons of good, current documentation, including tutorials.

      I know about the developer site, but it doesn’t really help in this regard yet.
      “Hey, I want to write applications for Ubuntu,” says the hopeful dev.
      “OK. You can choose from tens of languages, several toolkits, and a large number of IDEs. Get busy researching which one looks good for you. Of course, you won’t really know, because the docs for combining any three of these are two to three versions out of date, and the library APIs have all changed in that time. Good luck!”
      “Hmmm …, thanks, I guess.” And the dev goes back to whatever platform they were on before, writing a blog about how “Linux is too messy to program for.”

      **Windows 7 Training Kit For Developers**
      ==System requirements==
      Supported Operating Systems: Windows 7
      Windows 7
      Windows 7SDK
      Visual Studio 2008
      Windows Code Pack API for .NET Framework
      Visual Studio 2010 Beta 2 (or higher)


      **Tools for iOS Development**
      Requirements: To develop applications for iOS, you need a Mac with an Intel processor.
      For additional requirements, see the Xcode Readme PDF file next to the Xcode toolset download image, or consult the Xcode page in the Mac App Store (choose Apple menu > App Store to launch the App Store application).
      Download Xcode from developer.apple.com/xcode.

      Those make it pretty clear where to start.

      • Michael Hall says:

        The thing is, ‘hopeful dev’ already has a language he knows, and an editor/IDE he knows. We’re not telling him to go research and learn something new, we’re saying “use what you already know”. If you know C, you’re good. If you know Python, you’re good. If you know C#, you’re good. If you know Java, well you can get by I guess. Vi, sure. Emacs, sure. GEdit, ok. Eclipse, if you insist. SharpDevelop, use MonoDevelop and you’ll be fine.

        If ‘hopeful dev’ is comfortable on any combination of these, all he needs to learn is the new API. How would a Python dev fair trying to write a Windows 7 app? Or a C# dev targeting iOS?

        • Klapauzius says:

          I’ve been coding for GTK/GNOME2. Now basically Ubuntu tells me they have decided to put a new shiny unusable XBMC-Clone based on an unstable beta-quality-library on a yet-to-be-developed TV and yet-to-be-developed smartphones/Tablets/refrigerators/toasters/younameit and therefore i can kiss my code goodbye and let it join the choir invisible. And my guess is they’ll kill this awesome idea in one year and come up with another great yet-to-be-found endeavour. the ISS running Ubuntu “Duality”, maybe.

          No, thanks.

        • tom says:

          Well, no harm in advertising a way that has the best tools and docs and IDEs.
          Problem is for Ubuntu Desktop this would probably be something with a GTK+ focus and for everything else it seems Qt-stuff would be the better choice.
          You are just too much of a coward to admit that the whole story is kinda messy.
          If you want to compete with Apples and MS smoothness, some hotchbotch with Python, Mono, Qt, Java etc won’t do you any good. It will be resource heavy, slow, laggy and it will suck.

          • D says:

            Qt slow? What? Only if you’re trying to use Perl or something like that. C++ Qt apps usually are lightning fast.

        • Allan says:

          “Vi, sure. Emacs, sure. GEdit, ok. Eclipse,”

          For a hopeful, VB developer, these are not options.
          Gambas might be needed by Ubuntu, I suggest and improve it.

          • JanC says:

            Gambas Visual Basic-alike) is available if you want to use it, as is FreePascal + Lazarus (Delphi-alike).

            If you want it to be more prominently displayed, maybe you can provide text + graphics about its features, advantages, etc.—and maybe Michael can get it included in the developer site somehow?

  3. istoff says:

    Regarding your quote:
    ” There is only one notifications API, only one search API, only one cloud syncing API. Nobody currently offers that kind of unified development platform across all form factors, not Microsoft, not Google, not Apple.”

    – what other hardware is supported besides (I assume X86/64 and possibly ARM) ?

    If you are restricting it to a class of devices capable of running Ubuntu, how different is that from Apple? On the contrary, developing for Android or even IOS would appear to be more unified than what you mention.

    I apologize in advance if I am missing something obvious.

    • Michael Hall says:

      Currently we officially support x86, amd64, and recent ARM chips. Between those, we cover a huge amount of computing hardware.

      Apple doesn’t just lock you into a CPU architecture, they lock you into the brand. OSX supports x86 and amd64, but you can’t (legally) run it on a Dell, or HP. iOS supports ARM, but you can’t run it on a Motorola Droid or Samsung Galaxy.

    • Klapauzius says:

      Well, that’s just awesome. So we have some unified post-beta-Quality API’s. Great.

      How about Documentation ?

      How about adequate Language bindings ?

      How about a professional development environment ?

      How about stable drivers ?

      GNOME2 had reached maturity to the point that all of the above (which are a prerequisite for really productive development) could have been done. And then you killed it.


      • Michael Hall says:

        Documentation can be found on http://unity.ubuntu.com/projects/

        Most of Unity’s APIs use DBus and GObject introspection, which means that you can use those APIs from any language with bindings for them. This way you always have access to the latest version of the API from any language.

        “Professional development environment” means different things to different people. Ubuntu offers a wide variety of IDE, editors and toolchains. Ultimately it comes down to choice, use what works best for you.

        Drivers come from the Linux kernel, they aren’t specific to Ubuntu or even part of the Unity project. We all want better drivers, and if you look back even 5 years you will see that we’ve come a long way.

        • Klapauzius says:

          The Unity documentation i know looks like this:


          Ayatana Home
          Application Menu
          Sound Menu
          Scroll Bars


          1.Launcher API
          3.Using the Launcher API
          1.Static Quicklist entries
          2.Dynamic Quicklist entries
          3.Quicklist elements
          4.Filing Bugs
          5.Example Code
          1.Vala Example
          2.Python Example
          6.Low level DBus API: com.canonical.Unity.LauncherEntry

          Launcher API
          We support adding quicklists, counters, and progress bars for apps in the Unity Launcher:

          The APIs described in this document are subject to change. We are trying very hard to bring you a powerful, fun, and coherent API to instrument the Unity shell from top to bottom. We acknowledge that this is a non trivial task and we might not get it Just Right (TM) in the first cut, and since we really want to give you, dear app developer, the best, we have to make reservations for API breaks until we’ve really nailed it down.
          When everyone is happy we will guarantee API and ABI stability, but not just yet. Sorry

          Using the Launcher API
          The libunity API does not currently have any ABI or API stability guarantees, we expect to solidify this for 11.10 in the first week of July 2011

          Nuff said.

          • Klapauzius says:

            “Low level DBus API: com.canonical.Unity.LauncherEntry
            While the libunity is unstable, the DBus protocol underneath is even more so. We strongly discourage anyone from relying on it “

          • Michael Hall says:

            Can you give me a link to where you are finding that documentation?

      • Vadim P. says:

        That’s how things move on. How can Gnome 2 even be considered to be applicable for a TV?

  4. Anubeon says:

    To be fair, I think most of the objections end-users have with Unity is the lack of custimisation, rather than the underlying technologies. I, for one, approve of the various ‘behind the curtain’ technologies in Unity (Launcher API, Indicators, Lenses, Scopes, etc…). However, the lack of flexibility within the desktop variant of Unity. In particular, the positioning of the launcher and integration of titlebar elements within the top panel (which looks crowded to me and could do with an elementary-esque AppMenu option). For me, whilst Unity desktop is visually and technically splendid in many ways (the ‘nudge/reveal’ animation of the launcher is particularly beautiful), its lack of configurability at this (admittedly early) stage in development, makes it unusable to me. I’ve thus opted to test the daily releases of those elementaryOS chaps, and can’t forsee me switching back in the forseeable future (I may test the third-party horizontal launcher variant of Unity at a later date).

    All that being said, Unity appears to be a perfect fit for Ubuntu TV and from what I’ve seen thus far I’ve been supremely impressed (I may try testing Ubuntu TV on a raspberry pi some day soon). I few little niggles with skinning, but the fact that (as you say) the core of unity is its backend APIs means that these could be easily ironed out if needed (although to be honest, they are very minor quibbles indeed w.r.t. Ubuntu TV – not worthy of developer attention even if I do say so myself). Some work on themeing (the ability to remove those infuriating square edges from launcher icons) wouldn’t go amiss though. :-)

    All in all, I think Unity has been a goop thing. Even if, in its current frontend form on the desktop, it’s not to my (and others) liking. :-)

    • Michael Hall says:

      Rasberry Pi uses an ARMv6 chip, I think Ubuntu and Linaro only support ARMv7 and up.

      • Anubeon says:

        There was another raspberry pi-esque offering with a more modern ARM processesor I read about recently, so I may hold out for that. It has a similar, but slightly higher price point if memory services.

        Are there any plans to extend Ubuntu/Unity support for earlier ARM architechtures, or are the current restrictions (to >ARMv7) a fait a compli?

        • Michael Hall says:

          Ubuntu has paired with Linaro to create a standard base for Linux on ARM, so it will depend on whether or not the Linaro base can be run on ARMv6 and earlier chips.

        • JanC says:

          “””There was another raspberry pi-esque offering with a more modern ARM processesor I read about recently, so I may hold out for that.”””

          I suppose you are referring to http://rhombus-tech.net/allwinner_a10/ which is still very much a work in progress AFAIK?

  5. Ludwig Van B. says:

    All that would have been great if only it had been built on top of the already-existing gnome-shell instead of doing exactly the same thing as gnome-shell but in a totally isolated way… Now, instead of having one platform to rule them all we have two… And having two great platforms means that we really have no good definitive platform to develop for (and a lot of duplicated effort).

    • Michael Hall says:

      Remember that when development on Unity started, Gnome-Shell was a far cry from what it is now. Even now, I’m not sure Gnome-Shell will adapt well to non-desktop form factors, because that wasn’t part of it’s design goal.

      • Wesley Stout says:

        Michael, I would have to disagree on Gnome-Shell and non-desktop form factors actually many of the complaints I have heard is that Gnome-Shell seems more for tablets than desktops. That being said I would gladly purchase Ubuntu TV the idea seems solid.

        • Michael Hall says:

          I’ve never used GS on a touch device, but from using on my desktop it seemed to depend heavily on mouse hover events, which you just don’t have on touch. There are other design details too that just make me feel that it wouldn’t be comfortable on touch. Unity has some of the same issues to resolve in terms of design, but at this point I believe it’s closer to that goal than GS.

          • Anubeon says:

            Surely a finger hold is the touch-interface equivalent of mouse hover, with a held drag useful for navigating any menus raised from such. I’m sorry, I’ve never used Gnome Shell, so I can’t say whether that’s how they’ve implemented touch (if at all). But that would seem to be the logical analog.

          • Michael Hall says:

            A finger hold is usually interpreted as a click-and-drag, not a mouse hover.

          • Mirek2 says:

            I beg to differ.
            Gnome Shell uses hover to: a) show the notification tray when in window mode, b) get to the “Activities” overview by pushing against the top right corner, and c) show the desktop pane in the “Activities” overview. (I hope I’m not missing anything.)
            a) The notification tray is also shown in the “Activities” overview, so hover isn’t necessary.
            b) Just tap on the “Activities” button to get to the overview — no need for hover there.
            c) The behavior of the desktop pane is being worked on right now.
            On Unity, on the other hand, the menus, window controls of maximized apps, and sometimes the launcher, are shown only on hover, and, AFAIK, there are no alternatives for this.
            Furthermore, Gnome Shell: has larger buttons than Unity, has a retractable on-screen keyboard, has a single easy-to-target window control (Close), and new Gnome applications are being developed with both touch AND mouse+keyboard in mind.

      • Ludwig Van B. says:

        Well, when Unity development started, gnome-shell might not have been very advanced, but – by definition – Unity was… not even started ;) So I still think it would have been a much smarter (and obvious) decision to stick on what was being worked on by upstream gnome developers.

        • michael says:

          See, you wouldn’t say that if you had first hand experience trying to bring any change to GNOME Shell from the outside.

          As it is, GNOME Shell is pretty much a Redhat product (just check the current maintainers). It’s kind of obvious that Canonical – if it wants more control over the direction of GNOME Shell – needs to create its own variation of it. And that variation become a full fork, with Unity.

          It’s important to understand that these decision are driven by business needs.

          • Ludwig Van B. says:

            Well, seeing the number of extensions currently being written for gnome-shell by “outsiders”, and seeing how it seems those extensions can alter pretty much anything in the gnome-shell experience, I fail to understand how Unity couldn’t simply be a gnome-shell extension instead of a compiz plugin.

          • klapauzius says:

            Aaaah, there you have it.

            So Unity is about “more control over the direction” of whatever.

            Luckily this is OSS. People will just chose another distro and move on.

          • michael says:


            So you would bet the future of your product on unstable API that can (and will) change with every release? GNOME Shell extensions are pretty much copypasta, which is a bit scary if you want to support something for longer than 6 months.

            It’s great that GNOME Shell offers the possibility for extensions, but that does not make GNOME Shell a plugin-based architecture.

            Perhaps if GNOME Shell was a proper library then it would have been possible to base Unity on top of that.

            @klapauzius: Yes, and? Every successful F/OSS project has a direction and goals its want to achieve. Why does that suddenly become bad because the direction and goals are backed by commercial interests?

          • Ludwig Van B. says:


            What you’re saying can be said about compiz too.

          • michael says:


            Yes, indeed. With the difference that Canonical has much more control over compiz than it has over GNOME Shell. Makes all the difference in the end.

    • Bill says:

      Going back in history, Gnome-shell was indeed a project right around 10.04, but it was already stagnant. I remember well b/c I really, really wanted to use it and it wasn’t working and no one was working on it. This went on for about a year or so.

      Then, I remember Mark announcing Unity and GS development picked up. So, yes, GS was written first…but it was going NOWHERE until Mark announced Unity. Once that happened, GS seemed to get their act together and get a release out.

      So, that being the case, can we PLEASE stop saying that Canonical should have invested in GS…when the decision was being made, it seemed that GS wasn’t going anywhere….And, TBF to Canonical, GS at the time Unity was announced was nothing like GS today.

      • Anubeon says:

        Also, if Canonical has a different vision to Gnome, fair play to them. If they fail, they fail; if they succeed with have another DE (if that’s the right word here), a more competitive environment and another engine for innovation. I wonder how many used similar arguements to detract from the initial development of Gnome 0.x/1.x/2.x and KDE 1/2/3/4.

        • Michael Hall says:

          Ubuntu still uses probably 90% of Gnome 3, the only part it doesn’t use is Gnome-Shell, so it’s not a separate DE.

          • Anubeon says:

            Quite. I wasn’t quit sure how to describe Unity though, it’s clearly an important part of the UX. DE not the word then, noted and filed. :-)

          • Jef Spaleta says:

            According the the Freedesktop definitions what what an “environment” is as used in the desktop menu specification… Unity is a distinct “environment” from GNOME.


            If you continue to try to portray the Unity as just a different shell over gnome…all you are doing is adding to confusion. You aren’t helping the platform.


          • Michael Hall says:

            Well that’s one way of defining an “environment”. But the purpose of that spec certainly isn’t to create a definitive list of “environments”, or to define what is or is not an “environment”. You can put any value you like for OnlyShowIn, and applications that consume menu files can look for any value they like. Like “operating system”, the term “desktop environment” is nebulous at best. I personally don’t consider a different shell to be enough of a difference to call it a different environment. You are free to differ.

          • Jef Spaleta says:

            I keep missing the point. It’s already a confusing situation exactly because there’s no authoritive definition. It’s not in the Unity platform’s best interest for Canonical reps to continue to make the case that its a step a way from GNOME.

            Moving forward this is going to be less and less true as GNOME integrates with systemd at the session management level. The Unity and GNOME platforms are on divergent paths. Its not just the shell. The shell just happened to be first. But lightdm and gdm are already on divergent paths from an underlying API standpoint for example. The divergence is going to continue. If you continue to choose to communicate about the relationship in the way you are you are just going to walk developers into more confusion that is really necessary. At that will be unfortunate.


          • Mirek2 says:

            Not yet, though it already ships with Qt, uses Compiz instead of Mutter, uses LightDM instead of GDM, has some unique technologies, and plans to develop its own set of core applications.

          • klapauzius says:

            Not really. Unity is deliberately re-implementing lots of low-level libraries for no other reason than the NDH (Not Developed Here)-syndrome.

            For instance:

            “•Why not use the de-facto standard DockMangaer API instead?
            Good question again! The introductory paragraph on the DBus API section gives the clue here. The DockManager API is great for a desktop dock. But if you analyze it you’ll see that it requires a great many DBus messages exchanged when exercised fully. Thus not a great choice for devices with less-than-desktop powers.
            The DockManager interface also doesn’t interface with the Dbusmenu protocol which is more expressive than the DockManager counterpart. There are also both technical- and UI choices in the DockManager API that doesn’t fit well with the vision for Unity.”


  6. Benjamim Gois says:

    Design should not come before usability. And that´s the biggest issue i see in unity. It really looks very nice on the eyes, but it´s unusable on a corporate desktop enviroment. I don´t want to sound like a troll, i really appreciate the canonical effort to make something new and good looking on the linux desktop. To me unity is just another example of duplicated effort on the opensource desktop. The switch to compiz might be the biggest mistake. Compiz is a dying project and compromise the unity stability as well. So at least until 11.10, unity is a unstable and unusable software for me. In my office every station that were running 11.10 were reverted back to xp. Sadly

    • Michael Hall says:

      Ubuntu started using Compiz way back in 2007, it’s hardly new. Just last year Compiz underwent a major set up changes, so it’s hardly dying either.

      • Anubeon says:

        Compiz could use a refresh of its website and documentation though, if it is to see more plug-in development. The current site (which I assume is abandoned) is unmaintained and the forums are locus for spam.

        Disclaimer: I speak as a lay person however, so I can’t speak authorititavely on the matter of documentation (although I’ve read that criticism several times before).

  7. Shark Muttleworth says:

    “I wanna move the launcher to the bottom or to the right. I want to put 100 indicators on my panels. I want 1000’s of useless icons scattered all over my desktop…cuz “I” like it like that.” Geezus! Get over it and move on to something else. Times are changing, so lead, follow or get out of the way. There is Lxde, Xfce, Enlightenment, Gnome 3, Kde, Mate (Gnome 2 fork), Razor-Qt, Fluxbox and many other desktop environments. Pick one or all of them, but stop the needless whining already.

    • Ludwig Van B. says:

      > There is Lxde, Xfce, Enlightenment, Gnome 3, Kde, Mate (Gnome 2 fork), Razor-Qt, Fluxbox and many other desktop environments

      Finally someone from Canonical aknowledges that Unity is not simply a different shell for GNOME 3 but another desktop, and thus a fork of GNOME 3 ;)

      • TJ says:

        ;) he’s not from “Canonical” he’s from “Manonical” lol. Unfortunately for Unity Shark M. is right – there’s a lot of choice (including ms w as one of the choices). I think Unity is too late to come out. Most of new TVs already have something like Google running on them. So to me while Unity is a great attempt it’s a lost case already. What would persuade TV manufs to abandon their current smart tv implementations for Unity?

  8. xlinux says:

    i’m disappointed, this “ubuntu TV” is ( in my opinion ) a big lost opportunity, the TV isn’t a mediacenter, ubuntu tv now is too similar at mediacenter


Comments are closed.