Plasma/Active/Development
Development
Developing Active Apps
Plasma Active Apps are easy to create, adapt, publish and distribute. You can use Plasma Quick (which builds on top of Qt Quick and the QML declarative markup language), JavaScript, Python, Ruby, C++ and other languages to write Active Apps. We have collected a set of recommendations for writing apps that get the most out of the platform and provide a native look and feel to the user.
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
- Vocabulary
- Tutorials and examples
- Guidelines for Plasma widgets creation
- Plasma Architecture Overview
- Plasmoid and other Plasma plugin packaging
- Developing a device Shell
Interface Standards and Research
- Plasma Active Human Interface Guidelines
- Plasma User Research Profile
- The ways of the Plasma
- Recommended Reading on interaction design
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
Kubuntu packages are in the official repository starting from 13.04 (raring):
sudo apt-get 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
or
git clone git://anongit.kde.org/plasma-mobile
Source code for Contour's recommendation features can be found in the "contour" git repository, Share-Like-Connect is in the "share-like-connect" repository:
git clone kde:contour git clone kde:share-like-connect
or
git clone git://anongit.kde.org/contour git clone git://anongit.kde.org/share-like-connect
To build the Contour repository it's necessary to have installed Qt mobility 1.1 or newer. Be sure that you're using the latest shared-desktop-ontologies from git://oscaf.git.sourceforge.net/gitroot/oscaf/shared-desktop-ontologiesa and to rebuild soprano and nepomuk after updating shared-desktop-ontologies.
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 openSUSE's Plasma Active repo or the MeeGo Project 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.
Development Workflow
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 publicly, 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
Integration Workflow
openSUSE
Integration happens in the KDE:Active project within openSUSE's OBS.
MeeGo
Integration happens in Project:KDE:Devel project of the public MeeGO OBS. The kdelibs, kdebase-runtime, contour, plasma-mobile and share-like-connect modules are continously updated. A test image is regularly created from this project.
Working module revision are submitted to Project:KDE:Trunk:Testing project and after more extense testing to Project:KDE:Trunk project.
Meeting Minutes
- Plasma Active 4 planning meeting
- Brainstorming meeting on a task-centric approach for Plasma Active
- Meeting to further develop ideas on task-centric design for Plasma Active
- Going over release blocker bugs for PA4
Testing
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.
Release Management
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.