SoC proposal: KDE/Plasma for small form-factor devices

[Aaron J. Seigo]

On Tuesday 25 March 2008, Marijn Kruisselbrink wrote:
> would be very nice, and I don't really see what else the plasma app does
> that would not be relevant to small devices.

you already mentioned dashboard, but here's perhaps a more complete list:

* the default set of applets as defined in DesktopCorona
* PanelView (i doubt you'd need that, as you probably aren't dealing much with 
overlapping top level windows, which is the primary utility of a panel
* multiple screens and zooming control in RootWidget

so, on a rough guess, it looks like ~330 lines of the ~1200 lines of code, and 
4 out of 5 of the classes are pretty much irrelevant. since PlasmaApp relies 
on RootWidget which probably isn't needed, PlasmaApp would need some minor 
surgery. i don't know if you need/want the dbus interface either.

the code that's needed to drive a libplasma app appropriate for a phone is 
much more similar to plasmoidviewer which is ~160 lines. it just sets up a 
generic view and a generic containment; you'd probably want to set up a 
non-generic containment and resize to match the phone's screen.

so writing that bit is an afternoon's cut-n-pasting and should result in 
something that's a bit more straightforward.

to acheive the desktop/panel appearance, you can easily have two containments 
that sit right next to each other on the canvas and one view showing both. or 
you could have two views stacked one on top of the other, too, which would 
require no additions to libplasma. the PanelView in plasma adds strut 
management and moving to different edges of the screen; the latter is 
trivials beyond belief and would probably be more trivial even in a controled 
env like a phone and the strut management is likely not particularly relevant 
as i noted earlier.

> > * KConfig may be a limiter here as well. the many-text-files approach is
> > just fine for a desktop, but i wonder if there would be a win for smaller
> > devices if a KConfigBackend that used an efficient single binary store
> > would work better for things like the Neophone. that's probably a couple
> > weeks work right there, however.
>
> I'm not convinced this would really be such a great improvement; I guess
> some profiling/benchmarking would be needed to figure out if this would
> actually gain something (and than still, isn't config file
> reading/writing something that doesn't happen too often, so the speed of
> it would in most cases not be the greatest bottle-neck?)

perhaps. another avenue of exploration that would probably have even more 
impact is using KPixmapCache to store svg rendering.

> > personally, i think getting a base which works well is more important
> > than having more widgets that work right at the start, and it would
> > probably be good to prioritize things such as the above writing widgets
> > themselves. that can follow, and others can help a lot more if the base
> > is already in place.
>
> I completely agree with this; I'm just not sure yet what the base would
> contain. I guess one part of this would be to have a widget-style that
> behaves sanely on a near 300-DPI device (I'm not sure it is actually the
> style that is to blame, as using a default Qt style has the same issues
> as the oxygen has that is visible in the movie/screenshots).

this already works in qtopia so i assume it's a solve problem.

-- 
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 Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080325/7057876e/attachment.pgp