Developing Active Apps
You can find documentation for many aspects of Plasma development on the following pages:
- Plasma Active Apps recommendations and guidelines
- Qt Quick documentation has everything about Qt Quick
- Tutorials and examples
- Guidelines for Plasma widgets creation
- Plasma Architecture Overview
- Plasmoid and other Plasma plugin packaging
Interface Standards and Research
Plasma SDK: Plasmate
Add-ons and widgets for Plasma Active can be created without setting up a build system, and without using C++. Plasmate is a small, custom-made IDE specifically taylored for creating Plasma widgets and other add-ons. Plasmate allows you to quickly create new Plasmoids, or 'fork' and improve existing ones.
Plasmate packages for openSUSE 11.4 can be found in sebas' OBS home repository, and installed as follows (as root):
# Add sebas' home repo, 11.4 branch zypper ar \ http://download.opensuse.org/repositories/home:/vizzzion/openSUSE_11.4/ \ sebas zypper install plasmate
More information about Plasmate can be found at here.
Plasma Active Core Development
The project page of Plasma Active with pointers to Git repository, current activity and the likes can be found here. Upstream source code for Plasma Active can be downloaded with
git clone kde:plasma-mobile
git clone git://anongit.kde.org/plasma-mobile
For development questions, please refer to the Plasma mailinglist, or the IRC Channel (see Contact).
For building Plasma Active from master, you need the "active-development/4.7" or "active-development/master" branches from kdelibs and kde-runtime. You can find suitable development packages and install them from sebas' Plasma Active repo if you don't want to build them on your system. See the Installation section for a recipe to install these packages. Proceed with building plasma-mobile from Git, using CMake and the usual development mechanism for C++ application. Note that building Plasma Active from master is only useful if you want to work on the shell itself, and even then you might still be able to get away with just editing the QML files that come with Plasma Active and define its UI and interaction.
In order to keep development fun for everybody, the work on Plasma Active is structured as follows.
- The master branch remains a stable to work on
- Features are developed in branches
- Merge of branches happens after review and consensus in the Plasma team
- Everybody is encouraged to share their branches publically, as remote branches on git.kde.org in order to keep others in the loop about ongoing activity
- Stabilization branches for releases are branched from master and then stabilized for a series of releases
Plasma Active is developed in a Scrum-like workflow. We initially start with 2-week development cycles. One cycle typically looks like this:
- Merge Window (1 week)
- Stabilization and Integration (1 week)
During the merge window, Plasma Active is open for new features, bigger visual changes, and interaction improvements. During the stabilization and integration phase, quality, integration and default setup is further improved, updated packages and installation images are created. Each cycle results in the following:
- Newly integrated features
- Visual improvements
- Improved functionality in general
- Updated packages to test and use on the target device
- An installable live image to use as testing and further development base
- An overview of the changes in this cycle
For effectively improving and assuring quality, a structured approach to testing is mandatory. Supporting the process of testing, we have defined a standardised process to develop, build and deploy the Plasma Active Core and Active Apps.
Test Builds and Snapshots
In the process up to the first release, we provide regularly updated packages and bi-weekly installation images to test Plasma Active, and to test your App on the latest state-of-the-art code. You can find installation instructions in the Installation section.
Test on the target device
It is important to test your app, or Plasma Active in general on the target device. The following aspects can not be ful
- The device is often slower
- ... has a different display in terms of resolution, pixel density and color reproduction
- ... uses different input methods, most importantly a touchscreen, a virtual keyboard
- ... uses sensors, for example rotation sensors, accelerometers or GPS
- ... API and the platform might differ between your development machine and the target device
- ... the use-cases of the target device differ wildly from desktop machines, interaction problems and optimization is very hard to do on a different form factor
We recommend a defined development / deployment / testing process, in order to achieve the best possible quality for your app -- after all, only one bug or interaction problem can turn an app from great to unusable. For quicker development cycles, it is of course also possible to run and test Plasma Active in a window on your development machine, or in a virtual machine. If you are looking for a device suitable to test Plasma Active on, head over to the Devices section.
The Plasma Active team can help you getting your app packaged and built on the openSUSE and Meego buildservices.
Plasma Active is released independently from KDE SC releases, but using the same infrastructure. Plasma Active comes out about two months after SC's 6-monthly feature releases. The Plasma Active Core team decides, based on consensus specifics to the release. Stable releases are branched at beta stage, fully stabilized there, and released as .0 with .1, .2, etc. patch releases following. The release process is managed by Sebastian Kügler.
Preliminary Release Schedule
- July, 26th Alpha (T-8W)
- Aug, 10th: Feature freeze (T-6W)
- Aug, 23rd: Beta (T-4w)
- Sept, 13th: RC (release candidate)
- Sept, 27th: Plasma Active One