If you have written or know how to write a Quickly template, I’d like to get some help making one for Singlet Lenses and Scopes.Read more
I’ve finally had a little extra time to get back to working on Singlet. There’s been a lot of progress since the first iteration. To start with, Singlet had to be upgraded to work with the new Lens API introduced when Unity 5.0 landed in the Precise repos. Luckily the Singlet API didn’t need to change, so any Singlet lenses written for Oneiric and Unity 4 will only need the latest Singlet to work in Precise.
The more exciting development, though, is that Singlet 0.2 introduces an API for Scopes. This means you can write Lenses that support external scopes from other authors, as well as external Scopes for existing lenses. They don’t both need to be based on Singlet either, you can write a Singlet scope for the Music Lens if you wanted to, and non-Singlet scopes can be written for your Singlet lens. They don’t even have to be in Python.
In order to make the Scope API, I chose to convert my previous LoCo Teams Portal lens into a generic Community lens and separate LoCo Teams scope. The Lens itself ends up being about as simple as can be:
from singlet.lens import Lens, IconViewCategory, ListViewCategory
name = 'community'
description = 'Ubuntu Community Lens'
search_hint = 'Search the Ubuntu Community'
icon = 'community.svg'
category_order = ['teams', 'news', 'events', 'meetings']
teams = IconViewCategory("Teams", 'ubuntu-logo')
news = ListViewCategory("News", 'news-feed')
events = ListViewCategory("Events", 'calendar')
meetings = ListViewCategory("Meetings", 'applications-chat')
As you can see, it’s really nothing more that some meta-data and the categories. All the real work happens in the scope:
name = 'locoteams'
search_hint = 'Search LoCo Teams'
search_on_blank = True
lens = 'community'
categories = ['teams', 'news', 'events', 'meetings']
def __init__(self, *args, **kargs):
super(LocoTeamsScope, self).__init__(*args, **kargs)
self._ltp = locodir.LocoDirectory()
self.lpusername = None
import ConfigParser as configparser
bzrconf = configparser.ConfigParser()
self.lpusername = bzrconf.get('DEFAULT', 'launchpad_username')
def search(self, search, model, cancellable):
I left out the actual search code, because it’s rather long and most of it isn’t important when talking about Singlet itself. Just like the Lens API, a Singlet Scope uses an inner Meta class for meta-data. The most important fields here are the ‘lens’ and ‘categories’ variables. The ‘lens’ tells Singlet the name of the lens your scope is for. Singlet uses this to build DBus names and paths, and also to know where to install your scope. The ‘categories’ list will let you define a result item’s category using a descriptive name, rather than an integer.
model.append('http://loco.ubuntu.com/events/%s/%s/detail/' % (team['lp_name'], tevent['id']), team['mugshot_url'], self.lens.events, "text/html", tevent['name'], '%s\n%s' % (tevent['date_begin'], tevent['description']), '')
It’s important that the order of the categories in the Scope’s Meta matches the order of categories defined in the Lens you are targeting, since in the end it’s still just the position number that’s being passed back to the Dash.
After all this, I still had a little bit of time left in the day. And what good is supporting external scopes if you only have one anyway? So I spent 30 minutes creating another scope, one that will read from the Ubuntu Planet news feed:
The next step is to add some proper packaging to get these into the Ubuntu Software Center, but you impatient users can get them either from their respective bzr branches, or try the preliminary packages from the One Hundred Scopes PPA.
 Note that while lenses written for Singlet 0.1 will work in Singlet 0.2 on Precise, the reverse is not necessarily true. Singlet 0.2, as well as lenses and scopes written for it, will not work on Oneiric.Read more
I hope everyone has seen the announcement about the upcoming Heads Up Display feature hopefully landing in 12.04. If not, go read about it here: http://www.markshuttleworth.com/archives/939 I'll wait.
Great, now in order for this feature to show up in precise it needs some more work and refinement. Our focus on quality continues and this feature is not excluded -- in order to ensure its of release quality for precise, we're asking the community to help test and evaluate the feature. Here's everything you need to know to get started:
Prerequisites: Make sure you are running the latest version of precise, and all your packages are up to date. Unfortunately this cannot be installed on oneiric or any previous ubuntu release.
1) Add the HUD ppa (https://launchpad.net/~unity-team/+archive/hud). You can do this by issuing the following command:
sudo add-apt-repository ppa:unity-team/hud2) Update apt and run a dist upgrade -- this should prompt you to upgrade unity and some indicators
sudo apt-get update && sudo apt-get dist-upgrade3) Restart your unity session by logging out and logging back in again.
The desktop remains central to our everyday work and play, despite all the excitement around tablets, TV’s and phones. So it’s exciting for us to innovate in the desktop too, especially when we find ways to enhance the experience of both heavy “power” users and casual users at the same time. The desktop will be with us for a long time, and for those of us who spend hours every day using a wide diversity of applications, here is some very good news: 12.04 LTS will include the first step in a major new approach to application interfaces.
This work grows out of observations of new and established / sophisticated users making extensive use of the broader set of capabilities in their applications. We noticed that both groups of users spent a lot of time, relatively speaking, navigating the menus of their applications, either to learn about the capabilities of the app, or to take a specific action. We were also conscious of the broader theme in Unity design of leading from user intent. And that set us on a course which led to today’s first public milestone on what we expect will be a long, fruitful and exciting journey.
The menu has been a central part of the GUI since Xerox PARC invented ‘em in the 70′s. It’s the M in WIMP and has been there, essentially unchanged, for 30 years.
We can do much better!
Say hello to the Head-Up Display, or HUD, which will ultimately replace menus in Unity applications. Here’s what we hope you’ll see in 12.04 when you invoke the HUD from any standard Ubuntu app that supports the global menu:
This is the HUD. It’s a way for you to express your intent and have the application respond appropriately. We think of it as “beyond interface”, it’s the “intenterface”. This concept of “intent-driven interface” has been a primary theme of our work in the Unity shell, with dash search as a first class experience pioneered in Unity. Now we are bringing the same vision to the application, in a way which is completely compatible with existing applications and menus.
The HUD concept has been the driver for all the work we’ve done in unifying menu systems across Gtk, Qt and other toolkit apps in the past two years. So far, that’s shown up as the global menu. In 12.04, it also gives us the first cut of the HUD.
Menus serve two purposes. They act as a standard way to invoke commands which are too infrequently used to warrant a dedicated piece of UI real-estate, like a toolbar button, and they serve as a map of the app’s functionality, almost like a table of contents that one can scan to get a feel for ‘what the app does’. It’s command invocation that we think can be improved upon, and that’s where we are focusing our design exploration.
As a means of invoking commands, menus have some advantages. They are always in the same place (top of the window or screen). They are organised in a way that’s quite easy to describe over the phone, or in a text book (“click the Edit->Preferences menu”), they are pretty fast to read since they are generally arranged in tight vertical columns. They also have some disadvantages: when they get nested, navigating the tree can become fragile. They require you to read a lot when you probably already know what you want. They are more difficult to use from the keyboard than they should be, since they generally require you to remember something special (hotkeys) or use a very limited subset of the keyboard (arrow navigation). They force developers to make often arbitrary choices about the menu tree (“should Preferences be in Edit or in Tools or in Options?”), and then they force users to make equally arbitrary effort to memorise and navigate that tree.
The HUD solves many of these issues, by connecting users directly to what they want. Check out the video, based on a current prototype. It’s a “vocabulary UI”, or VUI, and closer to the way users think. “I told the application to…” is common user paraphrasing for “I clicked the menu to…”. The tree is no longer important, what’s important is the efficiency of the match between what the user says, and the commands we offer up for invocation.
In 12.04 LTS, the HUD is a smart look-ahead search through the app and system (indicator) menus. The image is showing Inkscape, but of course it works everywhere the global menu works. No app modifications are needed to get this level of experience. And you don’t have to adopt the HUD immediately, it’s there if you want it, supplementing the existing menu mechanism.
It’s smart, because it can do things like fuzzy matching, and it can learn what you usually do so it can prioritise the things you use often. It covers the focused app (because that’s where you probably want to act) as well as system functionality; you can change IM state, or go offline in Skype, all through the HUD, without changing focus, because those apps all talk to the indicator system. When you’ve been using it for a little while it seems like it’s reading your mind, in a good way.
We’ll resurrect the (boring) old ways of displaying the menu in 12.04, in the app and in the panel. In the past few releases of Ubuntu, we’ve actively diminished the visual presence of menus in anticipation of this landing. That proved controversial. In our defence, in user testing, every user finds the menu in the panel, every time, and it’s obviously a cleaner presentation of the interface. But hiding the menu before we had the replacement was overly aggressive. If the HUD lands in 12.04 LTS, we hope you’ll find yourself using the menu less and less, and be glad to have it hidden when you are not using it. You’ll definitely have that option, alongside more traditional menu styles.
Searching is fast and familiar, especially once we integrate voice recognition, gesture and touch. We want to make it easy to talk to any application, and for any application to respond to your voice. The full integration of voice into applications will take some time. We can start by mapping voice onto the existing menu structures of your apps. And it will only get better from there.
But even without voice input, the HUD is faster than mousing through a menu, and easier to use than hotkeys since you just have to know what you want, not remember a specific key combination. We can search through everything we know about the menu, including descriptive help text, so pretty soon you will be able to find a menu entry using only vaguely related text (imagine finding an entry called Preferences when you search for “settings”).
There is lots to discover, refine and implement. I have a feeling this will be a lot of fun in the next two years
The results so far are rather interesting: power users say things like “every GUI app now feels as powerful as VIM”. EMACS users just grunt and… nevermind . Another comment was “it works so well that the rare occasions when it can’t read my mind are annoying!”. We’re doing a lot of user testing on heavy multitaskers, developers and all-day-at-the-workstation personas for Unity in 12.04, polishing off loose ends in the experience that frustrated some in this audience in 11.04-10. If that describes you, the results should be delightful. And the HUD should be particularly empowering.
Even casual users find typing faster than mousing. So while there are modes of interaction where it’s nice to sit back and drive around with the mouse, we observe people staying more engaged and more focused on their task when they can keep their hands on the keyboard all the time. Hotkeys are a sort of mental gymnastics, the HUD is a continuation of mental flow.
There are other teams interested in a similar problem space. Perhaps the best-known new alternative to the traditional menu is Microsoft’s Ribbon. Introduced first as part of a series of changes called Fluent UX in Office, the ribbon is now making its way to a wider set of Windows components and applications. It looks like this:
You can read about the ribbon from a supporter (like any UX change, it has its supporters and detractors ) and if you’ve used it yourself, you will have your own opinion about it. The ribbon is highly visual, making options and commands very visible. It is however also a hog of space (I’m told it can be minimised). Our goal in much of the Unity design has been to return screen real estate to the content with which the user is working; the HUD meets that goal by appearing only when invoked.
Instead of cluttering up the interface ALL the time, let’s clear out the chrome, and show users just what they want, when they want it.
Time will tell whether users prefer the ribbon, or the HUD, but we think it’s exciting enough to pursue and invest in, both in R&D and in supporting developers who want to take advantage of it.
Other relevant efforts include Enso and Ubiquity from the original Humanized team (hi Aza &co), then at Mozilla.
Our thinking is inspired by many works of science, art and entertainment; from Minority Report to Modern Warfare and Jef Raskin’s Humane Interface. We hope others will join us and accelerate the shift from pointy-clicky interfaces to natural and efficient ones.
There’s still a lot of design and code still to do. For a start, we haven’t addressed the secondary aspect of the menu, as a visible map of the functionality in an app. That discoverability is of course entirely absent from the HUD; the old menu is still there for now, but we’d like to replace it altogether not just supplement it. And all the other patterns of interaction we expect in the HUD remain to be explored. Regardless, there is a great team working on this, including folk who understand Gtk and Qt such as Ted Gould, Ryan Lortie, Gord Allott and Aurelien Gateau, as well as designers Xi Zhu, Otto Greenslade, Oren Horev and John Lea. Thanks to all of them for getting this initial work to the point where we are confident it’s worthwhile for others to invest time in.
We’ll make sure it’s easy for developers working in any toolkit to take advantage of this and give their users a better experience. And we’ll promote the apps which do it best – it makes apps easier to use, it saves time and screen real-estate for users, and it creates a better impression of the free software platform when it’s done well.
From a code quality and testing perspective, even though we consider this first cut a prototype-grown-up, folk will be glad to see this:
Overall coverage rate: lines......: 87.1% (948 of 1089 lines) functions..: 97.7% (84 of 86 functions) branches...: 63.0% (407 of 646 branches)
Landing in 12.04 LTS is gated on more widespread testing. You can of course try this out from a PPA or branch the code in Launchpad (you will need these two branches). Or dig deeper with blogs on the topic from Ted Gould, Olli Ries and Gord Allott. Welcome to 2012 everybody!Read more
In an effort to increase the exposure of the work being done to improve the Unity desktop, we are moving discussions from the code-named #ayatana channel on freenode to the more discoverable #ubuntu-unity channel (still on freenode). If you want to talk to Unity developers, find out what’s happening, or join the growing ranks of community contributors, this is a good place to start.Read more
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.
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.
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?
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.
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.Read more
Back when I first started writing Unity lenses, I lamented the complexity required to get even the most basic Lens written and running. I wrote in that post about wanting to hide all of that unnecessary complexity. Well now I am happy to announce the first step towards that end: Singlet.
In optics, a “singlet” is a very simple lens. Likewise, the Singlet project aims to produce simple Unity lenses. Singlet targets opportunistic programmers who want to get search results into Unity with the least amount of work. By providing a handful of Python meta classes and base classes, Singlet lets you write a basic lens with a minimal amount of fuss. It hides all of the boilerplate code necessary to interface with GObject and DBus, leaving the developer free to focus solely on the purpose of their lens. With Singlet, the only thing a Lens author really needs to provide is a single search function.
So what does a Singlet Lens look like? Here is a sample of the most basic lens, which produced the screenshot above:
#! /usr/bin/python from singlet.lens import SingleScopeLens, IconViewCategory, ListViewCategory from singlet.utils import run_lens class TestLens(SingleScopeLens): class Meta: name = 'test' cat1 = IconViewCategory("Cat One", "stock_yet") cat2 = ListViewCategory("Cat Two", "hint") def search(self, phrase, results): results.append('http://google.com/search?q=%s' % phrase, 'file', self.cat1, "text/html", phrase, phrase, '') results.append('http://google.com/search?q=%s' % phrase, 'file', self.cat2, "text/html", phrase, phrase, '') if __name__ == "__main__": import sys run_lens(TestLens, sys.argv)
As you can see, there isn’t much to it. SingleScopeLens is the first base class provided by Singlet. It creates an inner-scope for you, and connects it to the DBus events for handling a user’s search events. The three things you need to do, as a Lens author, is give it a name in the Meta class, define at least one Category, and most importantly implement your custom search(self, phrase, results) method.
Django developers will notice a similarity between Singlet Lenses and Django Models in their use of an inner Meta class. In fact, they work exactly the same way, though with different properties. At a minimum, you will need to provide a name for your lens. Everything else can either use default values, or will be extrapolated from the name. Everything in your Meta class, plus defaults and generated values, will be accessible in <your_class>._meta later on.
Again borrowing from Django Models, you add categories to your Singlet Lens by defining it in the Class’s scope itself, rather than in the __init__ method. One thing that I didn’t like about Categories when writing my previous lenses was that I couldn’t reference them when adding search results to the result model. Instead you have to give the numeric index of the category. In Singlet, the variable name you used when defining the category is converted to the numeric index for that category, so you easily reference it again when building your search results. But don’t worry, you category objects are still available to you in <your_class>._meta.categories if you want them.
The core functionality of a Lens is the search. So it makes sense that the majority of your work should happen here. Singlet will call your search method, passing in the current search phrase and an empty results model. From there, it’s up to you to collect data from whatever source you are targeting, and start populating that results model.
Unity knows how to handle common URIs in your results, such as file:// and http:// uris. But often times your lens isn’t going to be dealing with results that map directly to a file or website. For those cases, you need to hook into DBus again to handle the URI of a selected result item, and return a specifically constructed GObject response. With Singlet, all you need to do is define a handle_uri method on your Lens, and it will take care of hooking it into DBus for you. Singlet also provides a couple of helper methods for your return value, either hide_dash_response to hide the dash after you’ve handled the URI, or update_dash_response if you want to leave it open.
Once you’ve defined your lens, you need to be able to initialize it and run it, again using a combination of DBus and GObject. Singlet hides all of this behind the run_lens function in singlet.utils, which you should call at the bottom of your lens file as shown in the above snippet.
There’s more to getting your Lens working that just the code, you also need to specify a .lens file describing your lens to Unity, and a .service file telling dbus about it. Singlet helps you out here too, by providing command line helpers for generating and installing these files. Suppose the code snippet above was in a file called testlens.py, once it’s written you can run “python testlens.py make” and it will write test.lens and unity-test-lens.service into your current directory. The data in these files comes from <your_lens>._meta, including the name, dbus information, description and icon. After running make you can run “sudo python testlens.py install”, this will copy your code and config files to where they need to be for Unity to pick them up and run them.
You can get the current Singlet code by branching lp:singlet. I will be working on getting it built and available via PyPi and a PPA in the near future, but for now just having it on your PYTHONPATH is enough to get started using it. Just be aware that if you make/install a Singlet lens, you need to make the Singlet package available on Unity’s PYTHONPATH as well or it won’t be able to run. I’ve already converted my Dictionary Lens to use Singlet, and will work on others while I grow the collection of Singlet base classes. If anybody has a common yet simple use case they would like me to target, please leave a description in the comments.Read more
Unity certainly has been getting a lot of attention in the past year. Love it or hate it, everybody seems to have something to say, whether it’s about the Launcher, application indicators, or the window control buttons being on the left. But with all the talk about Unity, good and bad, one very unique aspect that hasn’t been getting nearly enough attention are Lenses.
Lenses are a central part of the Unity desktop, and anybody who’s used it will be familiar with the default Application and File lenses, maybe even the Music lens. But there’s so much more to this technology than you might think. In fact, David Callé has recently been spearheading an effort to build out a large number of small but incredibly useful lenses. I first took notice of David’s work when he released his Book lens which, being a huge ebook fan, really brought home the usefulness of Unity Lenses for me.
More recently, David has been writing Scopes for the One Hundred Scopes project. A Scope is the program that feeds results into a Lens. While the Lens defines the categories and filters, it’s the Scopes that do the heavy lifting of finding and organizing the data that will ultimately be displayed on your Dash. If you follow David on Google+, chances are you’ve seen him posting screenshots of one scope after another as he writes them, often multiple of them per day.
Seeing how quickly he was able to write these, I decided to dive in and try it out myself. You can write Lenses in a variety of languages, including Python, my language of choice. I decided to start of with something relatively easy, and something that I’ve personally been missing for a while. I used to use a Gnome2 applet called Deskbar, which let you type in a short search word or phrase, and it presented you with search results and various other options. Included among those was the option to lookup the word in the gnome-dictionary, and I used this option on a startlingly frequent basis. Unfortunately Deskbar fell out of favor and development even before the switch to Gnome 3, and I’d been lacking a quick way to lookup words ever since. So I decided that the Lens I wanted was one that would replace this missing functionality, a Dictionary lens.
My first task was to find out how to write a lens. I checked the Ubuntu Wiki and the Unity portal, both of which offered a lot of technical information about writing lenses, but unfortunately not very much that I found helpful for someone just starting off. In fact, I had to get a rather large amount of one-on-one help from David Callé before I could even get the most basic functionality working.
Lenses and Scopes all communicate with each other and with the Unity Dash via DBus, and for anybody not familiar with DBus this makes for a very steep learning curve. On top of that, writing it in Python means you’ll be relying on GObject Introspection (GI), which is a very nice way of making APIs written in one language automatically available to another, but it also means you’re going to be using the lowest common denominator when it comes to language features. I found that learning to work with these two technologies accounted for 90% or more of the time it took me to write my Dictionary lens. Before I write another Lens or Scope, I plan on wrapping much of the DBus and GI boilerplate and wiring behind a simple, reusable set of Python classes. I hope this will help developers, both newbies and seasoned Unity hackers, in writing simple Scopes by allowing them to focus 90% of their time on writing the code that does the actual searching.
But by the end of the day I had a working Dictionary lens. It uses your local spellcheck dictionary, via python-enchant, to both confirm whether or not the word you typed in is spelled correctly, as well as offer a list of suggested alternatives. I also dug through the gnome-dictionary code and found that it was pulling its definitions from the dict.org online database using an open protocol. Using the python-dictclient I was able to query the same database, and include the start of a word’s definition in the Lens itself.
This lens turned out to be more complex than I had originally envisioned, not just for the features listed above, but also because I needed to override what happened when you clicked on an item. When you build up your results, you have to give each item a unique URI, which is often in the form or an http:// or file:// URL that Gnome knows how to handle. But for results that were just words, I needed to do the handling myself, which meant more DBus wiring to have the mouse click event call a local function. From there I was able to copy the word to the Gnome clipboard or launch gnome-dictionary for viewing the full definition.
After seeing that first Lens running in my Dash, I felt an urge to try another. Since I already had all of the DBus and GI code, I wouldn’t have to mess with all of that and I could focus just on the functionality I wanted. Jorge Castro has been trying to get me to write a lens for the LoCo Teams Portal (formerly LoCo Directory) since the concept was first introduced to Unity under the name “Places”. Since LTP already offers a REST/JSON api, this turned out to be remarkably simple to do. Between the existing DBus/GI code copied from my previous lens, and an existing python client library for the LTP, I was able to get a working lens in only a couple of hours.
For item icons, you can use either a local icon, or a URL to a remote image. For this lens, I used the team’s mugshot URL that LTP pulls from the team’s Launchpad information. When you search, it’ll show matching Teams, as well as Events and Meetings for those teams, and any Event or Meeting that also matches your search criteria. I’ve also added the ability for this lens to lookup your Launchpad username (by checking for it in your bazaar.conf) and defaulting it to display the LoCo Teams you are a member of, as well as their upcoming Events and Meetings.
Both the Dictionary Lens and the LTP Lens lump the Lens and Scope code in the same Python class, but it doesn’t have to be this way. You can write a Scope for someone else’s Lens, and vice versa. In fact, plan on separating the LTP lens into a general purpose Community Lens, with an LTP Scope feeding it results about LoCo Teams. From there, others can write scopes pulling in other community information to be made available on the Dash. This will also be my prototype for a Python-friendly wrapper around all of the DBus and GI work that scope writers probably don’t need to know about anyway.Read more
Earlier this week the guys in #ubuntu-tv (on Freenode) generated an Etherpad with their thoughts and then arranged a meeting to discuss priorities. Alan Bell produced some designs: http://people.ubuntu.com/~alanbell/unitytelly/
The mailing list has seen some decent traffic as well, with people talking mostly about what the future of the Connected TV might be and features they’d like to see.
- 10′ interface- Watching Media (DVR, Live, Network(TV Guide is part of DVR/other services))- Control via remote controlHigh priority- Plugin support- Cloud and/or server storage (for home grown media)
- Playback of physical media (USB cd/dvd/bluray drive)
- Installable image
- Easy configuration of new devices (eg. installing same plugins, mounting same network shares)
- Ubuntu One Accounts
- Push media to/from other Ubuntu devices / Media syncing capabilities (Pause on one device, resume from same spot on another device)
- Collaborate with other Ubuntu devices (context: https://lists.launchpad.net/ubuntu-phone/msg00006.html )
- Control from portable devices (phones/tablets/web interface/PC) (collaboration with Ubuntu Phone/Tablet?)
- Sharing media with friends (social network connectivity)
- Purchasing media through online stores (Ubuntu one/Amazon/Netflix)
Not a bad list at all. Thanks to tgm4883, MrChrisDruif, imnichol, callumsaunders1, dmj726 and others.
Separately, reports from a team that may have a crack at implementing the TV interface:
… tracked down some bugs in QML itself, fixed them, and are submitting patches upstream. Next time you read that Qt Mobility now supports hardware accelerated video playback, or how the “ShaderEffectItem” now respects the “clip” property, or simply that the OpenGL video painter renders where it’s supposed to; you know who to thank. As an added bonus this will benefit Unity-2D. Awesome work.
By 14.04 LTS Ubuntu will power tablets, phones, TVs and smart screens from the car to the office kitchen, and it will connect those devices cleanly and seamlessly to the desktop, the server and the cloud.
Unity, the desktop interface in today’s Ubuntu 11.10, was designed with this specific vision in mind. While the interface for each form factor is shaped appropriately, Unity’s core elements are arranged in exactly the way we need to create coherence across all of those devices. This was the origin of the name Unity – a single core interface framework, that scales across all screens, and supports all toolkits.
Canonical and the Ubuntu community have established Ubuntu’s place in desktop, server and cloud deployments. We have also invested in the design and engineering of Unity, motivated by the belief that desktop interfaces would merge with mobile, touch interfaces into a seamless personal computing platform in the future. Today we are inviting the whole Ubuntu community – both commercial and personal – to shape that possibility and design that future; a world where Ubuntu runs on mobile phones, tablets, televisions and traditional PC’s, creating a world where content is instantly available on all devices, in a form that is delightful to use.
The way we access the Internet, connect to our friends, listen to music, watch films and go about our daily lives is rapidly evolving. We now use a diverse set of devices with an array of operating systems, which have a range of connectivity. Few people are exclusively loyal to a single technology provider.
Consider this quote from Paul Maritz of VMWare:
“Three years ago over 95 percent of the devices connected to the Internet were personal computers. Three years from now that number will probably be less than 20 percent. More than 80 percent of the devices connected to the Internet will not be Windows-based personal computers.” Paul Maritz, 29 August 2011 VM World Keynote.
Make no mistake – just as the world is changing for manufacturers so is it changing for Linux distributions. Today, 70% of people in Egypt access the Internet solely via the phone. Even in the US that figure is a startling 25%.
Ubuntu will thrive in this new reality.
Our established collaboration with the silicon vendors that are driving this converging market are critical. Intel, ARM and AMD will make the chip-sets that will power this future and Ubuntu works with all of them on all technologies.
Our engagement with the PC market will help bring the results of this work to a huge audience – partnerships with the likes of Dell, HP, Asus, Lenovo, Acer, IBM, Vodafone and more are a gateway to users who want continuous, connected, cross-device computing.
We are determined to bring more free software to more people around the world, and building that future hand in hand with device manufacturers is the best way to do it. There is no winner in place yet. This opportunity remains wide open, but only to products that deliver excellent experiences for users, across a full range of device categories.
The investment we have already made in the interface accommodates the touch scenarios required in some form factors and, with a little love and attention, will work equally well in mouse, keyboard or stylus-driven environments. Ubuntu will not be restricted to small screen or large screen environments but encompasses both and all the form factors in between. We will see our work on the Ubuntu platform land in a variety of formats current and yet to be invented. It is without doubt the most exciting phase in the history of Ubuntu.
Ubuntu’s personal cloud and app centre services are appropriate for all these environments. They deliver the required storage, syncing and sharing capabilities that are not just a convenience but a requirement as we move to a universe where content is increasingly shared but the devices that access them become more diverse. Ubuntu One’s support for other OSes show the ability of Ubuntu to play nice with others, recognising that the divergence is strength. It allows users to choose the devices they prefer but still delivering the benefits of Ubuntu-centred strategy.
We are describing this at UDS to energize the entire Ubuntu ecosystem around this challenge. Canonical will provide the heavy lifting needed to put us in the ball park, but there are opportunities for participation, contribution and engagement by all elements of the broader Ubuntu community, both corporate and individual.
Our developers, our partners’ developers and the broader open source development community share this opportunity. There is a great deal to discuss, and an array of strands we need to pull together at UDS. But the direction is clear and the prize is great – to bring more free software to more people in more delightful ways than ever before.Read more
We have just finished another design sprint prior to UDS-P.
While talking with some others I realise that I have worked on Unity for six months, and not changed a single pixel on the output. No graphical changes, no moving widgets, no changing colours.
So what have I been doing?
First step was getting some new coding standards accepted by the team, which was much easier than I was expecting.
I added some property classes to nux, and did some general clean up in the code of nux and unity.
Refactored the indicator internals for the panel service which started off the shared unity core library for sharing code between the 2D and 3D code-bases.
Then I focused primarily on fixing memory leaks and crashes.
Once we hit final freeze, I did a little more refactoring internally, and now we are on to Precise Pangolin.
Another edition of the Ubuntu App Developer Week and another amazing knowledge sharing fest around everything related to application development in Ubuntu. Brought to you by a range of the best experts in the field, here’s just a sample of the topics they talked about: App Developer Strategy, Bazaar, Bazaar Explorer, Launchpad, Python, Internationalization, Launchpad Translations, Unity, Unity 2D, Gedit Developer Plugins, the MyApps Portal, the App Review Board, the UbuntuSoftware Centre, Unity Mail, Launchpad Daily Builds, Ubuntu One APIs, Rapid App Development, Quickly, GooCanvas, PyGame, Unity Launcher, Vala, the App Developer Site, Indicators, Python Desktop Integration, Libgrip, Multitouch, Unity Lenses, Ubuntu One Files Integration, The Business Side of Apps, Go, Qt Quick… and more. Oh my!
And a pick of what they had to say:
We believe that to get Ubuntu from 20 million to 200 million users, we need more and better apps on Ubuntu
Jonathan Lange on making Ubuntu a target for app developers
Bazaar is the world’s finest revision control system
Jonathan Riddell on Bazaar
So you’ve got your stuff, wherever you are, whichever device you’re on
Stuart Langridge on Ubuntu One
Oneiric’s EOG and Evince will be gesture-enabled out of the box
Jussi Pakkanen on multitouch in Ubuntu 11.10
I control the upper right corner of your screen
Ted Gould on Indicators
If you happened to miss any of the sessions, you’ll find the logs for all of them on the Ubuntu App Developer Week page, and the summaries for each day on the links below:
The last day came with a surprise: an extra session for all of those who wanted to know more about Qt Quick and QML. Here are the summaries:
In his session, Jussi talked about one of the most interesting technologies where Ubuntu is leading the way in the open source world: multitouch. Walking the audience through the Grip Tutorial, he described how to add gesture support to existing applications based on GTK+ 3. He chose to focus on the higher layer of the uTouch stack, where he explained the concepts on which libgrip, the gesture library, is built upon, such as device types and subscriptions. After having explored in detail the code examples, he then revealed that in Oneiric Eye Of GNOME and Evince, Ubuntu’s default image viewer and default PDF reader, will be gesture-enabled.
Check out the session log.
By Neil Patel
Check out the session log.
Another hands-on session from Michael, with a real world example on how to supercharge apps with cloud support. Using his experience in integrating the Ubuntu One Files API to Deja Dup, the default backup application in Ubuntu, he went in detail through the code of a simple program to talk to a user’s personal Ubuntu One file storage area. We liked Michael’s session so much that it will very soon be featured as a tutorial on developer.ubuntu.com!
By John Pugh
Ubuntu directly benefits from Canonical becoming a sustainable business to support its development, and that’s exactly what John talked about. Being responsible for business development in the Ubuntu Software Centre, he’s got a privileged insight on how to make it happen. He started off explaining that the main goal is to present Ubuntu users with a large catalog of apps available for purchase, and then continued concentrating on how to submit paid applications to be published in the Software Centre. A simple 5-step process, the behind-the-scenes work can be summarized in: Canonical helps packaging the app, it hosts the app and provides the payment via pay.ubuntu.com, in a 80%/20% split. Other highlights include the facts that only non-DRM, non-licensed apps cannot be submitted right now, but there is ongoing work to implement license key support, and that MyApps, the online app submission portal, can take any nearly any content: apps with adverts, “free” online game clients and HTML5 apps.
Check out the session log.
Gustavo’s enthusiasm for Go, the new programming language created by Google shows every time you start a conversation with him on that topic. And it showed as well on this session, in which he created yet another “Hello world” application in a new language -you guessed-: Go. Along the way, he had time to describe all of the features of this new addition of the extensive family of programming languages: statically compiled with good reflection capabilities, structural typing, interfaces and more.
Check out the session log.
By Donald Carr
Check out the session log.
Finally, if you’ve got any feedback on UADW, on how to make it better, things you enjoyed or things you believe should be improved, your comments will be very appreciated and useful to tailor this event to your needs.
Last day of UADW! While we’re watching the final sessions, here’s what happened yesterday:
Creating the concept and implementing a site for app developers is no easy task. The Ubuntu App Developer site is meant to be a place for app authors to get started with development, to find the information they need and to be able to publish their apps in the Software Centre. John explained all the research and user testing that happened behind the scenes, highlighting the key findings, while David focused on the purpose of the site, where it fits in the overall developer strategy for Ubuntu and the plans for the future.
Check out the session log here.
Fitting nicely topicwise with the questions about the default choice of tools for Ubuntu development on the previous session, Michael gave an overview of what Quickly is and how to use it. Going through the workflow of creating your first app with Quickly, he demonstrated all the key commands and explained in detail all the bits in between.
Check out the session log here.
By Rick Spencer
Rick started off the session explaining what GooCanvas and PyGame were good for: providing a 2D surface on which to construct interactive GUIs for users. Beginning with GooCanvas, he showed with a very simple example how to get started playing with 2D composing surfaces, adding images, text and doing other operations such as resizing and calculating coordinates to determine clicks. Next up was PyGame, for the same purpose, but better suited for apps with lots of animation updates without user input. He then wrapped up with three samples of simple games to study.
Check out the session log here.
By Ted Gould
Ted Gould, the man who controls the upper right corner of our screen, talked all about indicators. The idea was to illustrate how to get the information that comes from applications and handle it to the indicators. First up was the messaging menu, a menu to handle human-to-human communication, next the application indicators, which alllow long-running apps to put statuses on the panel consistently, and finally the sound indicator, taking care of all related to sound. Each one of them explained with code examples. Nice!
Check out the session log here.
Marcelo shared his experience acquired with Polly, a Twitter client he developed, on using Python and libraries to let apps provide better integration to the desktop. First explaining the concept of desktop integration, stressing the fact that it’s not only about visuals. The rest of the session was structured around 3 main areas: how to send notifications to the user, where to place files read or written by an app and what to use to store sensitive information. A very clear and solid session, also with example code for easy learning.
Check out the session log here.
Check out the first-class lineup for the last day of UADW:
16.00 UTC – Getting A Grip on Your Apps: Multitouch on GTK apps using Libgrip
Multitouch is everywhere these days, and now on your desktop as well -brought to you by developers such as Jussi Pakkanen, who’ll guide through using libgrip to add touch support to your GTK+ apps. Learn how to use this cool new library in your own software!
17:00 UTC – Creating a Google Docs Lens
Lenses are ways of presenting data coming from different sources in Unity. Neil Patel knows Lenses inside out and will present a practical example of how to create a Google Docs one. Don’t miss this session on how to put two cool technologies together!
18:00 UTC – Practical Ubuntu One Files Integration
Yet again the Deja-dup rockstar and UADW regular Michael Terry will be sharing his deep knowledge on developing apps. This time it’s about adding cloud support to applications: integrating with the Ubuntu One files API.
19:00 UTC – Publishing Your Apps in the Software Center: The Business Side
Closing the series of sessions around publishing apps in the Software Centre, we’ll have the luxury of having John Pugh, from the team that brings you commercial apps into the Software Centre and who’ll be talking about the business side of things.
20:00 UTC – Writing an App with Go
Go is the coolest kid around in the world of programming languages. Gustavo Niemeyer is very excited about it and will be showing you how to write an app using this language from Google. Be warned, his enthusiasm is contagious!
20:00 UTC – Qt Quick At A Pace
A last minute and very welcome addition to the schedule. In his session Donald Carr will introduce you to Qt Quick to create applications with Qt Creator and QML, the new declarative language that brings together designers and developers.
Looking forward to seeing you all there!
Time flies and we’re already halfway through UADW, but there is still much to come! Here’s yesterday report for your reading pleasure:
Starting off with a description of the features of Unity Mail, such as displaying webmail unread message count, notifications and mail subjects, we then learned more about how it was developed and the technologies that were used to create it. It’s written in Python, using GObject introspection (PyGI) and integrates with Ubuntu through the Unity, Notify and Indicate modules. After describing each one in more detail, Dmitry continued talking about how the app can be translated using Launchpad, and how he uses the Bazaar source revision control system to work with code history. Wrapping up, he went through the plans for the future: more configuration options, marking all messages as read and the need for a new icon. Any takers?
Check out the session log here.
Assuming some previous knowledge on Debian packaging, in his session Jelmer walked the audience through a practical example of a basic recipe build for a small project: pydoctor. Drawing the cooking recipe analogy, package recipes are a description of the ingredients (source code branches) and how to put them together, ending up with a delicious Debian package for users to enjoy. Launchpad can build packages from recipes once or automatically on a daily basis provided the code has changed, conveniently placing the result in a PPA. In the last part of the session, he described in detail the contents of an existing recipe and added some notes on best practices when building from a recipe.
Check out the session log here.
The idea bahind the Ubuntu One developer programme is to make it easy to add the cloud to your apps and make new apps for the cloud. With this opening line, Stuart delivered a talk about a high-level overview on the cool things you can do as an app developer adding Ubuntu One support. One aspect it data: for example building applications that work on the desktop, on mobile phones and on the web, securely sharing data among users. Another is music: streaming, streaming music and sharing playlists on the desktop, on mobile and from the web, all through a simple REST HTTP API. He also mentioned some examples of cloud enabled applications: Shutter and Deja-Dup, and many other interesting ways to use Ubuntu One to do exciting thigs with data. And you can get started already using the available documentation.
Check out the session log here.
By Jason Smith
In his talk, Jason first went through the terminology that covers the elements related to the Unity Launcher, and the bachground behind the Launcher API, implemented in the libunity library. Libunity can be used in many programming languages: Python, C, Vala and others supported by GObject Introspection. Going through what you can do with the Launcher (marking/unmarking apps as urgent, setting object counts, setting progress on objects and adding quicklist menu items to the object), he used Vala snippets to illustrate each feature with code.
Check out the session log here.
By Luca Bruno
Vala, a new programming language with C#-like syntax that compiles to C and targets the GObject type system: with a clear statement of what Vala is and what it can do, Luca, a contributor to the project introduced one by one the mostkey features of the language through his “Hello world” example: namespaces, types, classes, properties, keywords and more. As a highlight he mentioned Vala’s automatic memory management using reference counting, andits interoperability with other languages, most notably C, but it can also work with many others supported by GObject Introspection. Other cool featuresto note were also error handling on top of GError, support for async operations, closures and DBus client/server, on each of which he elaborated before finishing the session.
Check out the session log here.
Another day, another awesome set of sessions coming up:
16.00 UTC – Creating an App Developer Website: developer.ubuntu.com
Ubuntu 11.10 will not only bring new features to the OS itself. In time for the release we’ll be launching the new Ubuntu App Developer site, a place for developers to find all the infromation and the resources they need to get started creating, submitting and publishing their apps in Ubuntu. John Oxton, David Planella and many other people have worked to make the next developer.ubuntu.com possible and will tell you all about it.
17:00 UTC – Rapid App Development with Quickly
Quickly is a wrapper that pulls together all the recommended tools and technologies to bring apps from creation and through their whole life cycle in Ubuntu. With an easy set of commands that hide all the complexity for your, it effectively enables developers to follow rapid development principles and worry only about writing code. Michael Terry, from the Quickly development team will be looking forward to guide you through the first steps with this awesome tool.
18:00 UTC – Developing with Freeform Design Surfaces: GooCanvas and PyGame
Have you ever wondered what freeform design surfaces, or canvases are? You probably have now. Well, lucky you then, because Rick Spencer will be here to tell you what they’re good for and how to get started with them
19:00 UTC – Making your app appear in the Indicators
In another session on how to integrate with the platform, Ted Gould, the man who knows most about them, will describe how to add indicator features to your apps, both in terms of panel indicators and messaging menu support.
20:00 UTC – Will it Blend? Python Libraries for Desktop Integration
You certainly will want your app to have that familiar look and feel at home in the OS it’s running on, but you’ll also want it to use all the backend technologies to integrate even deeper and provide a great user experience. Well, fear not, for Marcelo Hashimoto is here to tell you exactly how to do that!
Looking forward to seeing you all there in a few hours!
Another app developer day is over and we’re nearly halfway through the week. Here’s what happened yesterday:
In this session we learned how to link up an app that already has internationalization support to Launchpad Translations, so that it is exposed to Launchpad’s extensive community of translators who’ll effectively make your app speak almost any language. From setting up code hosting for a seamless integration, to setting up the translations settings to tips and tricks for best practices, the presentation should give developers a good grasp of how to start getting their apps translated and ready to reach a wider audience.
Check out the session log here.
An interactive and popular session, in which Florian started describing the main goal behind the Unity 2D project: to run on platforms that do not provide accelerated OpenGL. It essentially is an implementation of the main Unity user interface using the Qt toolkit and the QML declarative language, while reusing the backend technologies from Unity. From there he went on describing the Unity 2D architecture and the release policy, pointing out to the Unity 2D daily PPA, for those testers who want to be on the bleeding edge., and wrapped up answering the questions from the audience.
Check out the session log here.
By Curtis Hovey
Starting off with a description of Gedit plugins, their purpose and how to install them, Curtis delved into the general-purpose plugins and the developer plugins (click to install) plugins, explaining how to set them up and his recommended choice of plugins to convert Gedit in the perfect programming editor. The highlights included the GDP Bazaar integration plug in, which allows working with the bzr source revision control system and others (Subversion, Mercurial, Git), as well as the Source Code Browser plugin, a class and function browser based on Exuberant Ctags.
Check out the session log here.
In another session devoted to the app developer strategy, Anthony told us all about the MyApps webapp developers can use to submit their applications to the Software Center. Available on https://myapps.developer.ubuntu.com, it started off as the need to automate the submission of commercial apps to the Software Centre, expanding to a full-blown online portal that can now tackle any type of submission. He then walked the audience through the 5-step process to send an app for review, including all the necessary metadata and payment details. Once an app has been submitted, it needs to be packaged (if it wasn’t already) and reviewed before being published. Hinting to Jonathan Lange’s session on day 1, Anthony explained that they are looking at providing an automated process for packaging, with the intention of removing the last big remaining manual process.
Check out the session log here.
Complementing the previous session, Stéphane explained how libre+gratis apps can get into the Software Centre and what the App Review Board’s (ARB) role is in that process. He focused on how the Board reviews applications and how other types are distributed in Ubuntu. The types of apps reviewed by the ARB are small, lightweight apps, usually of the type created by Quickly (check out the sessions on Quickly on Thursday!). The next upcoming changes in the way this applications are reviewed will most probably include them being submitted through the MyApps online portal and them being made more secure by wrapping them in a container based on AppArmor or Arkose (or a combination of them).
Check out the session log here.
Check out today’s rocking lineup:
16.00 UTC – Unity Mail: Webmail Notification on Your Desktop
We’re starting to see more and more apps that integrate with Unity. Unity Mail is a cool app that allows you to stay up to date with your web mail directly from your desktop. It supports any IMAP server, but right now it works best with Gmail, along with notifications, message counts, quicklists and more. Dmitry Shachnev will tell us about its features and how he put the application together.
17:00 UTC – Launchpad Daily Builds and Rapid Feedback: Writing Recipe Builds
Launchpad has many awesome features. This time around Jelmer Vernooij will be explaininghow to set up recipe builds for your project in Launchpad, so that users can get the latest updates easily packaged on a daily basis, so that they can install them at a click of a button and can test them and make the feedback loop as short as possible.
18:00 UTC – Using the Ubuntu One APIs for Your Apps: An Overview
Ubuntu One is starting to be everywhere, and it even has its own developer programme. The Ubuntu One website already provides lots of information to developers, and to make it even more clear, Stuart Langridge will walk you through the available Ubuntu One APIs you can use to make your application cloud-ready.
19:00 UTC – Supercharging Your Apps with Unity Launcher Integration
One of the easiest and more visual ways for your apps to blend in with Unity is for it to integrate with the Launcher. Counts, progress indication, quicklists… are an elegant and simple wayto provide feedback to users. Jason Smith knows all about Launcher integration, and he’s really looking forward to share it with us!
20:00 UTC – Hello Vala: An Introduction to the Vala Language
Vala is a powerful programming language that allows modern programming techniques to be used to write applications that run on the GNOME runtime libraries, particularly GLib and GObject. Luca Bruno is part of the team that develops Vala itself, and will be introducing us to the first steps to get started with Vala with the universal “Hello world” app becoming “Hello Vala!”.
Looking forward to seeing you all there in a few hours!
For 11.10 the launcher team worked on a new alt-tab. Here’s how I use it to switch between not only applications, but windows within applications.
(Sorry about the flicker, seems to be a result of recording it)Read more
Alex has found a great workaround for fixing web applications in Unity.
BAMF has been plagued by this bug, which basically means it groups Chromium and Chrome windows under the browser icon. That means my gmail, IRC, music, etc. all get matched as generic browser windows instead of separate applications.
It’s quite easy, you just edit the .desktop that Chromium makes and tell it to make a user profile someplace else and somehow this is enough for BAMF (and therefore Unity) to match the window as a separate application. What’s the result? Finally, each application shows up independantly on the launcher:
Those used to just all file under my Chrome icon. And of course, the big one, alt-tab:
I’ll update my instructions on webapps in Unity later tonight, or an enterprising person can go and update it if you want.
Thanks Alex for finding this workaround, I’ve been crippled by this for a long time, now I just updated a few files. This should tide us over until Trevino gets back from holiday and fixes it for real. (This is a bug I certainly won’t miss).Read more
I was checking out some of the incoming merge proposals from contributors and I noticed a FIXME in a comment and decided to see what’s in the Unity source code that someone might want to check out if they’re looking for something TODO or FIXME.
Turns out it’s not as bad as you’d think,
I’m going to update this list weeklyish, it’s already found some dead code that Neil was able to just purge from the source tree, so if someone wants to go ahead and start going through these and check for low hanging fruit it’d be a nice project for someone who wants to dig in. If the FIXME or TODO is missing a corresponding number then perhaps filing placeholders for them would be useful as well.Read more
Well, we’re a week away from 11.04 so I decided that I would collate the information about Unity on the web and put it into one nice page for everyone to find. Got some more tips you’d like to add? Add them in the comments!
Am I missing any? Post them in the comments. (I will moderate comments for this post to only allow tips and tricks)Read more
© 2010 Canonical Ltd. Ubuntu and Canonical are registered trademarks of Canonical Ltd.