Plasma Active SDK Notes

[Aleix Pol]

On Friday 09 March 2012 01:27:03 Sebastian Kügler wrote:
> Hi all,
> 
> Here are the notes from the breakout session at the sprint about the Plasma
> SDK and Developer story.
> 
> 
> Plasma Active SDK
> =================
> - Three "levels":
>     (0) Simple App / Widget / "fart app" (purely Plasma Quick): Plasmate,
>     (1) Complex App / Existing Qt & KDE app (C++ & Plasma Quick): Mer Plasma
> Active SDK
>         - VM image of Mer SDK
>         - additional packages (kdelibs, etc) preinstalled
>         - IDE / editor installed on the host machine, way to mount source
> code inside VM
>         - possibly IDE integration plugins to make building and installing
> easier
>         - also possibe to SSH into the VM and build
>         - easy to set up!
>     (2) System / Core development
>         - Mer PDK (not further specified at this point
>         - ask fellow developers at this point ;)
> 
> OBS Workflow
> ============
> 
> - package it, .spec file (examples on OBS)
>     - write yaml file, pass it through command
>     - coolo has a tool to import Debian packages
> 
> - upload to OBS:
>     - official repo (for example for Spark): reviewed and vetted apps
>     - contrib repo for third parties: no guarantees, basic checks to
> uploaders
> 
> Things we need to do:
>     - set up official and contrib repos
>     - document for app developer how these steps work
>     - ensure apps are actually maintainaned, not just dumped and let bitrot
> 
> Cheers,

Hi!
I know that right now it might sound weird, but now I've just seen these 
conclusions and I feel like I was not at the same place.

Right now there's no SDK whatsoever, the only way I could get to run some of 
my applications on Active was to actually do it on the device. I guess that 
applications must be important in active in the future, so a solution must be 
provided.

As I said on the "workout", having a device image is good for having an 
overview of what the end result looks like, but I don't really think that this 
is going to scale:
 - Having two snapshots of the source code can be misleading to the developer. 
We can hack around ways to minimize this, but this is all logic that we'll 
have to work out.
 - It means to run a full-blown system virtualized on a qemu (or something 
similar) and compiling stuff on it. It's going to be slow.

I understand that the plan is that people keep compiling and testing the 
programs against a locally installed KDE installation and they only compile it 
against ARM when they want to test it on the device, so why do we need an 
emulated system at all? Additionally, this solution overlaps with MerSDK in 
many levels.

Also, as I said on the workout, I'd propose to look into something like MADDE 
or something like they're doing in QtonPi.

Aleix