Plasma Active SDK Notes

[Lamarque V. Souza]

Em Friday 09 March 2012, Aleix Pol escreveu:
> 
> 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.

	Not only slow, things like touchscreen-ony features (pinch and zoom), 
wifi, battery and kwin+opengl do not work in VirtualBox for example, you have 
to test them in a real device. Sound only works if you use the opensource 
version of VirtualBox plus the correct plugin or, for the binary-only version 
of VirtualBox, if you manually enable sdl's dlopen feature (sdl developers 
consider it broken). Shared folders do not work because VirtualBox is not able 
to compile its add-ons against the kernel in the image, of course, we could 
provide a rpm package with the add-ons to fix this problem (as long as that is 
permitted by VirtualBox's license).

	I do not own a tablet, I only use VirtualBox and have obs installed in 
my notebook to build rpm packages. Obs is also slow because for every package 
you build it firstly uninstalls any package that is not needed to build it and 
that takes time. There is also the fact that rpmbuild does not continue to 
build a package from the last error (after the error is fixed), you have to 
start from the begining.
 
> 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.

	For people like me that do not own a device? :-D
 
> Also, as I said on the workout, I'd propose to look into something like
> MADDE or something like they're doing in QtonPi.

	Interesting, for those using QtCreator MADDE looks nice.

-- 
Lamarque V. Souza
http://www.basyskom.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/active/attachments/20120309/35f514fb/attachment.html>