DevelopmentGuide

Differences between revisions 21 and 25 (spanning 4 versions)
Revision 21 as of 2013-02-14 19:01:51
Size: 10605
Editor: dpm
Comment: Fixed blueprint links markup
Revision 25 as of 2013-03-11 10:16:49
Size: 10814
Editor: dpm
Comment: Added TOC
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was renamed from UbuntuPhone/CoreApps/DevelopmentGuide
Line 3: Line 4:
<<Include(UbuntuPhone/CoreApps/Contents)>> <<Include(Touch/CoreApps/Contents)>>
Line 6: Line 7:

||<tablestyle="float:right; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents>>||
Line 140: Line 143:
<<Anchor(Workflow)>>

Development Guide

Before Your Start

There are a few things you should do before you start hacking:

  • Download and install the SDK from the Ubuntu App Developer Site - you should also run through the tutorial to get acquainted with the technology.

  • Sign the Contributor Agreement - email Kevin Wright for details - we need to ask folks to sign this as many carriers and handset manufacturers require specific license agreements, and this allows us to dual-license the code between both a a fully Free Software license and a license that might be required for a handset manufacturer or operator.

Getting Started

Here is how you get started. If you have any questions, feel free to email Kevin Wright

Join The Mailing List

You should first join the ubuntu-phone mailing list. To do this, head over to https://launchpad.net/~ubuntu-phone/+join and join the open team. You can see the list archives at https://lists.launchpad.net/ubuntu-phone/

When sending emails to the list, please put app name from the Launchpad project in square brackets in your subject line. As an example, for the Calendar app:

[Calendar] My subject title

This helps us to filter the list better.

Getting The Code

To get the code, go to the wiki page for the app you are interested in and click the Launchpad Project link. You can then see how to branch the code.

For example, for the calendar you run:

bzr branch lp:ubuntu-calendar-app 

Using Bzr

Bzr is the primary version control system used by Ubuntu and Ubuntu projects. Bzr is quite like other distributed version control systems, just as Git and Mercurial in that you have both a local checkout and the full branch history locally. This allows you to branch, commit and merge code without being connected to a central server.

When you branch the project's code (using the command above), you get the full history of the branch, with the tip (HEAD) checked out in your new directory. When you make changes to this code you will need to commit is to your branch history by running:

bzr commit -m "Commit Message"

This commits your changes to your local branch history, but not to the remove Bzr branch that you pulled from. You can commit as much as you like to this local branch history until you are ready to submit all of your changes back to the original branch.

When you are ready to submit your changes, you will need to push them back to Launchpad. You should not push to the same branch you pulled from however, instead you should push to a new branch location where you changes can be reviewed before making it way to trunk. Do do this, run the following command:

bzr push lp:~<your_launchpad_username>/ubuntu-calendar-app/<unique_branch_name>

You'll need to have a launchpad profile, and give your branch a unique name that you can use to identify it. Replace ubuntu-calendar-app with the name of the project you are working on. You can then open the new branch in your browser with:

bzr launchpad-open lp:~<your_launchpad_username>/ubuntu-calendar-app/<unique_branch_name>

Using Launchpad

Once your code is in Launchpad, you need create a Merge Proposal to submit it back to the trunk branch. When you open your branch in the browser, you will see the following link:

propose_for_merging.png

On the next page you will provide a description of your changes to help the reviewer understand what they are looking at or looking for. The more information you provide here, the easier it will be for the reviewer. If your merge proposal needs more work, the reviewer will leave you comments on the new merge proposal's page. If it is accepted, your branch will be merged into the project's trunk, there is nothing more you need to do.

You can continue to commit code to your local branch, and your merge proposal will be updated when you run bzr push again to the same location. You should limit what you push to this branch to only what is necessary for the fix or feature you are implementing. If you want to work on some other aspect of the project, you should create a new local branch and push to a new remote location.

For Developers

Ubuntu Phone Core App Development Principles

In developing the Ubuntu Phone Core Applications we will be using a declarative approach for creating the user experience. The Ubuntu SDK includes QtQuick2 for this purpose, and we will be creating our applications in a way that maximizes our use of this amazing technology.

If you are familiar with QtQuick in general already, and especially QtQuick2, then you might still find this short guide useful in describing the principles we would like to adhere to during development.

Please note we do not support QtQuick1, so to keep things simple, when you read QtQuick in the remainder of this document it will be referring to QtQuick2. You may notice that the terms will be used interchangeably.

QtQuick is primarily the combination of the QtDeclarative engine and QML scripting language. While the engine is used for interpreting one or more QML files, it additionally supports interpreting Javascript and plugins written in Qt C++. At the same time the declarative engine is itself called and controlled by a binary application (e.g. qmlscene or a custom C++ wrapper application).

When developing in a declarative centric way we wish to minimize relying on the application that instantiated the runtime. Instead we will push as much application logic to Javascript, in simple use cases, and to C++ plugins when we need something more complex. In this way we can abstract the logic in an efficient way, expose it to QML and take better advantage of the power inherent in the declarative runtime.

The description above is a simplification of the split between when to use Javascript and C++. It is not always a case of simple versus complex logic. Javascript can sometimes simply be the better way of doing something. For example, extending UI components with Javascript can be, and often is, much better than C++ in the majority of cases. At the same time plugins written in C++ are the better choice when using the various Qt container classes available to developers.

In addition to this, there are cases where a thin C++ wrapper around the declarative engine isn't enough, and no amount of Javascript or QML plugins are going to help. We suspect that this will come up, but for the core applications we want to avoid these situations as much as possible so that we can keep things portable and avoid other complications or maintenance headaches.

So to summarize the principles:

  1. When defining your user interface it will be done in QML
  2. When you need to extend UI elements and for simple logic start with Javascript
  3. If things get too difficult, not possible, or not relevant with Javascript create a C++ plugin for QML and import it
  4. When all else fails or the above simply is not appropriate then improve the C++ that controls the declarative engine

Feature Development

join meetings

coordinate features in meetings and on the list

Use Blueprints to Track Work

Fixing Bugs

find the bugs list

assign the bug to you

fix the bug and submit as a merge proposal

Talking about your work

While you are working on one of these Core Apps, it's always nice to show off your progress and get input from the wider community. Posting screenshots or, better still, screencasts will let non-developers and future users see what is being done. Raising excitement around your contributions is also a great way to get more people involved in making them.

If you have a personal blog, you can use it to chronicle your Core Apps contributions, solicit feedback and comments, and generally make people aware of what you are doing. If you are an Ubuntu Member you can also have these posts syndicated to the Ubuntu Planet for even more exposure. Using a specific tag (in Wordpress, for example) will also allow people to easily find all of your related posts.

You are also encouraged to use the Ubuntu Phone Mailing List (mentioned above) to talk about major features or milestones, ask for design input, or to seek advice on how best to implement something. Not only will you be able to receive help from the mailing list, but you will also show how active the development is.

Finally, you can use the existing Ubuntu communities on Reddit and Google+ to show people your app or feature and get it noticed.

For the Project Team

Workflow Overview

Development workflow diagram

Reviewing Branches

how to review someone elses branch

Triaging Bugs

how to manage bug reports and get them ready for developers

Promoting the project

How to publicly promote the project, plans and progress

Touch/CoreApps/DevelopmentGuide (last edited 2014-06-05 12:10:08 by popey)