Plasma Active SDK Notes

[Aleix Pol]

On Fri, Mar 9, 2012 at 6:25 PM, martin brook
<martin.brook100 at googlemail.com> wrote:
> 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
>

Hi!
I'll try to be there. At what time?

Aleix