About KDE/plasma on small devices

[Aaron J. Seigo]

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 would really like to keep the "footprint" as low as possible not just
>  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?

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

> > >  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

* 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.

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.

>  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.

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20091123/e1531ade/attachment.sig