Canonical Voices

Posts tagged with 'community'

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

Welcome back to another week of Ubuntu Core Apps Hack Days!  As always we will be in #ubuntu-app-devel on Freenode’s IRC from 9am to 9pm UTC to answer all of your questions, help you get your development environment setup, and get started contributing to the Core Apps projects.

To start off this week we will be taking a look at the Calculator app.  The Calculator was another one of the original core apps, made some of the fastest progress and was one of the first to make it onto the device images’ default install.  The Calculator is as simple as it is beautiful, and thanks to this and the hard work put in by it’s developers, that means it’s already feature-complete as far as our dogfooding list was concerned:

  • Create a common calculation (subtraction, addition, multiplication etc). DONE!
  • Create a new calculation. DONE!
  • Keep previous calculations across reboots of the app and device DONE!

But even though the main features are complete, there is still some work left to be done.  Most importantly, with Ubuntu’s focus on quality these days, we need to finish up our Autopilot test coverage, which means we need the help of all your Python developers out there.  We also have a list of reported bugs that need to be fixed, which is going to require somebody with QML and/or Javascript knowledge.  If either of those suits you, please join us in #ubuntu-app-devel today to get started!

Read more
Michael Hall

Today is the last Ubuntu Core Apps Hack Day of the week, but don’t worry because we’re coming back every day next week to cover more of our amazing Core Apps.  Like previous days, we’ll be in #ubuntu-app-devel in Freenode IRC from 9am to 9pm UTC to help you get setup and contributing to these apps.

Today our focus will be the Clock app, one of the original Core Apps, and while you might think that a clock app would be simple, there’s a lot going on in this one.  In addition to showing you the current local time, the Clock app also sports a world clock, a timer, a stopwatch, and soon the ability to set alarms.  Our dogfooding goals for the clock are:

  • View local time. DONE!
  • View times in different cities. DONE!
  • Stopwatch (start, stop, pause, lap) DONE!
  • Set alarm, be notified when the alarm time arrives
  • Set timer, be notified when the time runs out

As you can see, the first 3 are already done and working.  The remaining two are blocked on platform work for setting alarms that will be triggered by the system even when the Clock app itself isn’t active.

But that doesn’t mean there’s nothing for new contributors to do.  One of the Clock’s most active developers, Nekhelesh Ramananthan, has helpfully provide me with a list of things that he needs your help with:

  • Getting autopilots tests ready for the timer, stopwatch and clock
  • Bug fixes for timer, clock and world clock
  • Caching support for sunrise/sunset times. The sunrise/sunset should only be retrieved once a day or when the location is changed. I will create a bug report to track this and also tag it hackday.

He even went so far as to tag bugs that would make good hack day targets and provide some insight into how to solve them, so you can go grab one from this list and give it a shot.  Some of these will require QML and Javascript knowledge, others are for needed Autopilot tests that need Python, so we’ve got something for everybody.  Nekhelesh (nik90) will also be in the IRC channel tomorrow to help you work on these items and review your contributions.

Read more
Michael Hall

Welcome to day 2 of the Ubuntu Core Apps Hack Days!  Once again we will be in #ubuntu-app-devel on Freenode IRC from 9am to 9pm UTC to help you get started contributing to Ubuntu Touch’s Core Apps.

Today we’re going to turn our attention to the Music app.  This app is a little bit different in the fact that it didn’t start off as a Core App, or even as a single app.  Several people had started on music apps or mockups for music apps, so we brought them together to combine their efforts into a single app.  Because of this, instead of progressing through the usual steps of defining requirements, designing user experience and then implementing features, we had all three things coming together at the same time.  This put the Music app both ahead and behind the others in different ways.

The feature targets we set out for dogfooding the Music app are all larely half-done, as a result of how the app is the amalgamation of several formerly independent efforts.  You’ll find that many of them are complete on the back-end but need to be integrated with the new front-end work, or vice-versa.  As such, this is a project where a little bit of effort can make a very large impact.  To get the Music app ready, we want to get the following working:

  • Read in music from ~/Music.
  • Browse a list of artists.
  • Browse albums by an artist.
  • Browse songs by an artist.
  • Play a song, with transport controls (Play, Stop/Pause, Skip Back/Forwards).
  • Shuffle.
  • Bonus: pull in album cover/details from the net.

To do these, you’ll need some working knowledge of QML and Javascript.  The Music app also re-uses the File Manager App’s plugin to find and read metadata of music files, so if you have C++ experience there are things you can work on there too.  And of course our Python developers can help by working on Autopilot tests to make sure that the above features work (and continue to work) as expected.

Just like the Calendar app, there are some things that we want the Music app to do that require work to be done on the platform side.  Specifically, we want the Music app to continue playing songs when you switch away from it or turn off the phone’s screen.  Currently the platform will suspend the Music app’s process when this happens, so playback stops.  However Canonical’s Jim Hodapp, who has already done a lot of work on multimedia integration and gstreamer, will soon begin work on a system-wide media playback service that the Music app will be able to hand songs off to.  Until then we will continue using the Qt Multimedia APIs to play songs while the application is still active.

Read more
Michael Hall

Today is the first of the Ubuntu Core Apps Hack Days, where we will focus on one app per day to help get new contributors setup, walk people though installing and testing the Core apps, filing bug reports and knocking out some of the outstanding feature requirements needed to get the Core Apps ready for release.

The Hack Day activity will happen in the #ubuntu-app-devel channel on Freenode IRC.  We will have dedicated helpers (myself, dpm and popey) from 9am to 9pm UTC to answer your questions, help get your setup, and review your code.  We will also have developers of the Core Apps themselves joining the channel as they can to help with your contribution.

Today we’re going to be focusing on the Calendar application, one of the original Core apps and also one of those that is already in the default device images.  Our goal for today is to get the Calendar ready for every-day use (dogfooding), which means we need to get the following features working:

  • Browse by month
  • Browse by week
  • Browse by day
  • Bonus: sync Google Calendar

To help with these, you’ll need to know some QML and/or Javascript.  You can read through our Core Apps Development Guide to get started.

In addition to these required features, we also have a load of new designs to improve the functionality and user experience for the app.  If you’re feeling like taking on a slighter larger task, and you have a good handle on building front-end functionality in QML, here’s a good opportunity to leave your mark.

We also want to fill out our automated test coverage, of which there are currently five bugs that need somebody to work on them.  Autopilot tests are all written in Python, so this is a great way for our large community of Python developers to get involved with the Core Apps projects.

Read more
Michael Hall

This is my third Core Apps update, you can go back and read about the Clock and Calendar apps if you missed them.  Today I’m going to show off the Calculator app.

Calculator Features

Basic Functions

The Calculator does exactly what you would expect a calculator to do.  It’s a four-function calculator and does it’s job perfectly well.  But it has a few unique features that make it so much more useful.  Using the old paper-roll calculators as inspiration, the calculator lets you label the numbers in your calculation, so you can go back and see “7 what?”.  When you’re done with a calculation, instead of clearing it off, you simply drag upwards to “tear off” that individual calculation.

Calculation History

Just because you’ve torn off a calculation, doesn’t mean you’ve thrown it away.  Instead, your calculation is stored in a browseable history.  This makes the labels even more useful, because you can go back hours, days, even months to an old bit of calculating.  You can even tap on any number in any of those calculations to insert it into your current one.  If you really are done with a calculation, you can swipe it to the right or left to delete it from your history.

Visual Designs

The Design team says we’ll have visual designs for the Calculator later this week, so the developers will be able to start on implementing those.  Keep an eye on the design team blog and Google+ to see them when they come out.

Release Schedule

The release schedule for the Calculator is the same as the Clock.  It’s already well past what would be considered an Alpha release, so we just called May for that milestone.  Going forward, we plan on delivering a Beta in July that includes the visual designs, followed by a final release in August.

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

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

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

Shortly after announcing the Ubuntu Phone, we made an ambitious and frankly unprecedented decision to make the development of the phone’s core apps a community initiative.  We weren’t just open sourcing the apps being developed by Canonical (though we did that too), we would let the community drive the design and development of what would become the foundation of the Ubuntu Touch app ecosystem.  And we would do it ten short months.

Work Item Tracking

Building 11 apps in less than a year is a lot of work, and tracking that work is itself a lot of work.  To do this, we are using the same tools and process as the rest of Ubuntu’s development.  This means using Launchpad for code hosting and bug tracking.  But more importantly, it also means using Blueprints for planning, breaking the work into individual tasks, and assigning those tasks to individual contributors.  This also allows us to use the Ubuntu Status Tracker to view the progress being made on those tasks.  As of right now, that chart looks like this:

As you can see, when we started tracking them we had about 165 work items defined, and about 140 left to finish.  As tasks are completed, and the developer updates the Blueprint with the new status of the work item, the orange part of the chart will shrink, and the green part will grow.  If we can keep the green part on or below the black line, then we’re on track to finish them all by our October goal.

Milestones

Ten months is a short amount of time to build a collection of well designed and polished apps, but it’s also a very long time for planning development work.  In order to narrow our focus and concentrate on immediate development tasks, we’ve further broken down the development period into a number of milestones, one for every month between now and October.

So instead of planning out the entire cycle, we will be scheduling tasks on a monthly basis.  This will make the amount of work seem less daunting, and also give us a more agile cycle of planning, development, and evaluation.  Each milestones will in turn get it’s own burn-down chart, so we can track the progress being made within the month as well.

Development Teams

Work items are also separated by team, which allows us to track the progress of individual projects, as well as the overall projects of the core apps campaign.

This allows teams to easily check if they are on track to complete their project  by October, and also gives them an idea of how much (or how little) work remains to be done.

Next Steps

The first milestone, coreapps-13.10-month-0 is coming up in mid-April.  For this milestone, we have been scheduling work items that were already making good progress, or that were small enough they could be completed in the two weeks between when it was defined and when it ends.

The milestone after that, ubuntu-13.10-month-1, ends mid-May, and will be our target for an alpha-level release of most of the apps.  As you can see, there is still a lot of work to be done between now and then, but we are currently below the burn-down line, so as long as we keep the momentum going we will make that goal.

Everything not currently scheduled for one of these two milestones is targeted to the final October goal.  Sometime in May we will begin scheduling work items for the coreapps-13.10-month-2 milestone, based on the progress made on these first two miles.

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

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

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
Michael Hall

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

Previews for all!

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

Better, faster, simpler Previews

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

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

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

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

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

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

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

    return preview

Read more