About KDE/plasma on small devices

Mon Nov 23 23:16:10 CET 2009

Well i've started the mobile shell, and it's not far... I just come back
from vacations so i will start again hacking on it.

For now, it's just a containment (mainly stole from plasma-desktop and
netbook).

I have implemented an applet to toggle the expose effect in the n900.

The road is long in order to have something usable on the n900. The applet
handle should be redisign, many applets are not finger enabled (though some
of them works quite nice).

And then the main problem is the lack of the documentation in the maemo
side. I had to reverse engineered the dbus server to find out which signal
trigger the expose effect.

On Mon, Nov 23, 2009 at 10:39 PM, Aaron J. Seigo <aseigo at kde.org> wrote:

> On November 23, 2009, you wrote:
> > > it's close, but there will be things in it that just don't fit very
> well.
> > > fortunately, plasma encourages a highly modular design and so parts
> that
> > > do make sense can be shared between plasma-netbook and plasma-mobile
> > > without much effort at all.
> > > yes; it could also be something more custom-fitted to a small screen,
> > > particularly when it comes to application transitions. see, for
> instance,
> > >  what the palm pre or even the iphone does in this area.
> >
> > So basically we would need a much more finger friendly smaller/compressed
> > plasma containment.
> > Whih shouldn't be too hard if we would "fork" the netbook maybe?
>
> perhaps; i'd suggest starting with an intended user experience design and
> work
> from there, taking what we can from other places.
>
> > > when it comes to the n900 itself, they use an expose-like effect which
> > >  would mean a different Plasma::View for each widget on the canvas.
> this
> > > is actually not uncommon (it's how popup applets work in the
> > > icon-and-dialog state, e.g. when in a panel in plasma-desktop).
>

I've actually hacked something else, a full screen app...So maemo popups
works well, like when somebody call for instance. Even the compositor do its
job.

> >
> > I would really like to keep the "footprint" as low as possible not just
>

Pointless for now, make things works fine and then you optimize.

> >  from a performance point of view but also from a position that we would
> >  have to port KWin to this special platform which could be worked around
> by
> >  adding the needed pieces upon the ready made plasma right?
>
>
KWin works out of the box without anything, it just doesn't have OpenGL
support mainly because KWin effects are using raw OpenGL which is different
from OpenGL ES 2.0. I don't think we need for now to replace the window
manager. Matchbox works quite fine.

> well, the n900 already provides this out of the box. we don't need to do
> anything there.
>
> there's the additional route of "creating a shell for any phone and do it
> from
> the ground up"; personally, i think we should target the n900 as step 1 and
> then generalize it from there. the reasons are:
>
> * we have n900s to actually run stuff on right now
> * it allows us to grow the project step by step instead of having to do
> everything at once
>
>
Having a plasma-mobile, with couple of useful applets, finger oriented.
Plasma mobile can works in full screen (in addition to the current
hildon-desktop) would be nice for a step 1. Then we can think of creating an
applet for calling and so on.

> > > >  would have the issue that you would get quite scared because most of
> > > > the mobilephone apps would have to be placed there.
> > >
> > > why would this be a problem? I'm not sure i'm seeing the issue here :)
> >
> > From what I've seen on the plasma newspaper the user would either (1)
> need
> >  to always drag the applet upon the newspaper or (2) KEEP all the
> plasmoids
> >  for these phone special stuff upon the newspaper conatinment which makes
> >  it either a hell of a mess or too much to load smooth enough for a daily
> >  workflow.
>
> it again comes back to what user experience plasma-mobile should offer.
>
> one possibility is:
>
> * there is a "home" screen that allows one to put multiple widgets on the
> screen at the same time; basically a tiny version of plasma-desktop's
> desktop
> view
>
>
That is my goal.

> * widgets can also be launched as a "full application", or full screen. in
> that case we create a separate View and show the widget in that view.
>
>
Kate for instance is already running. The problem is Oxygen and the UI, it's
not device enabled. KDE needs lot of work in that side. Plasma is probably
one of the easiest component to have on the N900 because its flexibility.

> the question is if we allow multiple applications to run or just one at a
> time. if just one at a time, then there is just one view and it can
> load/delete widgets on request. lower resource usage, but also slower
> switching between apps. this is the iPhone approach fwiu.

> if multiple, then its up to the user to not launch too many at once,
> closing
> those they don't need/want. perhaps with some automatic management added in
> as
> well to keep it from getting out of hand.
>
> as for things like the phone dialing pad, contacts .. those could be
> handled
> separately and created/shown on demand.
>
> > > > So one of the things that would need to be inplace would be
> information
> > > > for people who are not yet involved in the development.  For now
>  small
> > > > wrap up on the mailing list would help to get first pointers upon
> from
> > > > where to tackle all these issues.
> > >
> > > if you ask questions, we can provide answers :)
> >
> > Oki doke. I'll start off . It would be nice if you could give out
> pointers
> >  to the needed  svn repositories etc.
>
> svn.kde.org for the moment, with plasma-mobile in playground/base as i
> pointed
> out earlier.
>
>
It doesn't compile out of kdebase. I need to fix that :D.

> >  I haven't come around to do that. To
> >  encurage people to join us we should also to document it so others can
> >  have a look at it.
>
> agreed; we have a few steps first, particularly defining what user
> experience
> goal we want to shoot for.
>
> > When we do actually start to write application code for the
> > sms/phonecall/contacts apps for the mobile device which actual ibraries
> >  should be taken to manage that. Will we pick the freesmartphone
> libraries
> >  or will we pick on the meamo platform and keepit there?
>
> if the telephony features are put into dataengines and services, this
> becomes
> a non-issue. we can target the n900 or freesmartphone libs and use the same
> UI
> on each, just by changing which dataengine/service mix is on the device.
>
>
Me as a first step i would see Plasma running in addition of the existing
GTK framework, as an alternative to hildon-desktop (better widgets, better
freedom). Having KDE replacing the complete high level stack is for now too
much work. For instance simple things like config dialogs in Plasma
(KDialog) are completely unusable, they need a rewrite, i don't speak about
konqueror, dolphin, kate and so on.

> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20091123/b7b3b327/attachment-0001.htm 