Canonical Voices

Posts tagged with 'upstream'

Michael Hall

Screenshot from 2014-03-20 21:57:06Yesterday we made a big step towards developing a native email client for Ubuntu, which uses the Ubuntu UI Toolkit and will converge between between phones, tablets and the desktop from the start.

We’re not starting from scratch though, we’re building on top of the incredible work done in the Trojitá project.  Trojitá provides a fast, light email client built with Qt, which made it ideal for using with Ubuntu. And yesterday, the first of that work was accepted into upstream, you can now build an Ubuntu Components front end to Trojitá.

None of this would have been possible without the help up Trojitá’s upstream developer Jan Kundrát, who patiently helped me learn the codebase, and also the basics of CMake and Git so that I could make this first contribution. It also wouldn’t have been possible without the existing work by Ken VanDine and Joseph Mills, who both worked on the build configuration and some initial QML code that I used. Thanks also to Dan Chapman for working together with me to get this contribution into shape and accepted upstream.

This is just the start, now comes the hard work of actually building the new UI with the Ubuntu UI Toolkit.  Andrea Del Sarto has provided some fantastic UI mockups already which we can use as a start, but there’s still a need for a more detailed visual and UX design.  If you want to be part of that work, I’ve documented how to get the code and how to contribute on the EmailClient wiki.  You can also join the next IRC meeting at 1400 UTC today in #ubuntu-touch-meeting on Freenode.

Read more
Michael Hall

Today I reached another milestone in my open source journey: I got my first package uploaded into Debian’s archives.  I’ve managed to get packages uploaded into Ubuntu before, and I’ve attempted to get one into Debian, but this is the first time I’ve actually gotten a contribution in that would benefit Debian users.

I couldn’t have done with without the the help and mentorship of Paul Tagliamonte, but I was also helped by a number of others in the Debian community, so a big thank you to everybody who answered my questions and walked me through getting setup with things like Alioth and re-learning how to use SVN.

One last bit of fun, I was invited to join the Linux Unplugged podcast today to talk about yesterday’s post, you can listen it it (and watch IRC comments scroll by) here: http://www.jupiterbroadcasting.com/51842/neckbeard-entitlement-factor-lup-28/

Read more
Michael Hall

Today was a distracting day for me.  My homeowner’s insurance is requiring that I get my house re-roofed[1], so I’ve had contractors coming and going all day to give me estimates. Beyond just the cost, we’ve been checking on state licensing, insurance, etc.  I’ve been most shocked at the differences in the level of professionalism from them, you can really tell the ones for whom it is a business, and not just a job.

But I still managed to get some work done today.  After a call with Francis Ginther about the API website importers, we should soon be getting regular updates to the current API docs as soon as their source branch is updated.  I will of course make a big announcement when that happens

I didn’t have much time to work on my Debian contributions today, though I did join the DPMT (Debian Python Modules Team) so that I could upload my new python-model-mommy package with the DPMT as the Maintainer, rather than trying to maintain this package on my own.  Big thanks to Paul Tagliamonte for walking me through all of these steps while I learn.

I’m now into my second week of UbBloPoMo posts, with 8 posts so far.  This is the point where the obligation of posting every day starts to overtake the excitement of it, but I’m going to persevere and try to make it to the end of the month.  I would love to hear what you readers, especially those coming from Planet Ubuntu, think of this effort.

[1] Re-roofing, for those who don’t know, involves removing and replacing the shingles and water-proofing paper, but leaving the plywood itself.  In my case, they’re also going to have to re-nail all of the plywood to the rafters and some other things to bring it up to date with new building codes.  Can’t be too safe in hurricane-prone Florida.

Read more
Michael Hall

Quick overview post today, because it’s late and I don’t have anything particular to talk about today.

First of all, the next vUDS was announced today, we’re a bit late in starting it off but we wanted to have another one early enough to still be useful to the Trusty release cycle.  Read the linked mailinglist post for details about where to find the schedule and how to propose sessions.

I pushed another update to the API website today that does a better job balancing the 2-column view of namespaces and fixes the sub-nav text to match the WordPress side of things. This was the first deployment in a while to go off without a problem, thanks to  having a new staging environment created last time.  I’m hoping my deployment problems on this are now far behind me.

I took a task during my weekly Core Apps update call to look more into the Terminal app’s problem with enter and backspace keys, so I may be pinging some of you in the coming week about it to get some help.  You have been warned.

Finally, I decided a few weeks ago to spread out my after-hours community a activity beyond Ubuntu, and I’ve settled on the Debian new maintainers Django website as somewhere I can easily start.  I’ve got a git repo where I’m starting writing the first unit tests for that website, and as part of that I’m also working on Debian packaging for the Python model-mommy library which we use extensively in Ubuntu’s Django website. I’m having to learn (or learn more) Debian packaging, Git workflows and Debian’s processes and community, all of which are going to be good for me, and I’m looking forward to the challenge.

Read more
Michael Hall

It’s day 5 of the Ubuntu Core Apps Hack Days!  We’ve seen a tremendous amount of work coming into the Core Apps, and have several new contributors joining the initiative.  We’re keeping that momentum going throughout the week in #ubuntu-app-devel on Freenode from 9am to 9pm UTC, so come and be a part of this exciting project.

Today we’ll turn our attention to the Weather application, another one of the original Core Apps, and another one that is already largely complete.  The Weather app gained multi-city support and a long range forecast early on, and has more recently added the ability to toggle between Celsius and Fahrenheit temperature displays.  Between those, it met all of the criteria we set for dogfooding:

  • Choose a location to view weather from. DONE!
  • View current weather conditions. DONE!
  • View a 10 day forecast. DONE!
  • Configure C or F and display that chosen setting for all locations. DONE!

Since the features are complete, we now need to put the rest of our effort towards polish and quality.  This means we need those of you with QML and Javascript knowledge to help fix the reported bugs in Launchpad, and those of you with Python knowledge to help us finish the Autopilot test coverage, so that we can make this app rock solid and reliable for every day use.

Read more
Michael Hall

Back again for one more article on developing an Ubuntu SDK app.  This one might be short,  but it covers one of the cooler bits of magic that QML gives you: Transitions.  But first, be sure to read the previous articles in this series!

Transitions

It used to be that if you wanted to animate parts of your app, you had to setup timers, calculate distances and speeds, program each step along the way, and do it all without killing the user’s CPU.  Sure it could be done, it was done, but it wasn’t easy.  QML is different, QML Transitions aren’t something you have to bolt on yourself, they’re built in at the foundation.

A Transition is defined as a collection of Animation components that can change different properties in different ways, triggered automatically by a change in a component’s state or other properties.  All you, the developer, needs to do is tell QML what you want to change, and how.

ListView Event Transitions

QML offers a variety of ways to define transitions, depending on what you need.  All Items have a transitions  property, which takes a list of Transition instances that will be called whenever the Item’s state property is changed.  You can also define a Transition for any property change using the “Behavior on <property> {}” syntax, which creates a Transition for changes on the named property.

But for me, it was a third item that fit best.  QML’s ListView component has several properties that take a Transition instance, properties such as add and remove, which correspond to an item being added or removed from the ListView.  These transitions are then applied to the delegate ListItem component when it is being added or removed.  I used these properties to make the items slide in and out of view when changing subreddit, or moving from one page to another.

    ListView {
        id: articleList
        ...
        add: Transition {
            id: addAnimation
            property bool forward: true
            SequentialAnimation {
                NumberAnimation { properties: "x"; from: addAnimation.forward ? articleList.width : -articleList.width; to: 0; duration: 300 }
            }

        }
        remove: Transition {
            id: removeAnimation
            property bool forward: true
            SequentialAnimation {
                NumberAnimation { properties: "x"; from: 0; to: removeAnimation.forward ? -articleList.width : articleList.width; duration: 300 }
            }
        }
    }

At first I just had transitions going in one direction, but I wanted to give some implicit meaning to them, going one direction for “more results” and another for “new results” (reload, change subreddit, etc).  That’s why I added the extra forward property, which is used to determine the direction of the transition.

You can see it in action in this video:

Next Time: Who knows?

This is the last revision currently in my bzr branch.  I have some other code in the works, for Sharing using the new Friends service, and HUD integration.  But for one reason or another, neither is working quite the way I want it yet, and they haven’t been committed to my branch yet.  There were typically several days between revisions when I was developing uReadIt, and I’ve been blogging about it nearly every day since my first post.  Once I have some time to hack on uReadIt some more, I will have more to write about, so stay tuned!

Read more
Michael Hall

I’ve blogged three times now, here, here and here, highlighting some of the apps being written with the Ubuntu SDK.  Well after covering 44 of them, and more already popping up since yesterday’s article, we’ve decided that we need to start getting these into the Ubuntu Touch Preview images so that people can try them out on supported devices, give the developers real-use feedback and bug reports, and generally promote the amazing work being done by our community of app developers.

The Collection

So Alan Pope (popey) and I have kicked off what we’re calling the App Collection, which are apps being developed outside of the scope of our Core Apps project, but that we still want to support, promote, and  guide through the process of getting them ready for deployment to Ubuntu devices.  This means we’re going to commit to helping developers get their apps packaged, and we’re going to be uploading them to a new PPA specifically for these apps.

The Apps

We’re starting out by collecting a list of known apps, with information about where to find their source code, the status of packaging for the app, and finally whether they are available in the PPA or not.  I seeded the list with the apps I’ve been blogging about, but it’s open to anybody who has an app, or knows about an app, to add it to this list.

Apps should be in a usable state before adding them to the list, and should perform a function that might be of interest to a user or tester.  Hello World apps are great for learning, but it’s not really something that you want to promote to users.

Packaging

You don’t have to know about Debian packaging to get your app in our PPA, we’re going to help you bootstrap and debug your package.  Our goal is to provide the minimal amount of packaging necessary for your app to be installable, on the desktop or on devices, and work properly.  Of course, if you can provide packaging for your app, that will greatly speed up the process of getting it into the PPA.

We would also welcome any help from packagers. Even if you don’t have an app of your own, you can help support the app developer community by spending some time getting their packaging in order.  QML apps are relatively simple when it comes to packaging, so a seasoned packaging veteran could probably knock one out in a matter of minutes.

PPA Review

You won’t have to conform to all of the requirements that you will to get into the Ubuntu archives, and there won’t be a lengthy review process.  The Apps Collection is offered up for users to evaluate and test Ubuntu Touch and apps written for it, there is no guarantee of stability or security.  Generally if it installs and runs, we’ll include it in the PPA.  But we’re not crazy, and we won’t be uploading apps that are obviously malware or detrimental to the user or platform.

Preview Image Review

Your app will need to go through a more intense review before being approved to go into the default install of the Ubuntu Touch Preview.  You code will be inspected by the engineers responsible for the preview images, to make sure it won’t cause any problems with stability or security that would interfere with the primary goal of the preview images, which is showing off the incredible user experience that Ubuntu provides on touch devices.

Inclusion

Once it’s ready, your app will join the default apps being developed by Canonical, as well as Core Apps being developed by other members of the community in collaboration with Canonical project managers, as part of the demonstration platform for Ubuntu Touch.

This is a great opportunity for you, as a developer, to get your app in the hands of a large number of early adopters.  It’s also a great opportunity for us, being able to promote off our platform and how it is being used by the app developer community.

Read more
Michael Hall

The excitement around the Ubuntu SDK and application development is still going strong, both on the Ubuntu Touch Core Apps side and with independent developers. So strong, in fact, that it’s time for another round of updates and spotlights on the work being done.

Core Apps in the Touch Preview

Some big news on the Core Apps side is that they are now being reviewed for inclusion in the daily Ubuntu Touch Preview images being developed by Canonical for the Nexus family of devices, and by community porters to a growing number of others.

Now that all of the Core Apps are being regularly built and packaged in the Core Apps PPA, they can be easily installed on desktops or devices.  And, after being reviewed by the team building the Ubuntu Touch Preview images, three of them have been selected to be part of the default installed application set. So please join me in congratulating the developers who work to them.

For the Calendar, Frank MertensKunal Parmar and Mario Boikov have done a fantastic job implementing the unique design interactions that were defined by Canonical’s design team.  For the Calculator, Dalius DobravolskasRiccardo Ferrazzo and Riccardo Padovani were able to quickly build something that is not only functional, but offers unique features that set it apart from other standard calculators.  Finally, the Clock app, where Juha Ristolainen, Nick Leppänen LarssonNekhelesh Ramananthan and Alessandro Pozzi have put together a visually stunning, multi-faceted application that I just can’t get enough of.

New Independent App Development

In addition to the work happening on the Core Apps, there has been a continuous development by independent app developers on their own projects.

LoadShedding

Load shedding (or rolling blackouts) are a way for electricity utilities to avoid being overloaded by energy demands at peak times.  This an be an inconvenience, to say the least, especially if you don’t know it’s coming.  Maybe that’s why developer razor created this LoadShedding schedule app.

Multi-Convert

Multi-Convert was originally an Android application, written in HTML5, that is now being ported to Ubuntu.  Multi-Convert allows real-time conversion of weight, length, area, volume and temperature between different standard units.

 TV Remotes

I ran across not one, but two different apps for the remote control of home-theater-PCs, bringing the promise of your mobile phone as a “second screen” to Ubuntu Touch.

First is Joseph Mills (who also created a Weather app featured in the first of these roundups), with a remote control for MythTV:

And if you’re an XBMC user instead, not to worry, because Michael Zanetti has you covered with his remote control for XBMC:

CatchPodder

If you use your mobile device for listening to podcasts, you’ll be pleased to find the nice and functional podcast manager CatchPodder, which lets you subscribe to multiple feeds as well as playing files directly from the server.

AudioBook Reader

Keeping with the theme of listening to people talk on your Ubuntu device, we have an AudioBook manager and player that is being written with the Ubuntu SDK, which lets you load books, display cover images, and more.

Bits

If you’re a software developer, sysadmin or network engineer, there’s a good chance you’ve had to convert numbers between decimal, hexadecimal and binary.  This makes Bits a very handy utility app to keep in your pocket.

Periodic Table

From the same developer who created a Software Center front-end and Pivotal Tracker (both featured in previous posts) has a new project underway, an element browser that gives you loads of detailed information about everything on the periodic table.

WebMap

Canonical engineering Manager Pat McGowan has gotten into the fun too, building an app for displaying web-based maps from a number of providers.

GetMeWheels

For Car2Go customers looking to rent or return a vehicle, GetMeWheels lets you easily find the nearest locations to you.  Created by the same developer as the XBMC remote, this app was originally developed for Maemo/Meego, but is now being ported to the Ubuntu SDK.

PlayMee

A third app from the developer of GetMeWheels and XBMC Remote is PlayMee, a local music player that again was originally developed for Maemo/Meego, and is being ported to the Ubuntu SDK.

Tic-Tac-Toe

Tic-Tac-Toe is not a fancy game, but this one developed by Hairo Carela makes beautiful use of animation and colors, and even keeps a nice score history.

LightOff

If games are you thing, you should also check out LightOff, a simple yet challenging game where the object is to turn off all of the lights, but clicking one toggles the state of every square around it.

 

That’s all for now, keep those apps coming and be sure to post them in the Ubuntu App Developers community on Google+

 

Read more
Michael Hall

If you missed it, I posted an earlier round of SDK apps a couple weeks ago.  Well the pace of new app development didn’t slow down, so here I am again with another round of apps being written with what is still an alpha version of the Ubuntu SDK.

Core Apps Update

First an update on the Ubuntu Touch Core Apps project.  I highlighted a few of these already in my last post, but in the past week those apps have received several updates, and others have had the initial features start to land as well.

Calculator

In addition to being able to scroll back through previous calculations, the Calculator App developers have now added the ability to start a new calculation by dragging up and “tearing off” the current one, moving it into the history for later browsing.

Clock

The Clock app has been given a slight visual update on the main screen, and all new stop watch functionality too!

Calendar

The Calendar App now shows events for the day, and will take over the full screen to let you easily view your busy schedule.

Weather

The weather app too has added some visual features, and with the detailed design workflows just released, you can expect to see major changes coming to this app soon.

RSS Reader

The RSS Reader got off to a good start this week, allowing you to add feeds and read articles, either all aggregated together or one feed at a time.


File Manager

Finally, the File Manager is now working enough to let you browse through files and folders, and even open files in the appropriate application

Independent Apps

A man of many talents

Developer Ashley Johnson has been working on a couple of new apps using the Ubuntu SDK.  His first was a touch-friendly version of the Ubuntu Software Center:

Click for video

Followed up earlier this week with an Ubuntu Touch client for the Pivotal Tracker project management web service:

Click for video

Ubuntu Loves Reddit

We must, because there is not one, not two, but three separate Reddit apps being written with the Ubuntu SDK.

By Victor Thompson

By Bram Geelen

By yours truly

Ultimate Time Waster

Even Canonical’s VP of Engineering, Rick Spencer, has gotten in on the fun.  Though his app, which gathers funny pictures from across the internet for easy browsing, it’s as productivity-focuses as you might expect.

Dawning of the age of Aquarius

Canonical’s Stuart Langridge (aquarius on IRC, for those who don’t get the reference) is our resident audio-phile, which might explain why he’s written two music apps with the Ubuntu SDK, one for Ext.fm and another for Ubuntu One’s Music Streaming service.

Zeegaree

Developer Micha? Pr?dotka is porting his desktop timer app Zeegaree to the Ubuntu SDK

GPS Workout tracker

Fitness trackers are becoming more and more popular, especially as mobile apps.  Ready to meet this demand is Marin Bareta and his workout tracker for Ubuntu Touch

uQQ

QQ, the popular instant messaging service out of China, is getting it’s own native uQQ Ubuntu SDK client thanks to developer ? ? (shared to me by Szymon Waliczek)

Resistor Color Codes

I’m not electrical engineer, so I don’t know exactly what this does, but if you do I bet it would be handy to have available in your pocket, so thank Oliver Marks for making it.

Stock Tracker

Last but not least, I just saw this stock price tracker from Robert Steckroth

 

If you are writing an Ubuntu SDK app, or have come across one that I haven’t blogged about yet, be sure to drop me an email or ping me on IRC.  I get the feeling this isn’t the last SDK Apps update I’ll be posting.

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

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

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.

Read more
Michael Hall

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.

Read more
Michael Hall

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.

ARB Membership

Two of the existing members, Bhavani Shankar and Andrew Mitchell, will be continuing to serve on the board, and Alessio Treglia will be joining them. But we still need four more members in order to fill the full 7 seats on the board.  ARB applicants must be Ubuntu Members, Ubuntu Developers, and should create a wiki page for their application.

ARB members help application developers get their apps into Software Center by reviewing their package, providing support and feedback where needed, and finally voting to approve the app’s publication.  You should be able to dedicate a few hours each week to reviewing apps in the queue, and discussing them on IRC and the ARB’s mailing list.

If you would like to apply, you can contact the current ARB members on #ubuntu-arb on Freenode IRC, or the team mailing list (app-review-board at lists.ubuntu.com).  The current term will expire at the end of the month, so be sure to get your applications in as soon as you can.

ARB Helpers

In addition to the 7 members of the ARB itself, we are building a community of volunteers to help review submitted packages, and work with the author to make the necessary changes.  There are no limits or restrictions on members of this community, though a rough knowledge of packaging will surely help.  This group doesn’t vote on applications, but they are essential to helping get those applications ready for a vote.

The ARB helpers community was launched in response to the overwhelming number of submissions that came in during the App Showdown competition.  Daniel Holbach put together a guide for new contributors to help them get started reviewing apps, and you can still follow those same steps if you would like to help out.

Again, if you would like to get involved with this community, you should join #ubuntu-arb on Freenode IRC, or contact the mailing list (app-review-board at lists.ubuntu.com).

Read more
Michael Hall

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.

Read more
Michael Hall

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.

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