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.

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.

Writing a Singlet

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.

Going Meta

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.

Categorically easy

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 search is on

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.

You can handle the URI

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.

Make it go

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.

Lord of the files

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.

More to come

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.

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.

Some of my readers may react like “WTF? Unity again? After writing ‘no thanks’ post?” But yeah — I spent over month using it. And yes — this is going to be past tense during this week.

In March I got tired of KDE4 and switched to XFCE which served me quite well during Ubuntu 11.04 ‘natty’ cycle. But then I had a feeling that it becomes more and more second citizen in Ubuntu world. All those transitions from GTK+2 to GTK+3 which made some applications look ugly etc.

Then there was this discussion on Canonical internal mailing list where I wrote what do I think about Unity. It was not polite and I am sorry for that. So I decided to give Unity/2D and 3D a longer try.

Unity 2D was interesting environment. Some things were not configurable or hard to find without using gconf-editor and had some issues. I reported few bugs and could not reproduce some of them even:

• Desktop background not restored after switch from text console — had it one day and was not able to reproduce anymore
• Add vertical/horizontal maximize on RMB/MMB

Also I had one issue with Unity/2D and Psi+ running at same time — was looking like Psi+ opened window, Unity composited desktop but did not noticed that window disappeared in meantime:

But as I have graphics card which knows what OpenGL is I decided to make use of it and switched to Unity/3D. This was real change. More configuration options but you have to remember that you should not touch ccsm (Compiz configuration settings manager) which is the only way to configure it.

Why ‘do not touch ccsm’ mantra? Because it is easy to break whole Unity setup with it. But as there is no other way… For example I do not like 2×2 desktop setup which was default but prefer 6×1 one. Or when use wants to change keyboard shortcuts or several other things.

As usual I tried to report what I found:

• After switching desktops I am unable to enter data from keyboard — had to switch windows/desktops just to give focus to proper one
• Only window decoration is shown after un-minimize — had to kill and restart application instead
• App icon on the Unity Launcher lost track of running instance — panel tells that I have gVim open but no way to get into it
• During screen lock windows get moved to other workspaces — nasty when you have a lot of windows and group them on desktops by activity
• Suggestion for “Workspace Switcher”, “Applications”, “Files & Folders” and “Trash” icons — cause not all parts of launcher are equal (more later)
• Privacy problem: on resume Unity bar visible through GDM

Some other things went into #ayatana and #ubuntu-desktop channels on irc where I had several discussions with developers. Some suggested that I must have strange configuration that I have some of my problems. There was even suggestion that I should move to QA team but I hope that no one will take it serious ;D

After that month I can admit that Unity may be usable for many users but I am not one of them. Idea of switching applications not desktops (via Start+[1-0] keys) is nice but I was not able to fully adapt to it. Mostly because I tend to have several windows of same application (terminal, gvim, web browser) and in such case I had more switching as Unity Alt-Tab switcher makes it even worse (you need to use cursor keys in it).

Application menus in top panel was one of first things which I removed. When few windows were present on screen I had several focus changes before I went from right side of screen to menu in panel. Why several? Because I am too used to ‘focus under mouse’ way of selecting windows which is not default Unity way. And even with this enabled I did not find out how to disable ‘bring focused window to front’.

Other thing was side panel (launcher one). There is a way to disable devices icons but no way to disable trashcan or workspaces buttons (which I do not use). Good that other things are configurable — so I set it to 32px width and auto hide if any window wants to take space.

Application runner is hard to use. Press “Start+A”, type “xkill” and tell me what you see? Probably nothing. So run “Alt+F2″ and again type “xkill” — this will work. As interface is same in both situations it may confuse users.

To add application into launcher panel you have to start it first, then find it on panel, get to context menu (usually right mouse button) and select ‘keep in launcher’ option. Different then in other systems but can get used to it.

Systray implementation is weird but it will not be changed as there is a pressure to write indicators instead (if you do not know what it is think “panel applets”). In result some of the applications which I used for years became harder to use (Last.fm official client or Psi+ Jabber client). Some of them could get replaced by other ones or dropped.

What else? Unlocking screen can sometimes take ages^Wminutes. With KDE4 or XFCE I was able to turn on monitor, type password and begin hacking, with Unity desktop I had to remind myself what patience is because often I had to wait 1-2 minutes before ‘enter password to unlock screen’ dialog appeared. Sometimes I even got preview of desktop in meantime (which is privacy unfriendly).

Next week I will check how KDE4 looks like and will have to decide which environment to choose. Maybe will try GNOME 3 next year? Who knows…

All rights reserved © Marcin Juszkiewicz
Used Unity for over a month was originally posted on Marcin Juszkiewicz website

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.

Essential
- 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?)

Medium priority

- Sharing media with friends (social network connectivity)

- Purchasing media through online stores (Ubuntu one/Amazon/Netflix)

 

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.

A constantly changing world

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 is well positioned

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 One and the software centre

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.

The next steps

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.

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:

• Day 1 Summary
• Day 2 Summary
• Day 3 Summary
• Day 4 Summary
• Day 5 Summary (this post)

Ubuntu App Developer Week – Day 5 Summary

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:

Getting A Grip on Your Apps: Multitouch on GTK apps using Libgrip

By Jussi Pakkanen

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.

Creating a Google Docs Lens

By Neil Patel

Neil introduced his session explaining the background behind Lenses: a re-architecture effort of the now superseded Places concept to make them more powerful, provide more features and make it easier to add features through a re-engineered API. Lenses create its own instance, add categories, filters and leave the searching to Scopes. The Lenses/Scopes pairs are purely requests for data, independent of the type of UI, and being provided by the libunity library, they can be written in any of the programming languages supported by GObject Introspection (Python, Javascript, C/C++, Vala, etc.). To illustrate all of this concepts, Neil devoted the rest of the session to a real example of creating a Lens for Google Docs.

Check out the session log.

Practical Ubuntu One Files Integration

By Michael Terry

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!

Check out the session log and Michael’s awesome notes.

Publishing Your Apps in the Software Center: The Business Side

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.

Writing an App with Go

By Gustavo Niemeyer

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.

Qt Quick At A Pace

By Donald Carr

Closing the week on the last -and surprise- session, we had the luxury of having Donald, from the Nokia Qt team, the makers of Qt itself, to talk about Qt Quick. Using a clear and concise definition, Qt Quick is an umbrella term used to refer to QML and its associated tooling; QML being a declarative markup language with tight bindings to Javascript. A technology equally suited to mobile or to the desktop, QML enables developers to rapidly create animation-rich, pixmap-oriented UIs. Through the qtmediahub and Qt tutorial examples, he explored QML’s capabilities and offered good practices for succesfully developing QML-based projects.

Check out the session log.

Wrapping Up

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.

Thanks a lot for participating. I hope you enjoyed it  as much as I did, and see you again in 6 months time for another week full with app development goodness!

Ubuntu App Developer Week – Day 4 Summary

Last day of UADW! While we’re watching the final sessions, here’s what happened yesterday:

Creating an App Developer Website: developer.ubuntu.com

By John Oxton and David Planella

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.

Rapid App Development with Quickly

By Michael Terry

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.

Developing with Freeform Design Surfaces: GooCanvas and PyGame

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.

Making your app appear in the Indicators

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.

Will it Blend? Python Libraries for Desktop Integration

By Marcelo Hashimoto

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.

The Day Ahead: Upcoming Sessions for Day 4

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!

Ubuntu App Developer Week – Day 3 Summary

Time flies and we’re already halfway through UADW, but there is still much to come! Here’s yesterday report for your reading pleasure:

Unity Mail: Webmail Notification on Your Desktop

By Dmitry Shachnev

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.

Launchpad Daily Builds and Rapid Feedback: Writing Recipe Builds

By Jelmer Vernooij

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.

Using the Ubuntu One APIs for Your Apps: An Overview

By Stuart Langridge

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.

Supercharging Your Apps with Unity Launcher Integration

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.

Hello Vala: An Introduction to the Vala Language

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.

The Day Ahead: Upcoming Sessions for Day 3

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!

Ubuntu App Developer Week – Day 2 Summary

Another app developer day is over and we’re nearly halfway through the week. Here’s what happened yesterday:

Making Your App Speak Languages with Launchpad Translations

By David Planella

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.

The Making of Unity 2D

By Florian Boucault

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.

Making App Development Easy: Gedit Developer Plugins

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.

Publishing Your Apps in the Software Center: The MyApps Portal

By Anthony Lenton

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.

Publishing Your Apps in the Software Center: The App Review Board

By Stéphane Graber

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.

The Day Ahead: Upcoming Sessions for Day 3

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!

The Unity team is doing an “Ask me Anything” on Reddit if you want to join in.

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)

Tried Unity, Unity 2D and GNOME3 today. Removed each after <0.5h of playing with them.

Unity? Lack of visible settings. Tried CCSM — chaotic attempt to keep all Compiz settings in one place done in a way to make user say “WTF?”. Managed to crash Unity panels (left, top) after clicking something. Started Gnome-tweak-tool — this one allows to set theme and decoration. Selected least ugly ones, no way to get rid of orange title bars. Did not manage to get rid of icons from desktop… Ok, maybe it has to be that way (sorry for big pictures):

Launcher always lists my permanently mounted partitions (playing with “keep in launcher” option did not changed anything).

Funny situation happens after pressing (aka aka ) key — it should open window with all -installed- recently used, installed, suggested-to-install applications. But what if you did not notice it due to clicking on other window? Panels will switch to transparent:

The whole “let me show you list of apps” looked as strange idea for me — too many clicks required and lot of space wasted. ADW Launcher on 1024x600 screen presents applications list in much better style.

So I logged into Unity 2D — but here I got one box over all windows (I could click though it and it disappeared after re-login):

Clicked few times and decided to avoid — normal Unity had better look.

GNOME3? No comments — I have only FullHD monitor so will not waste screen space for panel which does not even give me usability of older one. Harder to run apps even then under Unity.

So I decided to stay with XFCE. It is not perfect as I have few “sorry, unable to find icon” applets shown (GNOME Bluetooth, NetworkManager, sound) but this bug is known and who knows… maybe will get fixed before release (was fixed before 11.04 and broken again after).

UPDATE: I run Ubuntu 11.10 ‘oneiric’ on all my systems which have some kind of display (other is router which runs 11.04 with 11.10 kernel). I never run stable release cause my systems migrate to next release at start of development cycle as this makes my work easier for me (with 10 years of using Debian ‘sid’ I am able to deal with upgrade problems). Trying other desktops from time to time, usually around Ubuntu beta phase when all features are frozen even if they do not fully work, was fun and allowed me to find new tools for my daily use. But each time I expect some way to configure a look & feel and this is where Unity fails for me.

All rights reserved © Marcin Juszkiewicz
Unity? Thanks, but no was originally posted on Marcin Juszkiewicz website

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).

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,

https://wiki.ubuntu.com/Unity/Bitesize/Opportunities

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.

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!

Getting Started

Home page

Hardware Requirements

• Rick Spencer’s Getting Started (This is a great beginner guide, start here)
• OMG!Ubuntu’s Guide to Unity
• Rick’s Video Guide
• Jorge’s Video Guide to the Dash
• Jorge’s Video Guide to Multitasking
• Unity Photo Gallery

Frequently Asked Questions

Common Questions

• What’s the right terminology for Unity’s UI elements?
• How can I configure Unity?
• Unity Mouse/Keyboard Shortcuts
• Does Unity support disabling the global application menu?
• How do I reset my Unity configuration?
• How do I turn on Unity drag handles?

Launcher and Quick Lists

• What are the custom launchers created for Unity?
• How can I edit/create new launcher items in Unity?
• How do I make a custom launcher for terminal applications?
• How to add my favorite places as a quicklist in my home’s icon in Unity?
• How can I keep recent files from appearing in Unity?
• How do I add a static quicklist that opens a web page?
• How do I put a web application on the Launcher?
• Launcher icon to share files with Dropbox [drag and drop]
• Drag and drop imageshack uploader
• Show desktop icon for the launcher

Indicators and notification area

• How do I access the system tray?
• Adding a weather indicator to the panel
• List of application indicators

Lenses

• What exactly is a “lens”?
• 5 neat Unity lenses in development
• Unity Lens Documentation
• How do I install the Reddit Unity Lens?
• How do I install the Ask Ubuntu Unity Lens, and how do I use it?
• How do I install the Google Books Lens, and how do I use it?
• Is libunity planning on including functions for Unity Lenses?

Developers

For application developers

• Launcher API
• All API Documentation
• What is nux and what’s it used for?

Contributing to Unity

• Get Involved
• How do I build Unity from source?
• Unity Architecture
• Bitesize Bugs (getting started bits of code)
• Coding Style
• Unity’s development visualized in 30 seconds
• I’m a Unity developer ask me anything

Am I missing any? Post them in the comments. (I will moderate comments for this post to only allow tips and tricks)

One of the (great) trends that browsers are doing these days is “getting out of the way”. That is, less “chrome” more space for content. I was curious to how we’ve been improving in this area, so I asked Jason to do some math, and here’s what we came up with.

So, given a desktop that you log in, how many pixels do we consume and how much do we leave for apps? Well, by default here’s how GNOME 2.x, 3.0, and Unity consume your pixels. These are the amount of pixels (broken down by resolution) that these three desktops use:

I measured Unity twice here. By default if there’s nothing in the way, we show you the launcher, if you move a window there or maximize, we get out of the way (the green bar). So, GNOME 2.x takes up a given amount of space no matter what. Unity takes more but gets out of your way once you start using it to about the same level as GNOME 3.0. Notice how both GNOME 3.0 and Unity are already giving the pixels back where they belong, to applications. :)

Next we have how much space we take up when working, for me I maximize my applications.  We maximized the window in GNOME 3.0 by dragging it to the top bar to measure it but didn’t take into account the window decorations and stuff. Still, much better across the board. I only measured Unity once because the launcher in this state goes away.

But wait a minute, doesn’t the application menu belong to the application? Let’s measure how much UI Unity consumes if we give the menu back to the application. So when you maximize an app the only UI Unity uses up is the home button, the window controls, and the indicators. There could still be dead space there in the menu, but that really depends on the length of the menu and per application, and I’m not going to go measure half the archive.

Caveats and Conclusions

a) GNOME 2.x is fat… :)

b) When you use them GNOME 3.0 and Unity are trending towards giving real estate back to applications. (I think this is good)

c) Unity does give the most space back, but remember that’s really all I’m measuring, this doesn’t imply that it’s better (or worse), and it also doesn’t take into account how we actually interact with the desktops, it’s just a raw measurement of pixels. Sorry guys, no flamebait here.

d) We didn’t measure how much space ayatana-scrollbars save you. This would be nice to know.

e) We didn’t take into account overlay-ish things like the dash or the overlay thing that GNOME Shell does. It could very well be that those UI interactions mean that you don’t have to care about those pixels (or care more), but that’s for an expert to figure out, my goal was just to figure out “Is it just me or are desktops following browser chrome trends?”

f) We didn’t take into account full screening applications.

Here’s the spreadsheet if you want to mess with it, or add your favorite desktop. (I didn’t measure KDE)

David Calle has been working on a Books Lens, which lets you search for free books on the internet. The workflow is like this. Super, “Dune”, enter, start reading Dune in Google Books. Neat huh?

Well wouldn’t it be cool if a lens knew what you were looking for before you even start typing?

(Video Link)

The zeitgeist integration isn’t ready yet, but David’s working on it. In the meantime enjoy the current lens and all the books it finds, here’s the PPA.

What an awesome week for application developers. Ubuntu App Developer Week was a week of great speakers, great sessions, great participation, Multitouch, Unity, GObject, Introspection, PyGI, Qt, Qt Quick, QML, Internationalization, KDE, Phonon, Multimedia, Touchegg, Plasma Widgets, Python, Testing, Rapid Prototyping, Thunderbird, GStreamer, Zeitgeist, D-Bus, Ubuntu One, Bazaar, Lenses, Launcher API, Indicators, Launchpad, Translations, Application Review Process, Packaging, pkgme, the Sound Menu, and much much more.

Here’s a recap of the whole week:

• Day 1 Summary
• Day 2 Summary
• Day 3 Summary
• Day 4 Summary

If you happened to miss any of the sessions, simply head to the Ubuntu App Developer Week page where you’ll find the logs for all of them.

Ubuntu App Developer Week – Day 5 Summary

Here comes the last of the summaries for your reading pleasure. Enjoy!

Qt Quick: Extend with C++

By Jürgen Bocklage-Ryannel

In this session Jürgen did another brief intro to Qt Quick: a declarative language to creat user interfaces on top of Qt C++. The subject was to extend it using the C++ language, and for this he introduced QtDeclarative, a UI runtime provided in a Qt module Qt Quick is based on. After this, he walked us through code examples: the first step – include QtDeclarative in the project in order to be able to use it in a C++ main.cpp file. Starting with basic tasks such as changing properties such as the colour of a rectangle from the C++ side, he went into more advanced ones, such as create a new qm element. Even more advanced tasks, such ad creating own elements, were left as a reading exercise with a pointer to the exhaustive Qt Quick documentation and tutorials.

Check out the session log here.

Phonon: Multimedia in Qt

By Harald Sitter

For the third time this week, Harald rocked the house with an entertaining and enlightening session: Phonon, a multimedia abstraction library. First, he showed how to get the environment set up and tools installed; next: an intro to Phonon – an abstraction layer between multimedia apps and a multimedia library backend in the form of a plugin. And next up some coding: the famous 3-line example to create a Phonon-based video player with C++. He showed us how to write a simple audio player, to which then video was progressively added. As a finale he pointed to a way to create a video player with no code at all!

Check out the session log here.

Integrating music applications with the Sound Menu

By Conor Curran

Conor started off explaining that sound menu integration in the next cycle will be made much easier through libunity, and talked a bit about the sound menu spec and the resources for contributors. He then explained that this cycle he concentrated on settling the architecture, making it easier for clients to provide integration. The only thing for a client to care about is to raise an MPRIS interface with a desktop entry, which will then allow it to be shown in the sound menu, and if available, any D-Bus menu items with it. He wrapped up with a description of some of the new features this cycle and an outlook on the next.

Check out the session log here.

pkgme: Automating The Packaging Of Your Project

By James Westby

On to packaging: James introduced pkgme, an almost magic tool to package your application to be distributed to users. Assuming your project uses a standard layout and pkgme has heard of it, it will use one of its backend to create the packaging structure tailored to your layout and toolset. New backends can be created upon request. As the finale, a recursive example: he showed us how to use pkgme to package pkgme itself!

Check out the session log here.

Unity Technical Q&A

By Jason Smith and Jorge Castro

Jason and Jorge started off this exciting session with an introduction to the cool things you can do in Unity: Lenses – bits of pluggable UI to mash up websites and applications in the dash, the Launcher API. After that questions started to kick in: What’s dee? Can you add multiple progress bars to the launcher? What’s the status of progress bars, badges and counters in the launcher? What search backend does the dash use? … if want to know the answer to these and more questions check out the session log

Check out the session log here.

Lightning Talks

By Stefano Palazzo, David Callé, Dustin Kirkland, MeanEye, Christian Muehlhaeuser, Nathan Handler

As the grand finale for a week packed with great sessions, even more concentraded content on a set of lightning talks to showcase cool projects created using the technologies available in Ubuntu: StackExchange App – a Unity Lens designed to work with Ask Ubuntu; Unity Book Lens – a Unity Lens to search through free online libraries; Bikeshed – a breeding ground for new/interesting/even-trivial-but-helpful scripts and programs; Sunflower FM – a twin-panel file GTK+ manager; Tomahawk – a social music player written in C++ and Qt; ClassBot – an IRC bot to help with running classroom sessions in #ubuntu-classroom

Check out the session log here.

Thanks!

I’d like to thank all session leaders for taking the time to prepare awesome content and deliver the sessions, and all participants for their attention and their interesting questions. You all made Ubuntu App Developer Week possible, and a success!

We’ll be back in 6 months time with a newer and cooler App Developer Week edition for you. See you then!