About KDE/plasma on small devices

[Andreas Marschke]

> well, pieces will be in 4.4, such as the keyboard. the plasma-mobile shell
> doesn't have a target date yet, but is at least started.
I'm very keen on seeing  how you guys  designed  the keyoard in diffrence what 
I had in my head about it.
> 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?

> i really think, given the size of the device, that an emphasis on full
>  screen apps and switching easily between them with nice visual effects
>  would be good.
 
> 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?
 
> >  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.
> > Another ,  more userfriendly, approach could be to add
> > containments/activities for sms/phonecalls/videos or what ever somebody
> >  would want to use there. These would then added dynamically as a new
> >  Activity you would switch them by providing the
> > activities-switch-plasmoid in each activities panel. Unfortunately I am
> > not fully aware about how easy/hard it is to do things like that.
> 
> creating Containments (which we call "Activities" in the user interface
>  when they are on the desktop layer in plasma-desktop or the top bar in
>  plasma- netbook) is trivial: Corona::addContainment. then it's just a
>  matter of deciding when that should be called.
> 
> as for creating containments for each ... it might make sense to just
>  create plasmoids for each and treat them more or less like any other
>  widget.
And then "just" Corona::addContainment with this plasmoid in it? 
I would rather see  Morpheuz's plasmoidviewer on steroids there as this is 
would might keep a good flat load there I believe. But this should be better 
clarified by performance tests. 
> i also wonder how much of the "this is a phone, let's make a phone call"
> interface could be put behind/inside a DataEngine/Service pair.
Definitely a good idea for a DataEngine that would (a) hold the calls /contacts 
and so on. 
> > 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. 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. 
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?
This is something to be clear about as we would ,unwantedly ,either disclose 
others from helping or bring problems to the distributers as they would have 
to decide how to pick their stack together. 

Cheers,

Andreas Marschke.