Canonical Voices

Posts tagged with 'work'

David Murphy (schwuk)

I was browsing Twitter last night when Thoughbot linked to their post about commit messages.

This was quite timely as my team has been thinking about improving the process of creating our release notes, and it has been proposed that we generate them automatically from our commit messages. This in turn requires that we have commit messages of sufficient quality, which – to be honest – we don’t always. So the second proposal is to enforce “good” commit messages as part of reviewing and approving merge proposals into our projects. See this post from Kevin on my team for an overview of our branching strategies to get an idea of how our projects are structured.

We still need to define what constitutes a “good” message, but we will certainly use both the article from Thoughtbot and the oft-referenced advice from Tim Pope as our basis. We are also only planning to apply this to commits to trunk because, well, you don’t need a novel – or even a short story – for every commit in your spike branch!

Now, back to the Thoughtbot article, and this piece of advice stood out for me:

Never use the -m <msg> / --message=<msg> flag to git commit.

Since I first discovered -m I have used it almost exclusively, thinking I’m being so clever and efficient, but in reality I’ve been restricting what I could say to what felt “right” on an 80 character terminal. If nothing else, I will be trying to avoid the use of -m from now on.

The post Writing better commit messages appeared first on David Murphy.

Read more
Michael Hall

Do you want a new OPPO Find 5?  Of course you do!  Well the awesome team at OPPO have given us a brand new Find 5 (x909 to be exact) for us to give you.  So here’s the deal, the first person to provide a working Ubuntu Touch image for this device gets to keep it.

Last weekend both Ubuntu and OPPO had booths at the first ever XDA Developers Conference in Miami.  While discussing both of our new products, the idea came up to hold a porting contest to get Ubuntu Touch running on the Find 5.  Jono announced the initial contest during his presentation on Saturday, with an initial challenge to have a winner claim the prize during the conference itself.  Despite having three separate developers build images and flash them onto the phone, none were able to boot into Ubuntu Touch.

So now we’re extending the contest and making it available to everybody!  To enter, you will need to send me an email containing links to the necessary files and detailed step-by-step direction for loading them on the phone.  I don’t have much experience with flashing ROMs, so treat me like a complete newbie when writing your instructions.  If your images don’t work, I will send you the output from adb logcat as well as any other information you request.  If your images do work, and meet the requirements below, I’ll be asking for a mailing address so I can send you your prize!

In order to win your phone, you need to get Ubuntu Touch running on the OPPO Find 5. Not just booting, but running, and is a way that makes it usable for other Find 5 owners.  So I’ve set out the following things that I will be checking for:

  • The phone boots into Ubuntu Touch (obviously)
  • I can launch multiple apps and switch between them
  • I can make phone calls (I have a SIM that works)
  • I can send and receive SMS
  • I can connect to Wifi, using WPA2
  • The screen goes to sleep when pressing the power button or after the set timeout period, and wakes up again when pressing the power button
  • I can play audio with the Music app
  • I can take pictures with the front and rear cameras

So, you want to take a crack at it?  Well the first step is to read the Ubuntu Touch Porting Guide.  Once you have an image you want me to try, send an email to mhall119@gmail.com with “OPPO” somewhere in the subject (just to help me out, I get a lot of email).  In that email include all of the steps necessary to download and install your image.  Again, be detailed, I’m a newb.  If you image meets the above requirements, I’ll put it in the mail to you!  After that, we can work on getting your image available for easy installation via our phablet-flash tool, so all the other OPPO Find 5 owners can try it too.

Read more
Michael Hall

When we announced the Ubuntu Edge crowd-funding campaign a week ago, we had one hell of a good first day.  We broke records left and right, we sold out of the first round of perks in half the time we expected, and we put the campaign well above the red line we needed to reach our goal.  Our second day was also amazing, and when we opened up a new round of perks at a heavy discount the third day we got another big boost.

But as exciting and record-breaking as that first week was, we couldn’t escape the inevitable slowdown that the Kickstarter folks call “the trough“.  Our funding didn’t stop, you guys never stopped, but it certainly slowed way down from it’s peak.  We’ve now entered a period of the crowd-funding cycle where keeping momentum going is the most important thing. How well we do that will determine whether or not we’re close enough to our goal for the typical end-of-cycle peak to push us over the edge.

And this is where we need our community more than ever, not for your money but for your ideas and your passion.  If you haven’t contributed to the campaign yet, what can we offer that would make it worthwhile for you?  If your friends haven’t contributed yet, what would it take to make them interested?  We want to know what perks to offer to help drive us through the trough and closer to the Edge.

Our Options

So here’s what we have to work with.  We need to raise about $24 million by the end of August 21st.  That’s a lot, but if we break it down by orders of magnitude we get the following combinations:

  • 1,000,000 people giving $24 each
  • 100,000 people giving $240 each
  • 10,000 people giving $2,400 each
  • 1,000 people giving $24,000 each

Now finding ways to get people to contribute $24 are easy, but a million people is a lot of people.  1,000 or even 10,000 people isn’t that many, but finding things that they’ll part with $2,400 for is challenge, even more so for $24,000.

That leaves us with one order of magnitude that I think makes sense. 100,000 people is a lot, but not unreasonable.  Previously large crowd-funding campaigns have reached 90,000 contributors, while raising only a fraction of what we’re trying for, so that many people is an attainable goal.  Plus $240, while more than an impulse purchase, still isn’t an unreasonable amount for a lot of people to part with, especially if we’re giving them something of similar real value in return.

Now it doesn’t have to be exactly $240, but think of perk ideas that would be around this level, something less than the cost of a phone, but more than the Founder levels.

Our Limits

Now, for the limitations we have.  I know everybody wants to see $600 phones again, and that would certainly be an easy way to boost the campaign.  But the manufacturing estimate we have is that $32 million will build only 40,000 phones.  That’s $800 per phone.  That’s something we can’t get away from.  Whatever we offer as perks, we have to average at least $800 per phone.  We were able to offer perks for less than that because we projected the other perk levels to help make up the difference.  So if you’re going to suggest a lower-priced phone perk, you’re going to have to offer some way to make up the difference.

You also need to consider the cost of offering the perk, as a $50 t-shirt doesn’t actually net $50 once you take out the cost of the shirt itself, so we can’t offer $240 worth of merchandise in exchange for a $240 contribution. But you could probably offer something that costs $20 to make in exchange for a $240 contribution.

Our Challenge

So there’s the challenge for you guys.  I’ve been thinking of this for over a week now, and have offered my ideas to those managing the campaign.  Often they pointed out some flaw in my reasoning or estimates, but some ideas they liked and might try to offer.  I can’t promise that your ideas will be offered, but I can promise to put them in front of the people making those decisions, and they are interested in hearing from you.

Now, rather than trying to cultivate your ideas here on my blog, because comments are a terrible place for something like that, I’ve created a Reddit thread for you.  Post your ideas there as comments, upvote the ones you think are good, downvote the ones you don’t think are possible, leave comments and suggestions to help refine the ideas.  I will let those running the campaign know about the thread, and I will also be taking the most popular (and possible) ideas and emailing them to the decision makers directly.

We have a long way to go to reach $32 million, but it’s still within our reach.  With your ideas, and your help, we will make it to the Edge.

Reddit: http://www.reddit.com/r/Ubuntu/comments/1jqyas/submit_your_ubuntu_edge_campaign_perk_ideas_here/

Read more
David Murphy (schwuk)

As part of our self-improvement and knowledge sharing within Canonical, within our group (Professional and Engineering Services) we regularly – at least once a month – run what we call an “InfoSession”. Basically it is Google Hangout on Air with a single presenter on a topic that is of interest/relevance to others, and one of my responsibilities is organising them. Previously we have had sessions on:

  • Go (a couple of sessions in fact)
  • SystemTap
  • Localization (l10n) and internationalization (i18n)
  • Juju
  • Graphviz
  • …and many others…

Today the session was on continuous integration with Tarmac and Vagrant, presented by Daniel Manrique from our certification team. In his own words:

Merge requests and code reviews are a fact of life in Canonical. Most projects start by manually merging approved requests, including running a test suite prior to merging.

This infosession will talk about tools that automate this workflow (Tarmac), while leveraging your project’s test suite to ensure quality, and virtual machines (using Vagrant) to provide multi-release, repeatable testing.

Like most of our sessions it is publicly available, here it is is for your viewing pleasure:

The post Continuous Integration with Tarmac and Vagrant appeared first on David Murphy.

Read more
Michael Hall

There’s been a lot of talk about the Ubuntu Edge, and our associated Indiegogo campaign to fund it. There has been a lot of positive coverage on news sites, social media, Reddit and even one television interview. But there have also been a lot of questions about why we’re doing this, and why we’ve chosen a crowd-funding campaign to do it. Since I’ve seen so many of the same questions being asked by so many people, I wanted to take the time to try and explain things a little bit better.

What it isn’t

In order to fully understand and appreciate what the campaign is about, it might be easiest to first explain fully what it isn’t.  Once we’ve done away with these misconceptions, it should become more clear why it is what it is, and finally why that is important.

First of all, and perhaps most importantly, this is not a charity.  We have provided a $20 perk for people who want to see this campaign succeed but don’t have the means or desire to purchase one of the Ubuntu Edge devices.  But this is primarily a way for people to get very high-end hardware by paying for it’s creation.  I don’t have the exact numbers, but just going by what we’ve seen of the perks claimed, people have been contributing at levels that would get them a phone more than 3.5 times more often than the much less expensive founder’s perk. This tells me that people aren’t supporting this campaign because they think it’s a good cause, or because they like what Canonical is doing, by and large they are supporting this campaign because they want an Ubuntu Edge in return.

Secondly, and this is one that has been asked a lot, this is not a financial investment.  OEMs aren’t stupid, venture capitalists aren’t stupid, and Mark Shuttleworth isn’t stupid.  If there was money to be made in building bleeding-edge phones then we would have half a dozen to choose from at our local store.  The margins on hardware sales is much lower than many people realize, and without a high rate of profits available, only a very low level of risk can be assumed.  That’s the main reason nobody else has built a phone like the Ubuntu Edge, and why nobody is going to anytime soon if we were to try and do it using capital investments.  The Ubuntu Edge doesn’t need to prove that people want scratch-proof screens or high-capacity batteries, it doesn’t need to prove that consumers like more power and more storage, it needs to prove that those technologies are ready to be produced in high volumes without supply or manufacturing problems.  It doesn’t need to prove that people want a desktop available at home or work, but it does need to prove that the hardware and software are capable now of providing that convergence in a satisfactory way that previous attempts couldn’t.

Finally, it’s not a way of making money for Canonical or a last-ditch effort for keeping either Ubuntu or Ubuntu Touch alive.  Whether this campaign succeeds or fails, we will continue to work with OEMs to bring multiple consumer phones to market, most likely using slightly better hardware than the current generation of smart phones, where there is little risk involved on the hardware side.  But in order for Ubuntu to provide the kind of convergence and one-device experience that we envision, we needed skip the slow, safe evolution of hardware and spark the flames on a whole new class of phone.  So while we work on getting Ubuntu phones to market with our partners, the Ubuntu Edge will provide the seeds for the suppliers and manufacturers that those partners use, so they will be ready to build their new generation of superphones when the time comes.

What it is

Now that I’ve gone over what this campaign isn’t, let talk about what it is.  I spent some time over this weekend thinking about how to accurately describe it without going deep into the economics or politics of it, trying to find parallels in other industries (like Mark’s F-1 analogy) that wouldn’t fall apart when going into the specifics of either.  In the end, I decided that the thing this campaign resembles the most is an adventure.

Now that’s vague, I know, so let me give some more concrete examples.  I liked Mark’s F-1 analogy, but when looking into how F-1 actually operates these days it really doesn’t quite fit.  Instead it’s more like X-Prize competition that put the first private manned vehicle into space.  Even though there was a monetary prize in that competition, it was only a tiny fraction of the money that went into building any of the entrants.  The reason anybody participated was to push the bounds of technology and to try and birth a new industry, one where they would stand to benefit more in the long run than any possible profits they could have made by sticking with the status quo.

But those initiatives were largely funded by wealthy individuals, who probably didn’t expect to get much in return.  So for a more fitting analogy we need to go a bit further back in time, to expeditions into the Americas and Africa, some of which were funded only by those who were to participate in them, and who could expect little more than the thrill of participating.  While not pushing the limits of technology, these adventurers would certainly push the bounds of knowledge to new levels, and would fundamentally change the way the world looked.

[Update] It has been pointed out in the comments that many of these expeditions had either deplorable intents or disasterous consequences for the native people.  While this was not at all what I had in mind, I understand that my knowledge of those histories is largely influenced by my own ancestry.  A better example, as also pointed out in the comments, would be the expeditions to both the north and south poles, or the scaling of Everest.

Why it’s important

Now both of these are extreme examples, and certainly far outshine what we’re trying to do with the Ubuntu Edge.  It is just a computer after all.  But on a smaller scale the reasons and motivations are the same, there is a desire to push the limits that currently confine us.  And that’s certainly not a feeling that’s limited to Canonical, over 15,000 people have contributed to the campaign in one way or another, and around 10,000 have committed to sharing the adventure with us from the beginning by claiming their own phone.  These aren’t wealthy investors looking to become more wealthy, nor is it good-hearted folks who are giving us money just to be nice, these are thousands of people who want go on the adventure because it’s exciting, because it’s audacious, and because it gives them the future they want to see made.

So there it is, we’re embarking on an adventure, and we want you to come with us.  If the Ubuntu Edge makes you excited for the future of computing, if you’re eager to see that future technology years before it becomes common place, if you want be on of the ones cutting new trails rather than following those well-worn paths cut years ago, then I invite you to sign up and add your name to the list of technology pioneers.

Read more
olli

Being edgy

edg·y (/?ej?/) – creatively challenging, of bold or provocative quality Welcome Ubuntu Edge – Canonical is starting a campaign on Indiegogo to crowdfund our vision of future mobile computing. The goal of $32M is bold, the approach of working through crowdfunding provocative. Teams have been working on an industrial design of how we envision the future […]

Read more
admin

It all sounds good in theory… Not too long ago, Mark communicated the vision for Ubuntu and Unity for 2013 as “[...] Unity in 2013 will be all about mobile – bringing Ubuntu to phones and tablets [...]” and my team is responsible for taking Unity to these hardware platforms. What you should expect to […]

Read more
olli

The second iteration of our virtual UDS is coming up tomorrow 5/14 and will go until Thursday 5/16, running from 1400 UTC to 2000 UTC. Out of all the proposed sessions I wanted to highlight the ones relevant to Unity & friends: Content Handling on Ubuntu/Unity General X.Org plans for Saucy Core Apps in Ubuntu Touch […]

Read more
admin

The documentation for Mir is growing and we also have instructions out how to get Mir running on your computer, I wanted to briefly summarize the necessary steps to get Mir up and running and how to go back. Please be warned that while I tried to carefully document all necessary steps you might end […]

Read more
olli

The first neutral (i.e. not published by us) benchmark of Mir is out. Michael over at Phoronix has a good write up of the current state of things and also mentions that the install was smoother than anticipated. The results (~about 10% median, 15% average penalty in FPS, see below) are totally within the expected […]

Read more
Michael Hall

Yesterday I posted the first in a new series of Core App Update, featuring the Clock App’s development.  Today I’m going to cover the status of the Calendar

Calendar Features

Calendar View

The calendar now provides several different views you can choose from.  You start off with a full month at the top, and your events for the day below.  Swiping left and right on the month will take you back or forward a month at a time.  Swiping left or right on the bottom half will take you back and forward a day at a time.

Pull the event area down and let it go, and the month will collapse down into a single week. Now swiping left and right there will move you back and forward a week at a time.  Pull down and let it go again and it will snap back to showing the full month.

Finally, you have an option in the toolbar (swipe up from the bottom edge) to switch from an event list to a timeline view of your events.

Adding Events

You can current add events to the calendar app, and they will be stored in a local database.  However, after discussions with Ubuntu Touch developers, the Calendar team is refactoring the app to use the Qt Organizer APIs instead.  This will allow it to automatically support saving to Evolution Data Server as a backend as soon as it’s integrated, making calendar events available to other parts of Ubuntu such as the datetime indicator.  Being able to import your ical feeds is also on the developer’s TODO list.

Visual Designs

We don’t have new visual designs for the Calendar yet, but it is one of the apps that the Design team has committed to providing one for.  Now that they are done with the Clock’s visual designs, I hope to see these soon for the Calendar.

Release Schedule

Once again I worked with the Calendar developers to set release targets for their app.  The alpha release is targeted for month-2, this month, and should include the switch to Qt Organizer.  Then we plan on having a Beta release in August and a Final in September.

Read more
Michael Hall

The Ubuntu Touch Core Apps project is a new kind of collaboration between Canonical and the wider Ubuntu community, with a goal of developing high-quality applications for Ubuntu Touch. A couple of months ago I set out the Core Apps roadmap to October, and it’s high time I got around to giving you an update on our progress.

I had originally planned on giving an update of each of the core apps in a single blog post, but I realized that was going to get very, very long.  And nobody has time to read a giant wall of text.  So instead I’ll be breaking them up, one post per apps, so you can spread your reading time over multiple days.

To kick this off, here are the latest developments going on in the Clock app:

Clock Features

Sunrise & Sunset

Recently added to the main Clock tab is a way to check the sunrise and sunset times for the day.  Simply tap on the clock face and it will switch to the sunrise/sunset view.  Tap it again to switch back.  Swipe up from the bottom to reveal the toolbar, where you can set your location (which is used to calculate your specific sunrise and sunset times).

Alarms

The Clock app developers are still waiting on a platform API to support registering alarms that will work even when the Clock app isn’t running.  But while they’re waiting on that, they’ve still be working hard on the interface for managing your alarms.  Their approach is both minimal and obvious, you drag the hour and minute hands around to the time you and and click Done in the center.  If you need more options, you can pick how often to repeat, what alarm tone to use, and whether or not to vibrate.

Now these won’t actually work until the platform API is in place, but you can already see how it will look to the user, and how simple it is to do.

Timer

Like the alarms, setting a timer is both minimal and obvious.  Unlike alarms, the timer is working today.  Drag the hand around to set how many seconds, tap the minutes part of the time and drag the hand to set the minutes.  Make more than one revolution around the dial and it will start adding hours as well.

Another nice feature is the ability to define custom timers that you can use again and again.  Swipe up from the bottom to reveal the toolbar again, select Add Preset, and set the duration using the same simple dragging motions on the dial.

Stopwatch

Finally we come to the stopwatch part of the app.  In addition to simple start, pause and reset functionality, the stopwatch lets you mark laps as it goes, and keeps a log of each one that you can view both while the stopwatch is running and after.

Visual Designs

Some of you may have seen the new visual concepts that the Design Team published last month, which received quite a bit of positive feedback.  Well this week they sent the Clock developers the completed visual designs for the Clock app, so we should start to get our first taste of those designs in action in the next few weeks.

Release Schedule

Starting a couple of weeks ago, I started working with each of the Core Apps developer teams to set release targets for Alpha, Beta and Final releases of the app, with a goal to have them all at a 1.0 version before the October release of Ubuntu 13.10.  For the clock, we decided to mark the month-1 milestone (May) as an alpha release, because of the progress they had already made.  We then picked month-3 (July) for beta and month-4 (August) for our final release target.  Furthermore we have work items assigned on a monthly release basis to track the progress we are making.

Read more
Michael Hall

It’s official, UDS 13.05 is coming up next month, marking our second online Ubuntu Developer Summit, and coming only two months after the last one. While going virtual was part of our transition to make Ubuntu’s development more open and inclusive, the other side of that coin was to start holding them more often. The first we put into affect in March, and the second is coming in May. Read below for information about this UDS, and changes that have been made in response to feedback from the last one.

Scheduling

The dates for UDS 13.05 are May 14, 15 and 16, from 1400 UTC to 2000 UTC.  We will once again have 5 tracks: App Development, Community, Client, Server & Cloud and Foundations.  The track leads for these will be:

  • App Development: Alan Pope, David Planella & Michael Hall
  • Community: Daniel Holbach, Nick Skaggs & Jono Bacon
  • Client: Jason Warner & Sebastien Bacher
  • Server & Cloud: Dave Walker & Antonio Rosales
  • Foundations: Steve Langasek

Track leads will be in charge of approving Blueprints and getting them on the schedule.  If you are going to be responsible for running a session, please get with the track lead to make sure they have marked you as being required for that session. If you would like to get a session added for this UDS, you can do so either through registering a Blueprint or proposing a meeting through Summit itself.  Both approaches will require the approval of a Track Lead, so make sure you discuss it with them ahead of time.

Changes to…

Using feedback from attendees of the March UDS, we will be implementing a number of changes for UDS 13.05 to improve the experience.

Hangouts

Google+ Hangouts have a limit of 15 active participants (if started with a Canonical user account, it’s 10 if you don’t have a Google Apps domain), but in practice we rarely had that many people join in the last UDS.  This time around we’re going to encourage more people to join the video, especially community participants, so please check your webcams and microphones ahead of time to be ready.  If you want to join, just ask one of the session leaders on IRC for the hangout URL. We are also investigating ways to embed the IRC conversations in the Hangout window, to make it easier for those on the video to keep track of the conversation happening there.

The Plenaries

Most people agreed that the mid-day plenaries didn’t work as well online as they do in person.  There was also a desire to have a mid-day break to allow people to eat, stretch, or hold a sidebar conversation with somebody.  So we are replacing the mid-day plenaries with a “lunch” slot, giving you an hour break to do whatever you need to do. We will be keeping the introductory plenary on the morning of the first day, because that helps set the tone, goals and information needed for the rest of the week.  In addition to that, we have added back a closing plenary at the end of the last day, where track leads will be able to give a summary of the discussions and decisions made.

The Schedule

In addition to the above plenary changes, we have added an extra day to this UDS, making it 3 days instead of two.  The last day will allow for overflow of sessions that couldn’t fit into 2 days, or the scheduling of follow-up session when it is determined they are necessary following a discussion earlier in the week.

Registration

Registration to attend will now be done in Summit itself, rather than through a Launchpad Sprint.  So if you’re not a track lead, and you’re not registering Blueprints, there’s nothing you need to do on Launchpad itself.  This will help those who do not have a Launchpad profile, though you will still need an Ubuntu SSO account to log in.

To register for UDS 13.04, go to the summit page, and just above the schedule you will see an orange “Register in Summit” button.  If you don’t see that, you either need to log in to  summit or you’ve already registered.

Summit Scheduler

Chris Johnston and Adnane Belmadiaf have been working hard to improve the Summit Scheduler website, taking feedback from attendees to improve the interface and workflow of the site.  We will include as many enhancements as possible before the start of UDS 13.05.  If you are interested in helping improve it, and you have some web development skills, please find them on #ubuntu-website on Freenode to find out how you can get involved.

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

The Ubuntu Skunkworks program is now officially underway, we have some projects already staffed and running, and others where I am gathering final details about the work that needs to be done.  Today I decided to look at who has applied, and what they listed as their areas of interest, programming language experience and toolkit knowledge.  I can’t share details about the program, but I can give a general look at the people who have applied so far.

Most applicants listed more than one area of interest, including ones not listed in Mark’s original post about Skunkworks.  I’m not surprised that UI/UX and Web were two of the most popular areas.  I was expecting more people interested in the artistic/design side of things though.

Not as many people listed multiple languages as multiple areas of interest.  As a programmer myself, I’d encourage other programmers to expand their knowledge to other languages.  Python and web languages being the most popular isn’t at all surprising.  I would like to see more C/C++ applicants, given the number of important projects that are written in them.  Strangely absent was any mention of Vala or Go, surely we have some community members who have some experience with those.

The technology section had the most unexpected results.  Gtk has the largest single slice, sure, but it’s still much, much smaller than I would have expected.  Qt/QML even more so, where are all you KDE folks?  The Django slice makes sense, given the number of Python and Web applicants.

So in total, we’ve had a pretty wide variety of skills and interests from Skunkworks applicants, but we can still use more, especially in areas that are under-represented compared to the wider Ubuntu community.  If you are interested, the application process is simple: just create a wiki page using the ParticipationTemplate, and email me the link (mhall119@ubuntu.com).

Read more
Michael Hall

Now that Google+ has added a Communities feature, and seeing as how Jorge Castro has already created one for the wider Ubuntu community, I went ahead and created one specifically for our application developers.  If you are an existing app developer, or someone who is interested in getting started with app development, or thinking about porting an existing app to Ubuntu, be sure to join.

Google+ communities are brand new, so we’ll be figuring out how best to use them in the coming days and weeks, but it seems like a great addition.

Read more
Michael Hall

Shortly after the Ubuntu App Showdown earlier this year, Didier Roche and Michael Terry kicked off a series of discussions about a ground-up re-write of Quickly.  Not only would this fix many of the complications app developers experienced during the Showdown competition, but it would also make it easier to write tools around Quickly itself.

Unfortunately, neither Didier nor Michael were going to have much time this cycle to work on the reboot.  We had a UDS session to discuss the initiative, but we were going to need community contributions in order to get it done.

JFDI

I was very excited about the prospects of a Quickly reboot, but knowing that the current maintainers weren’t going to have time to work on it was a bit of a concern.  So much so, that during my 9+ hour flight from Orlando to Copenhagen, I decided to have a go at it myself. Between the flight, a layover in Frankfurt without wifi, and a few late nights in the Bella Sky hotel, I had the start of something promising enough to present during the UDS session.  I was pleased that both Didier and Michael liked my approach, and gave me some very good feedback on where to take it next.  Add another 9+ hour flight home, and I had a foundation on which a reboot can begin.

Where is stands now

My code branch is now a part of the Quickly project on Launchpad, you can grab a copy of it by running bzr branch lp:quickly/reboot.  The code currently provides some basic command-line functionality (including shell completion), as well as base classes for Templates, Projects and Commands.  I’ve begun porting the ubuntu-application template, reusing the current project_root files, but built on the new foundation.  Currently only the ‘create’ and ‘run’ commands have been converted to the new object-oriented command class.

I also have examples showing how this new approach will allow template authors to easily sub-class Templates and Commands, by starting both a port of the ubuntu-cli template, and also creating an ubuntu-git-application template that uses git instead of bzr.

What comes next

This is only the very beginning of the reboot process, and there is still a massive amount of work to be done.  For starters, the whole thing needs to be converted from Python 2 to Python 3, which should be relatively easy except for one area that does some import trickery (to keep Templates as python modules, without having to install them to PYTHON_PATH).  The Command class also needs to gain argument parameters, so they can be easily introspected to see what arguments they can take on the command line.  And the whole thing needs to gain a structured meta-data output mechanism so that non-Python application can still query it for information about available templates, a project’s commands and their arguments.

Where you come in

As I said at the beginning of the post, this reboot can only succeed if it has community contributions.  The groundwork has been laid, but there’s a lot more work to be done than I can do myself.  Our 13.04 goal is to have all of the existing functionality and templates (with the exception of the Flash template) ported to the reboot.  I can use help with the inner-working of Quickly core, but I absolutely need help porting the existing templates.

The new Template and Command classes make this much easier (in my opinion, anyway), so it will mostly be a matter of copy/paste/tweak from the old commands to the new ones. In many cases, it will make sense to sub-class and re-use parts of one Template or Command in another, further reducing the amount of work.

Getting started

If you are interested in helping with this effort, or if you simply want to take the current work for a spin, the first thing you should do is grab the code (bzr branch lp:quickly/reboot).  You can call the quickly binary by running ./bin/quickly from within the project’s root.

Some things you can try are:

./bin/quickly create ubuntu-application /tmp/foo

This will create a new python-gtk project called ‘foo’ in /tmp/foo.  You can then call:

./bin/quickly -p /tmp/foo run

This will run the applicaiton.  Note that you can use -p /path/to/project to make the command run against a specific project, without having to actually be in that directory.  If you are in that directory, you won’t need to use -p (but you will need to give the full path to the new quickly binary).

If you are interested in the templates, they are in ./data/templates/, each folder name corresponds to a template name.  The code will look for a class called Template in the base python namespace for the template (in ubuntu-application/__init__.py for example), which must be a subclass of the BaseTemplate class.  You don’t have to define the class there, but you do need to import it there.  Commands are added to the Template class definition, they can take arguments at the time you define them (see code for examples), and their .run() method will be called when invoked from the command line.  Unlike Templates, Commands can be defined anywhere, with any name, as long as they subclass BaseCommand and are attached to a template.

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