Singlet 0.3 adds Unity Previews

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
Posted in OpenSource, Programming, Projects, Work | Tagged , , , , , , | 10 Comments

Six geeks, one sleepless night, and £5133.70 for charity

Well, we did it.  The six members of the Canonical Community Team stayed awake and (mostly) online for 24 straight hours, all for your entertainment and generous donations.  A lot of people gave a lot over the last week, both in terms of money and time, and every one of you deserves a big round of applause.

Team Insanity

First off, I wanted to thank (blame) our fearless leader, Jono Bacon, for bringing up this crazy idea in the first place.  He is the one who thought we should do something to give back to other organizations, outside of our FLOSS eco-system.  It’s good to remind us all that, as important as our work is, there are still things so much more important.  So thanks, Jono, for giving us a chance to focus some of our energy on the things that really matter.

I also need to thank the rest of my team, David Planella, Jorge Castro, Nick Skaggs and Daniel Holbach, for keeping me entertained and awake during that long, long 24 hours.  There aren’t many people I could put up with for that long, I’m glad I work in a team full of people like you.  And most importantly, thanks to all of our families for putting up with this stunt without killing us on-air.

Upstream Awesomeness

Before we started this 24-hour marathon, I sent a challenge to the Debian community.  I said that if I got 5 donations from their community, I would wear my Debian t-shirt during the entire broadcast.  Well, I should have asked for more, because it didn’t take long before I had more than that, so I was happily sporting the Debian logo for 24 hours (that poor shirt won’t ever be the same).

I wasn’t the only one who put a challenge to the Debian community.  Nick made a similar offer, in exchange for donations he would write missing man pages, and Daniel did the same by sending patches upstream.  As a result, the Debian community made an awesome showing in support of our charities.

All of our donors

The biggest thanks, of course, go out to all of those who donated to our charities.  Because of your generosity we raised well over £5000, with the contributions continuing to come in even after we had all finally gone to bed.  As of right now, our total stands at £ 5295.70 ($8486).  In particular, I would like to thank those who helped me raise £739.13 ($1184) for the Autism Research Trust:

And a very big thank you to my brother, Brian Hall, who’s donation put us over £5000 when we only had about an hour left in the marathon.  And, in a particularly touching gesture of brotherly-love, his donation came with this personal challenge to me:

So here it is.  The things I do for charity.

Posted in Events, LoCo, Meetups, OpenSource, Upstream, Work | Tagged , , , , , , , , , | 1 Comment

Why I am supporting Autism Research

The Canonical Community Team is running a week long charity fundraising drive, capped by a 24-hour live work hangout.  We all chose a different charity, and will be promoting it and encouraging donations during the week.  I chose to support the Autism Research Trust, and wanted to share a little bit about why.

Continue reading

Posted in OpenSource, Projects, Work | Tagged , , , , | 9 Comments

Help Wanted: Build a new documentation portal for Ubuntu App Developers

Back in San Francisco, during UDS-Q, we had a discussion about the need for better online documentation for the various APIs that application developers use to write apps for Ubuntu.  The Ubuntu App Showdown and subsequent AppDevUploadProcess spec work has consumed most of my time since then, but I was able to start putting together a spec for such a site.  The App Showdown feedback we got from our developers survey highlighted the need, as lack of good Gtk documentation for Python was one of the most common problems people experienced, giving it a little more urgency.

Fortunately, Alberto Ruiz was at UDS, and told me about a project he had started for Gnome called Gnome Developer Network (GDN for short).  Alberto had already done quite a bit of work on the database models and GObject Instropection parsing needed to populate it.  The plan is to use GDN as the database and import process, and build a user-friendly web interface on top of that, linking in external resources like tutorials and AskUbuntu questions, as well as user submitted comments and code snippets.

Now that the spec is (mostly) done, we need to get together some developers who can implement it.  There will be a lot of front-end work (mostly HTML, CSS and Javascript), but also enough backend work (Python and Django) to keep anybody occupied.  I’ve created a Launchpad project for the site, and a team you can join if you’re interested in helping out.

The GDN code and some very basic template are already available. You can get the code from bzr with bzr branch lp:ubuntu-api-website and following the instructions in the DEVELOPMENT file.  I’ll also be running a live App Developer Q&A Session at 1700 UTC today (September 19th), and would be happy to help anybody get the code up and running during that time.

Posted in OpenSource, Programming, Projects, Upstream, Work | Tagged , , , , , , , , | 5 Comments

Looking for a few good devs

More than a few, actually. As part of our ongoing focus on App Developers, and helping them get their apps into the Ubuntu Software Center, we need to keep the Application Review Board (ARB) staffed and vibrant. Now that the App Showdown contest is over, we need people to step up and fill the positions of those members who’s terms are ending. We also want to grow the community of app reviewers that work with the ARB to process all of the submissions that are coming in to the MyApps portal. Continue reading

Posted in OpenSource, Work | Tagged , , , , , , , , | Leave a comment

How the AppDevUploadProcess was written

For the past several week, David Planella, Jono Bacon and I have been drafting a spec that proposes a radically different approach to getting desktop applications into the Ubuntu Software Center.  Now, there’s nothing that annoys me more than somebody proposing radical changes for no reason, and without giving much thought as to how it would actually be done.  So I wanted to write down, here, both the justification for this proposal, and the process that we went through in drafting it.

The current process splits submissions between closed-source and commercial apps, which get reviewed by a paid team of Canonical employees, and non-commercial open source apps which are reviewed by the Application Review Board (ARB).  The ARB consists of 7 volunteers from the Ubuntu community, who will review the source code and packaging of each submission.  Members of the ARB are very smart, very dedicated members of the community, but they also have paying jobs, or are pursuing higher education (or both), so their time is a limited resource.  The ARB process was meant to provide an easier route for app developers than the more rigorous process that distro packages must follow to get into the Universe repository or Debian’s archives, and in that respect it has been a success.  But even with eased requirements, there was a limit to how many apps they could manually review.

The recent App Developer Showdown competition, which resulted in more than 140 new apps being submitted through our MyApps portal, showed us the limits of our current process.  We even drafted a number of new volunteers to help review the incoming apps, and Daniel Holbach provided both instructions and programs to help speed things up.  It took us weeks to give an initial review to all of the apps.  Almost two months later and we still haven’t been able to publish more than a quarter of them.  Android has seen over 9,000 new apps in a month, and I can only assume that iOS has seen similar numbers.  If we can’t even scale to handle 140, something has to change.

The spec didn’t get written down all at once from some grand design. It grew organically, from a short list of general goals to the massive text it is today.  In fact, the spec we ended up with is quite a bit different than the one we initially set out to write.  We took our list of goals and started asking the obvious questions: what work is involved, who will it impact, and what could (will) go wrong?  We could have just throw these questions out to other people, but those people are busy and have their own things they are trying to do.  Before we could ask anybody else to spend time on this, we had to put in some effort ourselves.

So we answered as many of these as we could between the three of us, and those answers changed our spec accordingly.  That raised more questions, and we repeated the process, updating the spec and finding more questions that needed to be answered.  In the process we gained both a clearer idea of what we wanted, and a better understanding of how to get there.  By the time we had answered as many as we could on our own, our list of goals had transformed into a longer list of implementation items and who would most likely be doing them.

At that point, we had a more specific direction and a pretty good idea of how much work it would take.  Having done as much of the leg-work as we could, we took the implementation items, and any unanswered questions we still had, and started talking to the people who would have to implement it.  Unsurprisingly, these conversations had an even bigger impact on the spec, and it underwent some pretty drastic changes as we tried to nail down the details of the implementation.  Just like the previous stage, we iterated over this one multiple times until we had as many details as we could collect, and answered all of the questions that we could.  At the end, we had the massive spec we announced today.

But this is just the next stage, the spec isn’t final.  The three of us have answered as much as we could, the teams who will implement it have answered as much as they could, now we’re introducing it the community to gather even more details and answer even more questions.  The feedback we get in this stage will go back into the spec, and very likely generate new questions and feedback, and we’ll iterate through this stage too.

The final spec, whatever it ends up being, isn’t going to be perfect, and it’s not going to make everybody happy.  But we can be confident that is will be a very well thought out spec, it will be a very detailed spec, and it will allow us to accomplish the goals we set out to accomplish at the beginning of it all.  It will help make Ubuntu a much more attractive platform for application developers, it will make Software Center more useful to developers and users alike, and it will make Ubuntu a better OS for all of our users.

If you have any questions or comments on the spec itself, please send them to the ubuntu-devel mailing list, not the comments section here.

Posted in OpenSource, Upstream, Work | Tagged , , , , , , , | 3 Comments

Why the Linux desktop is not dead

Because you will never, ever, see this headline:

Linux Corporation discontinues desktop product, fires developers.

As long as there are people who want a Linux desktop, there will be a Linux desktop.  And by any measure, there are more people who want it now than every before.

Posted in OpenSource | Tagged , | 11 Comments

App Developer Q&A

You can watch the App Developer Q&A live stream starting at 1700 UTC (or watch the recording of it afterwards):

Questions should be asked in the #ubuntu-on-air IRC channel on freenode.

You can ask me anything about app development on Ubuntu, getting things into the Software Center, or the recent Ubuntu App Showdown competition.

Posted in Events, OpenSource, Programming, Upstream, Work | Tagged , , , , , , | 3 Comments

App Developer Q&A Kickoff

Due to the popularity of the Ubuntu App Showdown Workshops, I plan to start holding a weekly Q&A session for all Ubuntu app developers using the same format: A live Google+ Hangout with IRC chat.

The first of these will be Wednesday of this week, at 1700 UTC (6pm London, 1pm US Eastern, 10am US Pacific).  Because it will be an On-Air hangout, I won’t have a link until I start the session, but I will post it here on my blog before it starts.  For IRC, I plan on using the #ubuntu-on-air channel on Freenode, though again the exact details will be posted the day of the session.

So bring your questions about developing apps for Ubuntu, packaging an submitting them to the Software Center.  If I can’t answer your question myself, I’ll help you find someone who can.

Posted in Events, Programming, Work | Tagged , , , , , , , | Leave a comment

Quickly Gtk update

As part of the Ubuntu App Showdown I started on a small project to provide a nice GUI frontend to Quickly.  While I was able to get it working and submitted before the contest deadline, I unfortunately didn’t have the time to make it do everything I wanted.  Since the end of the contest, however, I was able to spend a little more time adding some nice features to it.

Continue reading

Posted in OpenSource, Programming, Projects, Work | Tagged , , , , , | 7 Comments