About KDE/plasma on small devices

[Marco Martin]

On Monday 23 November 2009, Andreas Marschke wrote:
> > 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?

something to fork, something not,
before doing testing on the real thing on what it works and what it doesn't 
everything is just conjectures i think

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

depends if you want to have the possibility of have any application != plasma 
running on it, if so you need windows.
a kind of task switcher could be done with something similar to the zui.
trascuring for a while the horrid performance of view scaling, not sure is a 
good idea anyways...

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

i think we should have 2 processes: one for the main launcher/ui (maybe the 
most fundamental thing too, the phone dialer itself) one for the 
"applications" (and that a thing i've already started in playground

> > > 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.
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
> 


-- 
Marco Martin