Canonical Voices

Posts tagged with 'unity'

Michael Hall

Will CookeThis is a guest post from Will Cooke, the new Desktop Team manager at Canonical. It’s being posted here while we work to get a blog setup on unity.ubuntu.com, which is where you can find out more about Unity 8 and how to get involved with it.

Intro

Understandably, most of the Ubuntu news recently has focused around phones. There is a lot of excitement and anticipation building around the imminent release of the first devices.  However, the Ubuntu Desktop has not been dormant during this time.  A lot of thought and planning has been given to what the desktop will become in the future; who will use it and what will they use it for.  All the work which is going in to the phone will be directly applicable to the desktop as well, since they will use the same code.  All the apps, the UI tweaks, everything which makes applications secure and stable will all directly apply to the desktop as well.  The plan is to have the single converged operating system ready for use on the desktop by 16.04.

The plan

We learned some lessons during the early development of Unity 7. Here’s what happened:

  • 11.04: New Unity as default
  • 11.10: New Unity version
  • 12.04: Unity in First LTS

What we’ve decided to do this time is to keep the same, stable Unity 7 desktop as the default while we offer users who want to opt-in to Unity8 an option to use that desktop. As development continues the Unity 8 desktop will get better and better.  It will benefit from a lot of the advances which have come about through the development of the phone OS and will benefit from continual improvements as the releases happen.

  • 14.04 LTS: Unity 7 default / Unity 8 option for the first time
  • 14.10: Unity 7 default / Unity 8 new rev as an option
  • 15.04: Unity 7 default / Unity 8 new rev as an option
  • 15.10: Potentially Unity 8 default / Unity 7 as an option
  • 16.04 LTS: Unity 8 default / Unity 7 as an option

As you can see, this gives us a full 2 cycles (in addition to the one we’ve already done) to really nail Unity 8 with the level of quality that people expect. So what do we have?

How will we deliver Unity 8 with better quality than 7?

Continuous Integration is the best way for us to achieve and maintain the highest quality possible.  We have put a lot of effort in to automating as much of the testing as we can, the best testing is that which is performed easily.  Before every commit the changes get reviewed and approved – this is the first line of defense against bugs.  Every merge request triggers a run of the tests, the second line of defense against bugs and regressions – if a change broke something we find out about it before it gets in to the build.

The CI process builds everything in a “silo”, a self contained & controlled environment where we find out if everything works together before finally landing in the image.

And finally, we have a large number of tests which run against those images. This really is a “belt and braces” approach to software quality and it all happens automatically.  You can see, we are taking the quality of our software very seriously.

What about Unity 7?

Unity 7 and Compiz have a team dedicated to maintenance and bug fixes and so the quality of it continues to improve with every release.  For example; windows switching workspaces when a monitor gets unplugged is fixed, if you have a mouse with 6 buttons it works, support for the new version of Metacity (incase you want to use the Gnome2 desktop) – added (and incidentally, a lot of that work was done by a community contributor – thanks Alberts!)

Unity 7 is the desktop environment for a lot of software developers, devops gurus, cloud platform managers and millions of users who rely on it to help them with their everyday computing.  We don’t want to stop you being able to get work done.  This is why we continue to maintain Unity 7 while we develop Unity 8.  If you want to take Unity 8 for a spin and see how its coming along then you can; if you want to get your work done, we’re making that experience better for you every day.  Best of all, both of these options are available to you with no detriment to the other.

Things that we’re getting in the new Ubuntu Desktop

  1. Applications decoupled from the OS updates.  Traditionally a given release of Ubuntu has shipped with the versions of the applications available at the time of release.  Important updates and security fixes are back-ported to older releases where required, but generally you had to wait for the next release to get the latest and greatest set of applications.  The new desktop packaging system means that application developers can push updates out when they are ready and the user can benefit right away.
  2. Application isolation.  Traditionally applications can access anything the user can access; photos, documents, hardware devices, etc.  On other platforms this has led to data being stolen or rendered otherwise unusable.  Isolation means that without explicit permission any Click packaged application is prevented from accessing data you don’t want it to access.
  3. A full SDK for writing Ubuntu apps.  The SDK which many people are already using to write apps for the phone will allow you to write apps for the desktop as well.  In fact, your apps will be write once run anywhere – you don’t need to write a “desktop” app or a “phone” app, just an Ubuntu app.

What we have now

The easiest way to try out the Unity 8 Desktop Preview is to use the daily Ubuntu Desktop Next live image:   http://cdimage.ubuntu.com/ubuntu-desktop-next/daily-live/current/   This will allow you to boot into a Unity 8 session without touching your current installation.  An easy 10 step way to write this image to a USB stick is:

  1. Download the ISO
  2. Insert your USB stick in the knowledge that it’s going to get wiped
  3. Open the “Disks” application
  4. Choose your USB stick and click on the cog icon on the righthand side
  5. Choose “Restore Disk Image”
  6. Browse to and select the ISO you downloaded in #1
  7. Click “Start restoring”
  8. Wait
  9. Boot and select “Try Ubuntu….”
  10. Done *

* Please note – there is currently a bug affecting the Unity 8 greeter which means you are not automatically logged in when you boot the live image.  To log in you need to:

  1. Switch to vt1 (ctrl-alt-f1)
  2. type “passwd” and press enter
  3. press enter again to set the current password to blank
  4. enter a new password twice
  5. Check that the password has been successfully changed
  6. Switch back to vt7 (ctrl-alt-f7)
  7. Enter the new password to login

 

Here are some screenshots showing what Unity 8 currently looks like on the desktop:

00000009000000190000003100000055000000690000011000000183000001950000020700000255000002630000032800000481

The team

The people working on the new desktop are made up of a few different disciplines.  We have a team dedicated to Unity 7 maintenance and bug fixes who are also responsible for Unity 8 on the desktop and feed in a lot of support to the main Unity 8 & Mir teams. We have the Ubuntu Desktop team who are responsible for many aspects of the underlying technologies used such as GNOME libraries, settings, printing etc as well as the key desktop applications such as Libreoffice and Chromium.  The Ubuntu desktop team has some of the longest serving members of the Ubuntu family, with some people having been here for the best part of ten years.

How you can help

We need to log all the bugs which need to be fixed in order to make Unity 8 the best desktop there is.  Firstly, we need people to test the images and log bugs.  If developers want to help fix those bugs, so much the better.  Right now we are focusing on identifying where the work done for the phone doesn’t work as expected on the desktop.  Once those bugs are logged and fixed we can rely on the CI system described above to make sure that they stay fixed.

Link to daily ISOs:  http://cdimage.ubuntu.com/ubuntu-desktop-next/daily-live/current/

Bugs:  https://bugs.launchpad.net/ubuntu/+source/unity8-desktop-session

IRC:  #ubuntu-desktop on Freenode

Read more
Michael Hall

There’s been a lot of talk about Ubuntu’s phone and tablet development over the last year, and it’s great that it’s getting so much attention, but people have been getting the name of it all wrong. Now, to be fair, this is a problem entirely of our own making, we started off talking about the phone (and later tablet) developments as “Ubuntu Touch”, and put most of the information about on our wiki under a page named Touch.  But there is no Ubuntu Touch! It’s not a separate OS or platform, there is only one OS and it’s simply called Ubuntu.

Ubuntu 14.04 Stack

What people are referring to when they say Touch or Ubuntu Touch, is really just Ubuntu with Unity 8.  Other than the shell (and display server that powers it), it’s the same OS as you get on your desktop.

Everything under the hood is the same: same tools, same filesystem, even the same version of them, because it’s all built from the same source. Calendar data is stored in the same place, audio and video is played through the same system, even the Unity APIs are shared between desktop and phone.

So why is the name important?  Not only is it more accurate to call them both Ubuntu, it’s also one of the (in my opinion) most exciting things about having an Ubuntu phone.  You’re not getting a stripped down embedded Linux OS, or something so customized for phones that it’s useless on your desktop.  You’re getting a fully featured, universal operating system, one that can do everything you need from a phone and everything you need from a desktop.

Future Ubuntu Stack

This is the key to Ubuntu’s convergence strategy, something that nobody else has right now. Android makes a terrible desktop OS.  So does iOS.  Chrome OS won’t work for a phone either, nor OSX. Even Microsoft has built two different platforms for mobile and desktop, even if they’ve slapped the same interface on both.

But with Ubuntu, once Unity 8 comes to the desktop, you will have the same OS, the same platform, on all of your devices. And while you will run the same version of Unity on both, Unity 8 is smart enough to change how it looks and how it works to meet the needs and capabilities of what you’re running it on.  Better still, Unity will be able to make these changes at run time, so if you dock your convertible tablet to a keyboard, it will automatically switch from giving you a tablet interface to a desktop interface. All of your running apps keep running, but thanks to the Ubuntu SDK those too will automatically adjust to work as desktop apps.

So while “Ubuntu Touch” may have been a useful distinction in the beginning, it isn’t anymore.  Instead, if you need to differentiate between desktop and mobile versions of Ubuntu, you should refer to “Unity 8″ if talking about the interface, or “Ubuntu for phones” (or tablet) if you’re talking about device images or hardware enablement. And if you’re a developer and you are talking about the platform APIs or capabilities, you’re talking about the “Ubuntu SDK”, which is already available on both desktop and mobile installs of Ubuntu.

Read more
Michael Hall

I’m happy to announce that today I filed for a Feature Freeze Exception to get the latest Unity stack into Ubuntu Raring.  It’s a lot of new code, but it should all be available in a PPA in the next day or so, and it’ll be available there for about two weeks for people to test and provide feedback before it lands.  I won’t go into all of the fixes, performance work and other technical changes, but if you’re interested in what this means for you as a user, keep reading.

Smart Scopes

Discussed during a UDS-style Ubuntu On-Air hangout back in January, Smart Scopes use an intelligent server-side service to decide when they should be used to search.  This allows a single process (the Dash Home) to run a query through only a sub-set of your installed scopes.  It also allows the scopes processes to be terminated when you close the dash, and only re-start those that are likely to produce a relevant result.  As defined by the spec, this service will learn as more people use it, providing more relevant results, so you don’t get unwanted Amazon product results when it should be obvious you’re looking for an application.  It also means fewer running processes on your local machine, and therefore less memory usage overall.

100 Scopes

While there won’t be quite 100 in this release, there will be more scopes installed on the client than in previous releases, and even more that we will be able to implement on the server-side.  Thanks to the Smart Scope Service, these additional local scopes won’t be using up a lot of your system resources, because they’ll only be run when needed, then immediately terminated.  You will be able to install 3rd party scopes, just as before, even ones that the Smart Scope Service doesn’t know about yet.  Plus we will be able to add more server-side scopes during the lifetime of a stable release.  So while we’re not at 100 yet, there is still a large and growing number of scopes available.

Privacy

Now I know I couldn’t get away with talking about changes to the Dash, especially ones that put more of it’s functionality online, without talking about privacy concerns.  With these changes we’ve tried to strike a balance between control and convenience, privacy and productivity.  So while we’re providing more fine-grained controls over what scopes to enable, and whether or not to use the Smart Scope service, the default will still be to enable the services that we believe provides the best user experience on Ubuntu.  In addition, 13.04 has already added more notice to users that their the Dash will search online sources as well as local.

Read more
Michael Hall

UPDATE: A command porting walk-through has beed added to the documentation.

Back around UDS time, I began work on a reboot of Quickly, Ubuntu’s application development tool.  After two months and just short of 4000 lines of code written, I’m pleased to announce that the inner-workings of the new code is very nearly complete!  Now I’ve reached the point where I need your help.

The Recap

First, let me go back to what I said needed to be done last time.  Port from Python 2 to Python 3: Done. Add built-in argument handling: Done. Add meta-data output: Well, not quite.  I’m working on that though, and now I can add it without requiring anything from template authors.

But here are some other things I did get done. Add Bash shell completion: Done.  Added Help command (that works with all other commands): Done.  Created command class decorators: Done.  Support templates installed in any XDG_DATA_DIRS: Done.  Allow template overriding on the command-line: Done.  Started documentation for template authors: Done.

Now it’s your turn

With the core of the Quickly reboot nearly done, focus can now turn to the templates.  At this point I’m reasonably confident that the API used by the templates and commands won’t change (at least not much).  The ‘create’ and ‘run’ commands from the ubuntu-application template have already been ported, I used those to help develop the API.  But that leaves all the rest of the commands that need to be updated (see list at the bottom of this post).  If you want to help make application development in Ubuntu better, this is a great way to contribute.

For now, I want to focus on finishing the port of the ubuntu-application template.  This will reveal any changes that might still need to be made to the new API and code, without disrupting multiple templates.

How to port a Command

The first thing you need to do is understand how the new Quickly handles templates and commands.  I’ve started on some documentation for template developers, with a Getting Started guide that covers the basics.  You can also find me in #quickly in Freenode IRC for help.

Next you’ll need to find the code for the command you want to port.  If you already have the current Quickly installed, you can find them in /usr/share/quickly/templates/ubuntu-application/, or you can bzr branch lp:quickly to get the source.

The commands are already in Python, but they are stand-alone scripts.  You will need to convert them into Python classes, with the code to be executed being called in the run() method.  You can add your class to the ./data/templates/ubuntu-application/commands.py file in the new Quickly branch (lp:quickly/reboot).  Then submit it as a merge proposal against lp:quickly/reboot.

Grab one and go!

So here’s the full list of ubuntu-application template commands.  I’ll update this list with progress as it happens.  If you want to help, grab one of the TODO commands, and start porting.  Email me or ping me on IRC if you need help.

add: TODO
configure: TODO
create: DONE!
debug: TODO
design: TODO
edit: DONE!
license: TODO
package: DONE!
release: TODO
run: DONE!
save: DONE!
share: TODO
submitubuntu: TODO
test: TODO
tutorial: TODO
upgrade: TODO

Read more
Michael Hall

During this latest round of arguing over the inclusion of Amazon search results in the Unity Dash, Alan Bell pointed out the fact that while the default scopes shipped in Ubuntu were made to check the new privacy settings, we didn’t do a very good job of telling third-party developers how to do it.

(Update: I was told a better way of doing this, be sure to read the bottom of the post before implementing it in your own code)

Since I am also a third-party lens developer, I decided to add it to my come of my own code and share how to do it with other lens/scope developers.  It turns out, it’s remarkably easy to do.

Since the privacy setting is stored in DConf, which we can access via the Gio library, we need to include that in our GObject Introspection imports:

from gi.repository import GLib, Unity, Gio

Then, before performing a search, we need to fetch the Unity Lens settings:

lens_settings = Gio.Settings(‘com.canonical.Unity.Lenses’)

The key we are interested in is ’remote-content-search’, and it can have one of two value, ‘all’ or ‘none’.  Since my locoteams-scope performs only remote searches, by calling the API on http://loco.ubuntu.com, if the user has asked that no remote searches be made, this scope will return without doing anything.

And that’s it!  That’s all you need to do in order to make your lens or scope follow the user’s privacy settings.

Now, before we get to the comments, I’d like to kindly point out that this post is about how to check the privacy setting in your lens or scope.  It is not about whether or not we should be doing remote searches in the dash, or how you would rather the feature be implemented.  If you want to pile on to those argument some more, there are dozens of open threads all over the internet where you can do that.  Please don’t do it here.
&nbps;

Update

I wasn’t aware, but there is a PreferencesManager class in Unity 6 (Ubuntu 12.10) that lets you access the same settings:

You should use this API instead of going directly to GSettings/DConf.

Read more
Michael Hall

A few weeks ago, Canonical founder Mark Shuttleworth announced a new project initiative dubbed “skunk works”, that would bring talented and trusted members of the Ubuntu community into what were previously Canonical-only development teams working on some of the most interesting and exciting new features in Ubuntu.

Since Mark’s announcement, I’ve been collecting the names and skill sets from people who were interested, as well as working with project managers within Canonical to identify which projects should be made part of the Skunk Works program.  If you want to be added to the list, please create a wiki page using the SkunkWorks/ParticipationTemplate template and send me the link in an email (mhall119@ubuntu.com).  If you’re not sure, continue reading to learn more about what this program is all about.

 What is Skunk Works?

Traditionally, skunk works programs have involved innovative or experimental projects lead by a small group of highly talented engineers.  The name originates from the Lockheed Martin division that produced such marvels as the U-2, SR-71 and F-117.  For us, it is going to focused on launching new projects or high-profile features for existing projects.  We will follow the same pattern of building small, informal, highly skilled teams that can work seamlessly together to produce the kinds of amazing results that provide those “tada” moments.

Why is it secret?

Canonical is, despite what some may say, an open source company.  Skunk Works projects will be no exception to this, the final results of the work will be released under an appropriate open license.  So why keep it secret?  One of the principle features of a traditional skunk works team is autonomy, they don’t need to seek approval for or justify their decisions, until they’ve had a chance to prove them.  Otherwise they wouldn’t be able to produce radically new designs or ideas, everything would either be watered down for consensus, or bogged down by argument.  By keeping initial development private, our skunk works teams will be able to experiment and innovate freely, without having their work questioned and criticized before it is ready.

Who can join?

Our Skunk Works is open to anybody who wants to apply, but not everybody who applies will get in on a project.  Because skunk works teams need to be very efficient and independent, all members need to be operating on the same page and at the same level in order to accomplish their goals.  Mark mentioned that we are looking for “trusted” members of our community.  There are two aspects to this trust.  First, we need to trust that you will respect the private nature of the work, which as I mentioned above is crucial to fostering the kind of independent thinking that skunk works are famous for.  Secondly, we need to trust in your ability to produce the desired results, and to work cooperatively with a small team towards a common goal.

What kind of work is involved?

We are still gathering candidate projects for the initial round of Skunk Works, but we already have a very wide variety.  Most of the work is going to involve some pretty intense development work, both on the front-end UI and back-end data analysis.  But there are also  projects that will require a significant amount of new design and artistic work.  It’s safe to say that the vast majority of the work will involve creation of some kind, since skunk works projects are by their nature more on the “proof” stage of development rather than “polish”.  Once you have had a chance to prove your work, it will leave the confines of Skunk Works and be made available for public consumption, contribution, and yes, criticism.

How to join

Still interested?  Great!  In order to match people up with projects they can contribute to, we’re asking everybody to fill out a short Wiki page detailing their skill sets and relevant experience.  You can use the SkunkWorks/ParticipationTemplate, just fill it in with your information.  Then send the link to the new page to my (mhall119@ubuntu.com) and I will add you to my growing list of candidates.  Then, when we have an internal project join the Skunk Works, I will give the project lead a list of people who’s skills and experience match the project’s need, and we will pick which ones to invite to join the team.  Not everybody will get assigned to a project, but you won’t be taken off the list.  If you revise your wiki page because you’ve acquired new skills or experience, just send me another email letting me know.

Read more
Michael Hall

When the Unity developers introduced Dash Previews in Unity 6, I knew it was something I wanted to add to Singlet.  I didn’t have time to get the feature added in time to get it into Quantal’s Universe archive, but thanks to Didier Roche and Iain Lane, I was able to get it into Quantal’s Backports archive before the actual release date, so it will be available to all Ubuntu users right away.

Previews for all!

One of the main goals of Singlet, second only to making it easy to write Unity lenses and scopes, was to automatically add new features to any lenses and scopes written with it.  Previews are my first opportunity to put this into practice.  Singlet 0.3 will add Preview information for any Scope or SingleScopeLens written for Singlet 0.2!  To do this, Singlet 0.3 will use the same image, title and description used in the search results to populate the preview.  This is a big improvement over having no preview at all, and there is absolutely nothing the developer needs to do. Even better, if you have a custom handle_uri method, it will also add an “Open” button to your preview which will call it.

Better, faster, simpler Previews

Getting previews for free is nice, but it does limit the preview to only the information you are giving to the result item.  But the Previews API allows you to do so much more, and Singlet lenses and scopes can take full advantage of them.

The simplest way to add more data to your preview is to add a method to your Scope or SingleScopeLens class called add_preview_data.  This method will be called whenever Unity needs to show a preview for one of your result items, and will be given the specific result item being previewed, as well as a reference to the Unity.Preview object itself.

def add_preview_data(self, result_item, preview):
    if result_item['category'] == self.lens.events:
        url_parts = result_item['uri'].split('/')
        event = self._ltp.getTeamEvent(url_parts[5])
        venue = self._ltp.getVenue(event['venue'])
        if 'latitude' in venue and 'longitude' in venue:
            preview.props.image_source_uri = 'http://maps.googleapis.com/maps/api/staticmap?center=%s,%s&zoom=11&size=600x600&markers=%s,%s&sensor=false' % (venue['latitude'], venue['longitude'], venue['latitude'], venue['longitude'])

The result_item is a Python dict containing the keys ‘uri’, ‘image’, ‘category’, ‘mime-type’, ‘title’, ‘description’, and ‘dnd-uri’, the same fields you added to the results model in your search field. The code above, added to the LoCo Teams scope, sets the Preview image to a Google Maps view of the venue’s location. You can also add additional Preview Actions from within this method.

If you want even more control, you can instead add a method called simply preview to your class, which takes the result_item and the full result_model from your scope, letting you create a Unity.Preview object yourself, and doing whatever you want with it.

def preview(self, result_item, result_model):
    preview = Unity.GenericPreview.new(result_item['title'], result_item['description'], None)
    preview.props.image_source_uri = result_item['image']

    some_action = Unity.PreviewAction.new("do_something", "Do Something", None)
    some_action.connect('activated', self.do_something)
    preview.add_action(some_action)

    return preview

Read more
Michael Hall

Following yesterday’s announcement of the Ubuntu Webapps project, I really wanted to find a way to try it out on a website.  I chose my personal blog (this one) as my guinea pig.

Since this site is powered by WordPress, it seemed that the best way to add Ubuntu Webapps integration was to make a plugin.  Now I’m not a big fan of writing WordPress backend code, not only is it PHP but I’ve found the API documentation lacking and the actual API implementation a bit of a mess.

However, after only a few hours of work (90% of which was spent trying to get the WP API to work), I had a very basic plugin that would export all my published pages to the Unity HUD.  If you have already installed the Ubuntu Webapps preview, you should have been asked if you want to integrate this site already.  If you did, you will get this in your HUD:

The code is licensed under the AGPLv2, and can be branched from my bazaar branch.

To install it, just copy the ubuntuwebapps.php file into your wp-content/plugins/ directory, then activate the plugin from the WP admin.  And remember this is 0.1 code that is mere hours old.  You have been warned.

Read more
Michael Hall

As you’ve probably heard already, Ubuntu is running an App Developer Showdown competition where contestants have three weeks to build an Ubuntu app from scratch.  The rules are simple: It has to be new code, it has to run on Ubuntu, and it has to be submitted to the Software Center.  The more you use Ubuntu’s tools, the better your chances of winning will be.  This week we ran a series of workshops introducing these tools and how they can be used.  It all seemed like so much fun, that I’ve decided to participate with my own submission!

Now 2 our of the 6 judges for this competition are my immediate co-workers, so let me just start off by saying that I will not be eligible for any of the prizes.  But it’s still a fun and interesting challenge, so I’m going to participate anyway.  But what is my entry going to be?  Well in my typical fashion of building tools for tools, I’ve decided to write a GUI wrapper on to of Quickly, using Quickly.

Before I started on any code, I first wanted to brainstorm some ideas about the interface itself.  For that I went back to my favorite mockup tool: Pencil.  I knew I wanted to cover all of Quickly’s functions, both for creating projects and working on them afterwards.  I also wanted something that would keep track of my projects, so I wouldn’t have to find where they are on my disk whenever I wanted to hack on them.

Now, I’ve never been a fan of GUI builders.  Even back when I was writing Java/Swing apps, and GUI builders were all the rage, I never used them.  I didn’t use one for Hello Unity, and I wasn’t planning on using Glade for this project either.  But after Jono’s fantastic workshop session about Glade, I decided to give it another chance.  I found that I was able to get a basic UI built and running in very little time.  I’m still struggling with some, and there’s a point where you need to switch from Glade to code, but all in all it has saved me a significant amount of time.

Quickly also saved me a large amount of time, both in creating the project and adding things too it.  Being able to add an Application Indicator to your app by just running “quickly add indicator” is amazing.  From there is was a simple matter to build a menu based on available Quickly commands and tie them in with callback functions.

But the part I like the best about this app so far, is that it’s useful even when you’re not using it.  Most of the time you spend developing a Quickly app is going to be in some other application, such as your code editor of choice, Glade or something.  Thanks to Unity’s HUD, and the fact that it’s smart enough to check Indicator menus in addition to the focused application’s menus, you can call your Quickly commands any time, simply by tapping ‘Alt’ and the command you want to run.  It’s like having Quickly integrated into all of your other tools.

And thanks to the developer tools available in Ubuntu, I was able to accomplish all of this in only a few hours of work.

Now it’s very, very far from being complete.  For instance, the “active” project is hard-coded to my quickly-gtk working directory, it can’t start a project yet, or support commands that take optional arguments or user input.  But in a short amount of time I was able to go from a mockup to a working layout and even some functional code.  It even packages successfully, something I found out quite by accident when I selected “Share” from the indicator menu and ended up with a package in my PPA.

Building an app in 4 hours then accidentally building a proper package and uploading it to a PPA, who’d have thought we’d ever make it that easy?  I hope you all are having as much fun and success in your showdown applications as I am.

Read more
Michael Hall

With the Ubuntu TV port to Unity 3d currently underway, the project team is looking towards future feature development and they want the community’s input on what the product should do.  Specifically they are gathering a list of use cases that consumers might want in a Smart TV in five key areas:

  • Local/networked media
    • How should Ubuntu TV interface with media on the local device or local network?
  • Online media
    • How should Ubuntu TV find and play online media?
  • Control from another device (smartphone, tablet etc.)
    • How can you use your existing phone or table to interface with your TV?
  • Broadcast (LiveTV, PVR)
    • How should Ubuntu TV list, store and playback live TV?
  • Applications
    • What types of applications would be useful on a TV?

So here’s your chance to get involved and be heard, go to this wiki page and start adding your use cases to the list.

 

 

Read more
Michael Hall

My big focus during the week of UDS will be on improving our Application Developer story, tools and services.  Ubuntu 12.04 is already an excellent platform for app developers, now we need to work on spreading awareness of what we offer and polishing any rough edges we find.  Below are the list of sessions I’ll be leading or participating in that focus on these tasks.

And if you’re curious about what else I’ll be up to, my full schedule for the week can be found here: http://summit.ubuntu.com/uds-q/participant/mhall119/

Read more
Michael Hall

Ubuntu 12.04, the Precise Pangolin, is scheduled to be released in a little over a week.  This is a very exciting release for us, not only is it an LTS release with 5 years of support, but it also brings some major improvements to Unity and other areas of the desktop.  It’s also going to see a very big focus on independent application developers.

Developers, Developers, Developers!

During the last six months we’ve spent a lot of time building tools and documentation for app developers.  In September of 2011 we launched the Ubuntu Developer Portal, a site dedicated to helping application developers target the Ubuntu platform, and for getting their applications distributed through Ubuntu.

The developer portal provides all the information an app developer needs to write apps for Ubuntu.  It will get you started with tools like Quickly, tell you what languages, toolkits and IDEs are available, and introduce you to the tools and workflows that make developing for Ubuntu a joy.

Once your app is ready, the Developer Portal will walk you through packaging it and submitting it to be published in the Ubuntu Software Center.  The MyApps section lets you upload and manage all your applications, provide branding and screenshots, and set your purchase price.

Going Native

In the past couple of months we’ve added extensive documentation on Unity integration, which allows your application to become part of the desktop experience.  The Unity APIs give your application a presence in multiple areas of the desktop, letting you to add extra information to the Launcher, indicators in the panel, search results in the Dash and more.

All about the Apps

Everybody knows that “Apps” are the big thing now.  No longer relegated to tablets and smartphones, “App Stores” are coming to both major proprietary desktop operating systems as well.  The Ubuntu Software Center already supports independent free and paid app downloads, and with 12.04 we want to grow that segment exponentially.

Not only do we provide a rich platform for app developers to target, we also have the means of delivering those apps directly to over 12 million users worldwide.  With Unity, your app isn’t just visible in the Ubuntu Software Center, but we put it right in the Dash!  Your app will show up whenever the user searches their system for something similar, giving it a level of visibility that no other platform offers.

Join the conversation

Developing applications for Ubuntu doesn’t have to be something you do in isolation.  Having a strong community is an important aspect in today’s software market, and Ubuntu provides you with the tools for collaborating with the existing Ubuntu user community and for growing a strong user community around your own application.    These users can help grow your app by add translations, identify bugs, and even submitting patches.

We’re also building a vibrant community of app developers, and we want you to be a part of that.  Learn tips and tricks from other app developers, share your own expertise and build professional connections.  Here you will also find a number of Ubuntu and Canonical developers who will take your suggestions and feedback for making app development on Ubuntu even better.

Read more
Michael Hall

Hello Unity is now open for translations!

Please help me make this technology showcase is available to application developers in your native language.  Translations are done through Launchpad, and will be built into the Hello Unity package.

Read more
Michael Hall

I spent some more time over the weekend working on Hello Unity.  If you haven’t already, be sure to read my first post about it.  In short, Hello Unity is a showcase application that demonstrates all the different ways an application developer can integrate their app with the Unity desktop.

The current version of Hello Unity sports a new syntax-highlighted code display, which makes it much easier to read and understand what the code is doing.  I also spent a significant amount of time going through and heavily commenting the code to explain what everything was doing.

In the Launcher section I added support for setting the “urgent” status of the application.  In Unity, this will cause the application’s icon in the Launcher to shake and, if the Launcher is set to auto-hide, will also cause the icon to slide out into view while it shakes.  This is a very useful way of telling a user that your application needs their attention.

A new section was added for integrating with the Message Menu.  It automatically adds a Hello Unity section to the menu, and allows you to add count indicators to it.  Clicking on an item in the menu will execute the code for removing it.  All of this is explicitly commented on in the source code.

Another new section is for Notifications.  While it uses the generic libnotify API, it does highlight how to use it with Ubuntu’s Notify-OSD display system, including how to updated and append text to the currently displayed notification.

Once again, if you are interested in contributing to this project, you can get the code from the Launchpad project page.  Also available there are source tarballs and installable .DEB files.

Read more
Michael Hall

David Planella and I have spent the past couple of weeks gathering, cleaning and verifying Unity integration documentation that has existed on the Ubuntu wiki, individual blogs and inside the source code itself.   After publishing those docs, a couple of people asked for some kind of simple “hello world” type of application to show off how all that integration works.

So, I made one.

You can get the code from Launchpad:

bzr branch lp:hello-unity

It’s not complete yet, but it’s a start.  Let me know if you’re interesting in contributing to it.

Read more
Michael Hall

Everybody knows that programmers can contribute to Unity, and I’ve shown in my previous posts that non-developers can still contribute features and fixes that make applications integrate better.  But what if your skills lay more on the creative side of the spectrum?

Well it just so happens that you have something to contribute to Unity too.  In fact, we’re currently in need of some graphic design talent to put some extra polish on some areas of application integration.  Specifically, we need people to help create vector art for application icons that only have raster images, PNG, XPM, etc.

This wiki page contains a list of applications that have been identified as needing an SVG icon.

Now graphic creation isn’t my specialty, so I’m not going to write a step by step guide to creating these images, that’s up to you artists.  What I am going to do, however, is walk you through the process of coordinating with the upstream application developers and submitting your finished image to Ubuntu.

1) Contact the upstream

This is an important step, because even if an application doesn’t have an SVG icon in Ubuntu, there’s still a chance that one already exists.  Read over the first half of my post on upstreaming Quicklists for ways to get in contact with with them. Ask them if they have an SVG  source for their application’s icon.  If they do, that’s great! You can take that and skip down to step #3.  If they don’t, then you will need to work with the upstream project to create one that is right for them.

2) Work with the current image

It’s important that we don’t try and re-brand an application unless the authors want it re-branded.  What we want is a more flexible/scalable version of the image icon we already have.  If you are creating a new SVG file, try to keep as close to the raster image as possible, and be sure to talk to the upstream developers about any deviations or changes you need to make.  And finally, keep with the spirit of open source and make your new image available to both Ubuntu and the upstream project under a copy-left license like the CC-BY-SA or another permissive license of the upstream’s preference.

3) Preparing your image

Since we are getting close to the release of 12.04, the requirements for any further changes are getting stricter.  In order to get your image into the Precise packages, you will need to meet the following two criteria:

It must be approved by the upstream project.  Since your image will be representing their application in Ubuntu, we absolutely need their acceptance of it before it can be used.  This is why step #1 is so vitally important, make sure you are working and communicating closely with upstream from the very beginning.

It must be a plain SVG file.  This is because it will be added as a patch file against the package, and patch files don’t work well with binary data.  Since a plain SVG file is text, not binary, it makes it much easier to convert into a patch.

4) Submit your new image

The wiki page containing the list of applications has a link to the corresponding bug report filed in Launchpad.  When your image is ready, attach it to the bug report.

You will also need to add the upstream project to the bug report.  Click the “Also affects project” link on the bug page, and choose the Launchpad Project that matches your upstream.

That’s it!  Well, almost.  Once we have your image, the application’s package in Ubuntu will need to be updated to use it, but that will require some changes to packaging scripts and patch files, which will be the subject of a more technical post.  But getting the necessary image is itself a big step.

Read more
Michael Hall

Bazaar is a great tool for distributed development, but distros are built on packages, and so packages are what distro developer care about.  That’s why many of you who have followed my previous blogs have probably been asked for patches to the package itself, not to the bzr branch.

Why the difference?  Well for package maintainers, it’s easier and faster to import  upstream changes if they keep their source code clean.  To do that, any changes made by the distro are applied on top of the unmodified upstream code in the form of patches.  There are many tools designed specifically to make this easy for the package maintainers.

Below I’m going to show you how to turn your code change into a package patch that is easy for Ubuntu developers to add to the distro’s packages.  Only do this if your submitted branch is to a package in main and it hasn’t already been merged.

0) Check your source package format

The following instructions will only work on source packages using quilt 3.0 for managing patches.  Before you do anything else, check that the file debian/source/format contains the following:

3.0 (quilt)

 

1) Find your revisions

Starting from your existing code branch, we first need to identify which revisions in your branch we need to turn into a patch.  To do that, we simply check for revisions in your branch that don’t exist in the main one.  Here is what I used for geany:

bzr missing --mine-only ubuntu:geany

You just need to replace ‘geany’ with your application’s branch name (the same you bzr branched in my earlier articles).  The –mine-only will limit the result to only revisions in your branch just to keep things simple.  You’ll want to make note of the first and last revisions in this output.  If, like me, you only had one revision missing, that makes it even easier.

 

2) Generate the patch

Fortunately the package “bzr-builddeb” provides a command that makes this step easy.

mkdir -p debian/patches
bzr dep3-patch -d ubuntu:geany . > debian/patches/add_keywords.patch

Again, just replace ‘geany’ with your application’s branch name, and dep3-patch will find the differences in your branch and convert them into a patch file.

Now that you have a patch file, we need to add it to the list of patches for this package.  To do that, all you need is to add it’s name to the end of the debian/patches/series file like this:

echo add_keywords.patch >> debian/patches/series

 

3) Convert your source changes

Now that your changes are in a patch file, we need remove those changes from the source code itself.  This is where those revision numbers from step 1 come in, you will need the highest revision number and one less than the lowest.  Since I only had one revision, rev 32, my numbers are 32 and 31.

bzr diff -r 32..31 | bzr patch

This causes bzr to generate a reverse-diff of your changes (by going from the higher to the lower revision), and then apply that reverse-diff to your current code, effectively undoing your changes.

Now you need to apply your new patch file using quilt, so that quilt knows about it:

quilt push -a

Which should give you the following output if everything applies cleanly (if not, then your package is going to need some extra work, and you should ask for help from someone in #ubuntu-devel on freenode IRC).

Applying patch add_keywords.patch
patching file geany.desktop.in

Now at patch add_keywords.patch

 

4) Log your changes

Since you are making changes to the package itself now, you need to add that information to the debian/changelog:

export DEBFULLNAME="Michael Hall"
export DEBEMAIL="mhall119@ubuntu.com"
dch -i

You will, of course, want to replace my name and email with your own (Hint: you can put those 2 export lines into ~/.bashrc for future packaging work). This will create a new entry in the chanelog for you, with one higher version number.  All you need to do it add in the comments:

* Add search keywords to .desktop file (LP: #942154)

Be sure to use the proper bug number for your changes.  Also, if you are not running on Precise, you  will need to change the release target at the top of the file to ‘precise’.  Here’s what my new record looks like:

geany (0.21.dfsg-1ubuntu4) precise; urgency=low

* Add search keywords to .desktop file (LP: #942154)

-- Michael Hall <mhall119@ubuntu.com> Wed, 07 Mar 2012 14:40:32 -0500

 

5) Commit and push

Now it’s time to put everything back into your bzr branch.  First you need to add your patch file:

bzr add debian/patches/add_keywords.patch
bzr add debian/patches/series
bzr add .pc/

If your package branch didn’t already have a ‘series’ file, my instructions in step 2 will have created one, so I’m adding it here just in case.  If it already existed, bzr add won’t do anything.

Next, commit and push your changes back to your submitted branch:

bzr commit -m "Convert source changes into a package patch file"
bzr push lp:~mhall119/ubuntu/precise/geany/add_keywords

 

Read more
Michael Hall

It’s sometimes easy to talk about “Ubuntu developers” as if they are some faceless “others” who are separate from “Ubuntu users”.  But the reality is that the line between user and developer isn’t quite as clear as many people imagine.

In the response to my recent posts, this mixing of user and developer has become even more clear to me, and I wanted to share it with everybody.  These are the faces of some of the many non-developer users who make Ubuntu better for you.

Nekhelesh Ramananthan

Nekhelesh was one of the first contributors to respond to my postings, and he never slowed down.  He has contributed multiple additions of Quicklists and Keywords, improving the Unity integration for many popular applications.

Trenton Fox

Trenton was another early contributor, creating Quicklists for several of the applications I had targeted for better Unity integration.

David Baucum

David is a long-time member of of my own LoCo Team, so I was thrilled to see him submitting patches to Ubuntu apps.  He was also one of the first to have his contributions land in Ubuntu 12.04.

If you should happen to run into any of these guys online or in real life, be sure to thank them for making Ubuntu better for you.

Read more
Michael Hall

After all the terrific feedback and contributions we received from community contributors as a result of my Quicklists article, I’ve been asked to talk about how to contribute to improving another feature of Unity, the Applications Lens.

Search is the heart of the Unity Dash, and making search better is great way to contribute to the overall quality and usability of Ubuntu.  And just like Quicklists, there are ways you can do this without being a developer.  In this article, I will show you how to add Keywords to an application that will be used by the Dash’s search function.

Just like in my previous tutorial on Quicklists, I will once again be using Geany as my example application since it is one of my most-used programs.  Geany will be found in a search for “IDE” or “Development”, thanks to those words being in the Comment and GenericName fields of it’s .desktop file.  However, I think it should also be found in a search for “Code” and “Programming”, which it currently does not.

Step 0: File bug reports

This wasn’t part of the Quicklist tutorial, because I had already  filed bugs for the apps we were targetting.  But this time there is no list, so it’s up to you to make sure there is a bug report.  For ubuntu, you can file it against:

https://bugs.launchpad.net/ubuntu/+source/<source_name>/

It’s equally important to file a bug in the upstream’s Bug Tracker.  Refer to the stems up my post about upstreaming your quicklists for how to find your upstream.

Once you  have your bugs filed, post a link to them in the comments so that others know you are working on them.

Step 1: Getting the package code

Everything in Ubuntu exists in bzr, which makes getting the source for the package easy.  just “bzr branch ubuntu:<project>”.  For geany, this is what I ran:

bzr branch ubuntu:geany

If you followed the Quicklist tutorial, you’ll have already done this.  However, if your merge proposal hasn’t been accepted yet, it’ll be easier to do these changes on a clean branch.  You can give the name of a new directory for this checkout by running:

bzr branch ubuntu:geany ./geany-keywords

Step 2: Adding keywords

Again, just like with Quicklists, you first need to locate the .desktop file for your application.  For me, it was located in the root of the branch in a file called “geany.desktop.in”.  If you don’t see it in the root of your project’s branch, try running this command:

find ./ -name "*.desktop*"

This may not look exactly like the file in your /usr/share/applications/, since some processing is done to add translated strings for the application name and comments.  But as long as you are just adding the Keywords item to the bottom of the file you shouldn’t have to worry about that.

Next you  should look for deprecated keyword fields.  ”Keywords” is a new part of the XDG specification, but your application may have already been using the desktop-specific field “X-GNOME-Keywords”.  If it does, go ahead and rename it to “Keywords”.  Also check for the existence of fields starting with an underscore, like “_Name”.  If your .desktop file has those, that means it’s probably setup for translations already, and you should use “_Keywords” instead, so that they can be translated as well.

For geany, there was no existing Keywords field of any kind, but it was setup for translations, so I used the following:

mhall@mhall-laptop:~/projects/Ubuntu/unity/quicklists/geany$ bzr diff
=== modified file 'geany.desktop.in'
--- geany.desktop.in	2012-02-24 19:30:41 +0000
+++ geany.desktop.in	2012-02-27 18:31:39 +0000
@@ -10,3 +10,4 @@
 Categories=GTK;Development;IDE;
 MimeType=text/plain;text/x-chdr;text/x-csrc;text/x-c++hdr;text/x-c++src;text/x-java;text/x-dsrc;text/x-pascal;text/x-perl;text/x-python;application/x-php;application/x-httpd-php3;application/x-httpd-php4;application/x-httpd-php5;application/xml;text/html;text/css;text/x-sql;text/x-diff;
 StartupNotify=true
+_Keywords=Code;Editor;Programming;

Step 3: Submitting to Ubuntu

Now you need to send your changes to Ubuntu.  This is very similar to what we did for Quicklists, but I’ve added one extra piece to the commit command.

bzr commit -m "Add Keywords to .desktop file" --fixes lp:942154
bzr push lp:~mhall119/ubuntu/precise/geany/add_keywords

By passing the –fixes flag, along with your Launchpad bug #, to the bzr commit command, you will automatically link your new branch with the bug report you created in step 0.

The next step is to once again propose that your changes be merged into the Ubuntu package. To do that, run the following command to open the Launchpad page for your new branch:

bzr lp-open

On that page you’ll see a link labeled “Propose for merging”, click that and fill out the form on the next page to create your merge proposal.

Step 4: Submitting to Upstream

The final step is to send your changes upstream as well.  This is good practice whenever you are making changes, plus it makes it easier for Ubuntu’s package maintainers.  Since every upstream is different in how they want to get submissions, I recommend following my previous upstreaming tutorial for this step.

Read more
Michael Hall

There has been a fantastic amount of feedback and contributions being made by folks who have been following my recent posts, and we’ve already had some of those contributions landing in Ubuntu 12.04.  But we’re not done yet!

Ubuntu means “I am who I am, because of who we all are”.  In a very literal sense, Ubuntu is what it is, because of what other distros are.  We all bring together the best open source software from upstream developers, and we should all be giving our improvements back to those developers.  Unity may be the default desktop on Ubuntu, but it’s also been ported to ArchLinux and SuSe, and is making it way to Fedora too.  That means that your Quicklist contribution can help more than just Ubuntu, all you need to do is submit it upstream.

Step 1: Find your Upstream

While all of Ubuntu’s package sources use Launchpad, and are therefore all in the same place, your upstream developers will all of their own separate spaces.  Some are rather easy to find, for example Firefox is developed over on mozilla.org.  Others may use GitHub, SourceForge, or their own sites.  So you first task if to find out where the code is developed.

Step 2: Talk to your Upstream

Once you’ve found their development home, look for ways of contacting the developers.  Usually there will me an email/mailing list available, an IRC channel or a forum.  Whatever method they prefer, us it to ask the developers how they want you to submit your patch.  Most developers love being contacted by somebody who already has a patch written.

Step 3: Submit your changes

Depending on your upstream’s development process, they may want a patch file with your changes, or they might ask you to use their version control system of choice (svn, git, etc) to submit your change in a way that is easy for them to merge.  Some, especially Debian, may request a patch for the package itself.  This is why Step 2 is so important, you need to know how to submit it in order for it to be accepted.  Don’t worry if you don’t know how do what they want, ask them to help you learn it.  Again, developers like people who come to them with patches.

For Geany, I first found their website, geany.org, and from there a link to their Feature Tracker on SourceForge.  I also found their IRC channel, #geany on freenode, and was in contact with their developers there.  In the end, I was asked to create a fork of their code on GitHub, and submit my change as a Pull Request.

Step 4: Updated your Merge Proposal

Once you’ve submitted you changes upstream, leave a comment to that effect in your merge proposal.  Ubuntu developers don’t like to keep custom changes in Ubuntu, and your merge proposal is much more likely to be accepted if they know the change will eventually be made in the upstream project as well.

Step 5: Stay involved with your Upstream

If you were working on a program you like, don’t let this be the end of your contribution!  You now have experience making and submitting changes (to both Ubuntu and Upstream), and you are forming a relationship with the upstream developers.  Keep up with both of those, as they will be invaluable assets to you.

 

Read more