Canonical Voices

Posts tagged with 'foss'

Michael Hall

I’ve been using Ubuntu on my only phone for over six months now, and I’ve been loving it. But all this time it’s been missing something, something I couldn’t quite put my finger on. Then, Saturday night, it finally hit me, it’s missing the community.

That’s not to say that the community isn’t involved in building it, all of the core apps have been community developed, as have several parts of our toolkit and even the platform itself. Everything about Ubuntu for phones is open source and open to the community.

But the community wasn’t on my phone. Their work was, but not the people.  I have Facebook and Google+ and Twitter, sure, but everybody is on those, and you have to either follow or friend people there to see anything from them. I wanted something that put the community of Ubuntu phone users, on my Ubuntu phone. So, I started to make one.

Community Cast

Community Cast is a very simple, very basic, public message broadcasting service for Ubuntu. It’s not instant messaging, or social networking. It doesn’t to chat rooms or groups. It isn’t secure, at all.  It does just one thing, it lets you send a short message to everybody else who uses it. It’s a place to say hello to other users of Ubuntu phone (or tablet).  That’s it, that’s all.

As I mentioned at the start, I only realized what I wanted Saturday night, but after spending just a few hours on it, I’ve managed to get a barely functional client and server, which I’m making available now to anybody who wants to help build it.

Server

The server piece is a very small Django app, with a single BroadcastMessage data model, and the Django Rest Framework that allows you to list and post messages via JSON. To keep things simple, it doesn’t do any authentication yet, so it’s certainly not ready for any kind of production use.  I would like it to get Ubuntu One authentication information from the client, but I’m still working out how to do that.  I threw this very basic server up on our internal testing OpenStack cloud already, but it’s running the built-in http server and an sqlite3 database, so if it slows to a crawl or stops working don’t be surprised.  Like I said, it’s not production ready.  But if you want to help me get it there, you can get the code with bzr branch lp:~mhall119/+junk/communitycast-server, then just run syncdb and runserver to start it.

Client

The client is just as simple and unfinished as the server (I’ve only put a few hours into them both combined, remember?), but it’s enough to use. Again there’s no authentication, so anybody with the client code can post to my server, but I want to use the Ubuntu Online Accounts to authenticate a user via their Ubuntu One account. There’s also no automatic updating, you have to press the refresh button in the toolbar to check for new messages. But it works. You can get the code for it with bzr branch lp:~mhall119/+junk/communitycast-client and it will by default connect to my test instance.  If you want to run your own server, you can change the baseUrl property on the MessageListModel to point to your local (or remote) server.

Screenshots

There isn’t much to show, but here’s what it looks like right now.  I hope that there’s enough interest from others to get some better designs for the client and help implementing them and filling out the rest of the features on both the client and server.

communitycast-client-1communitycast-client-2communitycast-client-3

Not bad for a few hours of work.  I have a functional client and server, with the server even deployed to the cloud. Developing for Ubuntu is proving to be extremely fast and easy.

 

Read more
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

Ubuntu API Website

For much of the past year I’ve been working on the Ubuntu API Website, a Django project for hosting all of the API documentation for the Ubuntu SDK, covering a variety of languages, toolkits and libraries.  It’s been a lot of work for just one person, to make it really awesome I’m going to need help from you guys and gals in the community.

To help smooth the onramp to getting started, here is a breakdown of the different components in the site and how they all fit together.  You should grab a copy of the branch from Launchpad so you can follow along by running: bzr branch lp:ubuntu-api-website

Django

First off, let’s talk about the framework.  The API website uses Django, a very popular Python webapp framework that’s also used by other community-run Ubuntu websites, such as Summit and the LoCo Team Portal, which makes it a good fit. A Django project consists of one or more Django “apps”, which I will cover below.  Each app consists of “models”, which use the Django ORM (Object-Relational Mapping) to handle all of the database interactions for us, so we can stick to just Python and not worry about SQL.  Apps also have “views”, which are classes or functions that are called when a URL is requested.  Finally, Django provides a default templating engine that views can use to produce HTML.

If you’re not familiar with Django already, you should take the online Tutorial.  It only takes about an hour to go through it all, and by the end you’ll have learned all of the fundamental things about building a Django site.

Branch Root

When you first get the branch you’ll see one folder and a handful of files.  The folder, developer_network, is the Django project root, inside there is all of the source code for the website.  Most of your time is going to be spent in there.

Also in the branch root you’ll find some files that are used for managing the project itself. Most important of these is the README file, which gives step by step instructions for getting it running on your machine. You will want to follow these instructions before you start changing code. Among the instructions is using the requirements.txt file, also in the branch root, to setup a virtualenv environment.  Virtualenv lets you create a Python runtime specifically for this project, without it conflicting with your system-wide Python installation.

The other files you can ignore for now, they’re used for packaging and deploying the site, you won’t need them during development.

./developer_network/

As I mentioned above, this folder is the Django project root.  It has sub-folders for each of the Django apps used by this project. I will go into more detail on each of these apps below.

This folder also contains three important files for Django: manage.py, urls.py and settings.py

manage.py is used for a number of commands you can give to Django.  In the README you’ll have seen it used to call syncdbmigrate and initdb.  These create the database tables, apply any table schema changes, and load them with initial data. These commands only need to be run once.  It also has you run collectstatic and runserver. The first collects static files (images, css, javascript, etc) from all of the apps and puts them all into a single ./static/ folder in the project root, you’ll need to run that whenever you change one of those files in an app.  The second, runserver, runs a local HTTP server for your app, this is very handy during development when you don’t want to be bothered with a full Apache server. You can run this anytime you want to see your site “live”.

settings.py contains all of the Django configuration for the project.  There’s too much to go into detail on here, and you’ll rarely need to touch it anyway.

urls.py is the file that maps URLs to an application’s views, it’s basically a list of regular-expressions that try to match the requested URL, and a python function or class to call for that match. If you took the Django project tutorial I recommended above, you should have a pretty good understanding of what it does. If you ever add a new view, you’ll need to add a corresponding line to this file in order for Django to know about it. If you want to know what view handles a given URL, you can just look it up here.

./developer_network/ubuntu_website/

If you followed the README in the branch root, the first thing it has you do is grab another bzr branch and put it in ./developer_network/ubuntu_website.  This is a Django app that does nothing more than provide a base template for all of your project’s pages. It’s generic enough to be used by other Django-powered websites, so it’s kept in a separate branch that each one can pull from.  It’s rare that you’ll need to make changes in here, but if you do just remember that you need to push you changes branch to the ubuntu-community-webthemes project on Launchpad.

./developer_network/rest_framework/

This is a 3rd party Django app that provides the RESTful JSON API for the site. You should not make changes to this app, since that would put us out of sync with the upstream code, and would make it difficult to pull in updates from them in the future.  All of the code specific to the Ubuntu API Website’s services are in the developer_network/service/ app.

./developer_network/search/

This app isn’t being used yet, but it is intended for giving better search functionality to the site. There are some models here already, but nothing that is being used.  So if searching is your thing, this is the app you’ll want to work in.

./developer_network/related/

This is another app that isn’t being used yet, but is intended to allow users to link additional content to the API documentation. This is one of the major goals of the site, and a relatively easy area to get started contributing. There are already models defined for code snippets, Images and links. Snippets and Links should be relatively straightforward to implement. Images will be a little harder, because the site runs on multiple instances in the cloud, and each instance will need access to the image, so we can’t just use the Django default of saving them to local files. This is the best place for you to make an impact on the site.

./developer_network/common/

The common app provides views for logging in and out of the app, as well as views for handling 404 and 500 errors when the arise.  It also provides some base models the site’s page hierarchy. This starts with a Topic at the top, which would be qml or html5 in our site, followed by a Version which lets us host different sets of docs for the different supported releases of Ubuntu. Finally each set of docs is placed within a Section, such as Graphical Interface or Platform Service to help the user browse them based on use.

./developer_network/apidocs/

This app provides models that correspond directly to pieces of documentation that are being imported.  Documentation can be imported either as an Element that represents a specific part of the API, such as a class or function, or as a Page that represents long-form text on how to use the Elements themselves.  Each one of these may also have a given Namespace attached to it, if the imported language supports it, to further categorize them.

./developer_network/web/

Finally we get into the app that is actually generates the pages.  This app has no models, but uses the ones defined in the common and apidocs apps.  This app defines all of the views and templates used by the website’s pages, so no matter what you are working on there’s a good chance you’ll need to make changes in here too. The templates defined here use the ones in ubuntu_website as a base, and then add site and page specific markup for each.

Getting Started

If you’re still reading this far down, congratulations! You have all the information you need to dive in and start turning a boring but functional website into a dynamic, collaborative information hub for Ubuntu app developers. But you don’t need to go it alone, I’m on IRC all the time, so come find me (mhall119) in #ubuntu-website or #ubuntu-app-devel on Freenode and let me know where you want to start. If you don’t do IRC, leave a comment below and I’ll respond to it. And of course you can find the project, file bugs (or pick bugs to fix) and get the code all from the Launchpad project.

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

This is it, the final day of the Ubuntu Core Apps Hack Days!  It’s been a long but very productive run, and it doesn’t mean the end of your chance to participate.  You can always find us in #ubuntu-app-devel on Freenode IRC, and for today either myself (mhall119) or Alan Pope (popey) will be at your beck and call from 9am to 9pm to help you get setup and started working on the Core Apps.

The last of the Core Apps, and the one we will be focusing on today, is the Stock Ticker. Originally developed by independent developer Robert Steckroth, we recently invited the Stock Ticker into the Core Apps project where we have been focused on refining the UI and setting it up for automated testing.  Feature wise, the Stock Ticker was already dogfoodable when we brought it under the Core Apps umbrella:

  • Search for stocks. DONE!
  • Add stocks to your portfolio. DONE!
  • Browse current stock prices. DONE!
  • Browse stock information. DONE!

For the UI we asked community designer Lucas Romero Di Benedetto to produce some new visual designs for us, which are looking incredible!  But it’s going to take a lot of work to implement them all, so we really need some more developers, especially those who know their way around QML, to help us with this.

Read more
Michael Hall

We only have 2 days left in the Ubuntu Core Apps Hack Days!  I hope everybody who has participated has enjoyed it and found it informative and helpful.  If you haven’t participated yet, it’s not too late!  Come join us in #ubuntu-app-devel on Freenode’s IRC network anytime from 9am to 9pm UTC and ping either myself (mhall119) or Alan Pope (popey) and we’ll help you get setup and show you where you can start contributing to the Core Apps.

Mmmmmm, Pie....Today we get another chance to play while we work, because the focus is going to be on Dropping Letters, a simple, fun, yet surprisingly addictive little app written by Stuart Langridge.  Stuart has since handed off development of the app to others, but not before having it already in perfectly usable state.  Because of it’s simplicity, our list of dogfooding requirements wasn’t very long:

  • Start a new game. DONE!
  • View high scores.

Short as the list may be, it’s only half done!  We still need to integrate a high scores screen, which means we need you Javascript and QML developers!  Dropping Letters also needs to be tested, which means Autopilot, which of course means we have something for you Python hackers too!  So come and join us today in #ubuntu-app-devel and help make this great game even better.

Read more
Michael Hall

We’re back again for another Ubuntu Core Apps Hack Day!  As always you can find us in #ubuntu-app-devel on Freenode IRC from 9am to 9pm UTC, you can ping me (mhall119) or Alan Pope (popey) and we’ll help you get setup with a development environment and a copy of the Core Apps source code so you can start hacking.

Today’s app is one that was most requested when we announced Ubuntu on phones, and has since proven to be one of the most often used by developers and testers the like.  That’s right, I’m talking about the Terminal!  The Terminal went through very rapid development, thanks to the herculean efforts of one very talented developer, and the ability to re-use the KTerminal QML component from KDE’s Konsole project.  Because of both, the Terminal app has been dogfoodable for a while now.

  • Issue commands. DONE!
  • Use case: ssh into another computer. DONE!
  • Use case: edit a file with vi. DONE!
  • Use case: tail a log file. DONE!
  • Use case: apt-get update. DONE!

But that doesn’t mean that the work here is done.  For starters, we need to make sure that changes to the KTerminal code are submitted back upsteam, something we could certainly use some help from somebody who is familiar with either Konsole’s development specifically or KDE in general.  We also want to improve the availability of special keys like the function keys and ctrl+ combinations that are oh so useful when interacting with the command line, so anybody with QML/Javascript experience or who is familiar with the on-screen keyboard specifically would be able to help us out quite a bit here.

Read more
Michael Hall

Last week was certainly an exciting one, between the Ubuntu Edge campaign announcement and several coworkers being at OSCON, I wasn’t able to keep the Hack Days going.  So we’ve decided to pick up where we left off this week, covering the remaining Core Apps on our list.  Just like before we’ll be hanging out in #ubuntu-app-devel on Freenode IRC from 9am to 9pm UTC, and will be more than happy to walk you through the process of getting started.

Today we’re going to work on the Document Viewer, a necessary app for most people, which is at the same time both simple and very complicated.  The app itself doesn’t require a lot of functionality, but it does need a lot of behind-the-scenes components to load and render documents of different formats.  Great progress has already been made on our dogfooding requirements list:

  • Load a text file. DONE!
  • Load an image file. DONE!
  • Load a PDF.
  • View the file. DONE!
  • Forward/back pages on PDF.
  • Pinch to zoom.

Until just yesterday, there wasn’t a released version of our desktop PDF library (Poppler) that had Qt5 bindings.  However, with the release of Poppler 0.24 yesterday, we should not be ready to start implementing the PDF support.  We also need to replace the existing C++ wrapper used to launch the app with the new Arguments QML component, but when we do that we’ll need another QML plugin that will give us the mime-type of the files that are being loaded.  And of course we need to make sure we have full Autopilot test coverage for all of these parts.  So whether your skill set is Python, QML, Javascript or C++, there is something you can contribute to on this app.

Read more
Michael Hall

We’ve had a great week running the Ubuntu Core Apps Hack Days so far, we’ve seen several new contributors join our development teams, and lots of merge proposals coming in and landing.  But we’re not done yet, we’ll be in #ubuntu-app-devel again today from 9am to 9pm UTC to help anybody who is interested in getting started contributing to these apps.

Today we’ll be focusing on an app that may not be high on the average user’s list of mobile apps, but is indispensable for anybody working on a ported image or writing an app for Ubuntu Touch, that is the File Manager App!

Thanks to reusing the Folder List Model QML Plugin from the Nemo Mobile project, the File Manager developers were able to get a very functional application working in a very short amount of time.  That means that our dogfooding list is already complete!

  • Browse folders. DONE!
  • View files within folders. DONE!
  • View file information. DONE!
  • Copy files. DONE!
  • Delete files. DONE!
  • Move files. DONE!

But don’t let that list fool you, there’s still plenty of work to be done.  The biggest one is making sure that any changes we’ve made to the Nemo plugin are sent back upstream.  If anybody from the Nemo project can help us with this, please find me (mhall119 on IRC).  We also need to make sure we have full Autopilot test coverage, and fix any remaining bugs that have been reported.

Read more
Michael Hall

I hope you all enjoyed spending some time playing Sudoku yesterday, because we’re back to work again for another Ubuntu Core App Hack Day!  As always you can find us in #ubuntu-app-devel on Freenode IRC from 9am to 9pm UTC to answer all of your app hacking questions, help get you setup and started contributing, or just generally discuss how to write Ubuntu Touch apps in general.

Today we leave behind yesterday’s light hearted fun and games and turn to the (only slightly) more serious work of reading news with the RSS Reader app!  Another one of the original Core Apps, the RSS Reader got some unexpected designs from the Canonical Design team that converted it from the typical list-of-headlines to a beautiful organic grid seen here.

Because of these very recent and very major changes to the UI, there’s a lot of work to be done to get all of the previous functionality working again at the same level.  For dogfooding the RSS Reader, these are our goals:

  • Add a feed.
  • Browse feeds. DONE!
  • View a feed.
  • Select an item to view from within the feed.

Because of the major changes, this app can use a lot of help from people who are simply willing to use it and report bugs so that the developers (and all of you new contributors) have a list of things to work on.  Then we need you QML/Javascript hackers to pick things from that list and start making and submitting your fixes.  Finally we need Autopilot tests written or updated for this new look, so I’m looking at you Python guys and gals to lend us a hand too.

Read more
Michael Hall

We’re continuing our Ubuntu Core Apps Hack Days again today in the #ubuntu-app-devel channel on Freenode IRC, from 9am to 9pm UTC.  If you want to learn more about the Core Apps and how you can get involved, jump into the channel and give myself (mhall119), Alan Pope (popey) or David Planella (dpm) a shout.

We’ve been working hard on the Core Apps lately, which is why I’m glad that today we get spend time on something a little more fun: the Sudoku App!  Sudoku was originally developed outside of the Core Apps umbrella, but it progressed so quickly and fit Ubuntu Touch so well, that we invited it’s developer to join the rest of our Core Apps.

Sudoku was so far along before joining the Core Apps, that our dogfooding list was already largely complete:

  • Start a new game DONE!
  • Record and display game statistics DONE!
  • Provide hints DONE!

But even as complete as it is, there are still a few bugs to squash and some final Autopilot tests to write, so if you have QML and Javascript skills or Python skills and can spare a little bit of your time, you can help us put the finishing touches on this classic game.  And if you want to help us, you know, “test” it for a few hours of your day, we’ll totally consider that a contribution too.

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

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

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

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

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

Read more
Michael Hall

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

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

JFDI

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

Where is stands now

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

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

What comes next

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

Where you come in

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

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

Getting started

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

Some things you can try are:

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

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

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

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

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

Read more