[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-maemo
Subject:    [Kde-maemo] Welcome to KDE/Maemo
From:       sebas () kde ! org (Sebastian =?iso-8859-15?q?K=FCgler?=)
Date:       2009-10-22 21:57:49
Message-ID: 200910222358.02391.sebas () kde ! org
[Download RAW message or body]

On Thursday 22 October 2009 23:13:07 Kevin Ottens wrote:
> Hello fellow Maemoers,
> 
> With Fremantle and the N900 almost out the door, it is time that we start a
> more coordinated effort within the KDE community to support Maemo as an
> official target system. In the past we had some scattered and not
>  coordinated efforts, results got linked on techbase:
> http://techbase.kde.org/Projects/KDE_on_Maemo
> 
> I think we need to get all the people interested into making the KDE
>  platform really usable on Maemo in order now. That's why this mailing list
>  got created, and we now have to start discussing how to achieve this goal.
>  To get there, it is likely that we want to consider Maemo as another
>  system like we do for Solaris, Windows or Mac OS X. It is very close from
>  our currently main target (Linux distros), but comes with its own specific
>  ways, hence this idea of considering it like a different system
>  altogether. Moreover, being the first time we really attempt at addressing
>  a resource constrained system, our own platform will likely benefit from
>  it.

And it's serious fun. I've got my hands on the device, and it has pretty nice 
capabilities. Its software sucks in places (email, wifi client), but surely has a lot 
of potential.

> I identified a few initial areas that we have to investigate, here they
>  are:
> 
> 1) Ensuring our platform is modular enough
> We need to be able to streamline our platform enough for such embedded
> devices. For that we need a clearer pictures of dependencies (in particular
> within kdelibs), and add flags within cmake to enable/disable the build of
> parts of our platform. Right now our dependency graph within the platform
>  is rather complex, we'd need to simplify it.

I think the koffice guys have a 'kdelibs-lite' for maemo. Would be interesting to see 
what's in there.
There are actually two dependency graphs we need to look at here, build-time and run-
time. Certain services in KDE (KTrader, for example) require a running kdeinit4, and 
will start this when they need to. This can slow down application startup 
considerably.

> 2) Packaging
> Thanks to (1) we can then provide some guidelines on packaging the platform
> (at first thinking kdelibs, kdebase-runtime and kdepimlibs here). For
> instance, most distributions package kdelibs as a single collection of
> libraries, while on embedded devices we probably want something finer
>  grained, for instance being able to install only kdecore. It is likely
>  that we also want to provide packages targetting maemo which follow the
>  developed guidelines.

This is of course different than how we deal with distribution of packages currently 
(we write code, zip it up, others package and ship it to the users; others being 
distros here). In this regard, it looks more like how the KDE Windows project works 
(they also build and distribute software directly to end users).
Mek can probably give a better idea of how much work packaging is, the target 
platform is pretty well defined, taking away some complexity.

> 3) Developing a plasma based shell for this form factor
> So far we have two main plasma shells, one targetting the desktop, one for
> netbook. There's also one cooking up in playground for media centers. We
>  need something which is suitable for smartphones like the N900. Alexis
>  M?nard from the Plasma crowd started working on such a shell (if
>  everything goes well we'll have a video to show early next week, stay
>  tuned). It's running decently already, and for now it's just a quick hack
>  to integrate in the N900. We can turn that into much more IMO.

This is probably best developed in plasma's playground. Looking forward to seeing it 
:-)

It's probably interesting to have more than one shell available. If you plug your 
N900 into the TV (works out of the box for me :)), you'll likely want media center 
functionality. Current software for those things has a separate mediacenter 
application. And input is a bit weird, if you have a relatively small phone connected 
through a thick cable to your TV. This is where remote plasmoids come extremely handy 
-- we can just remote control the device that's feeding the TV from another Plasma 
instance... OK, I'm getting carried away. :-)

> 4) Putting in shape a workflow for application developers
> Right now installing all the necessary to be able to conveniently work on
> Maemo is a difficult task, and that's probably in great part what scared
>  KDE people away from the N810. You can get really different results
>  depending on how you do it, crashes during builds, etc. We have to find a
>  way to make it easy for KDE developers to work on their application and
>  cross-build for the device. For that we might want to get in touch with
>  the Mer people and reuse their open build service, producing VMs with the
>  necessary toolchains are also an option. I'm currently working on this
>  topic, I admit basing our efforts on Mer is interesting as it is a fully
>  community driven project, but it is not yet known if we'll have technical
>  issues doing that.
> 
> As you can see, all the areas above mostly cover our libraries and runtime,
> not applications. The reason for that is that our current GUIs won't fit on
> this kind of devices. The screen size and interaction model is different
> enough that we'll probably need to write new applications, but based on the
> same platform. It leaves us with an open question though, where will we
> develop those applications? In our current modules structure? In new
> specialized mobile oriented modules (kdebase-mobile, kdepim-mobile, etc.)?

kdebase already is a huge module. :/ We will find that we share many components 
(think of libs in kdelibs, or in kdebase/workspace). Not long ago, actually 
kdebase/workspace/plasma has been split up into generic/, desktop/, netbook/. I'd say 
let's decide this when we have specific applications to ship, it probably can't be 
said in a general way.

> Of course, opinions and discussions are welcome.

I think yellow monkeys are kind of weird.
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-maemo/attachments/20091022/a4feb65f/attachment.sig 

[prev in list] [next in list] [prev in thread] [next in thread]