Plasma Active SDK Notes

[martin brook]

Aleix Hi,

Your right that we don't have an app developers SDK story at the moment bit
work is going on in the Mer area, see
http://mer.bfst.de/meetings/mer-meeting/2012/mer-meeting.2012-03-09-10.01.log.html.
 I note the next stage is to concentrate on the app development area.

I did take notes from you during the sprint about your current workflow
with madde and kdevelop and will feed these into the work going on in the
Mer SDK area,  The next Mer SDK meeting will be next Friday in #mermeeting
and you are welcome there to make sure we are going in the right direction
for your workflow.

BR

vgrade


On Fri, Mar 9, 2012 at 5:02 PM, Aleix Pol <aleixpol at kde.org> wrote:

> 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
>
> _______________________________________________
> Active mailing list
> Active at kde.org
> https://mail.kde.org/mailman/listinfo/active
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/active/attachments/20120309/dbdc3809/attachment-0001.html>