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

[Marijn Kruisselbrink]

Aaron J. Seigo wrote:
> On Sunday 23 March 2008, Marijn Kruisselbrink wrote:
>   
>> I've uploaded first rough draft of my proposal on getting KDE and plasma
>> usable on small form-factor devices like a neo1973 to
>> http://eljakim.nl/~mkruisselbrink/socplasma.txt, and I'd like to get
>> your comments on it to further improve it.
>>     
>
> great start. thoughts/suggestions:
>
> * expanding on what the new Containment would do/look like/have as goals would 
> be useful since that is likely to be a large amount of the work according to 
> the proposal
>   
Hmm... yeah... I've added some notes about this.
> * i'm surprised that qt 4.4 wouldn't already compile on the neophone since 
> it's now one of the official targets for qtopia and there is just one source 
> tree for qt and qtopia? so that might be very much a minor effort consisting 
> of setting up the cross-compile env on your machine
>   
afaik Qt4.4 does only support cross-compiling the qtopia/qt-embedded 
version by default, so the patches that currently exist modify the 
configure stuff to also properly support cross-compiling the 'normal' 
X11 version.
> * another useful link, if you missed it: 
> http://aseigo.blogspot.com/2008/03/plasma-on-mobile-devices.html where i 
> talked about your video and the slowness and "low hanging fruit" for 
> improvement
>   
Yeah, I've seen it; in that you mainly talk about start-up time, which I 
think is not really that important. Overall the boot-time of the Neo is 
quite lousy, and a phone also isn't really meant to be booted/rebooted 
all the time. 'Normal' users should rarely need to reboot, instead 
suspend/resume and other low-power modes should work properly. Still 
most of the improvements you mention would probably not only help 
start-up time, but also general usage.
> while washing my hair, a few other thoughts occurred to me:
>
> * there's some 1200 LOC in the plasma binary right now. most of that is 
> probably not relevant to small devices. it may make sense to write a 
> different app that just has a main loop, a plain Plasma::View and a minimal 
> Corona subclass. there could be considerable savings to be had there as well.
>   
I'm not sure how much that would gain me; I'm afraid that in the end I 
might up with a new plasma application that has everything the 'normal' 
one has, perhaps minus the dashboard view stuff, as I think having at 
least some sort of panel to replace the current openmoko matchbox panel 
would be very nice, and I don't really see what else the plasma app does 
that would not be relevant to small devices.
> * 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?)
> 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). I believe 
Openmoko even has separate (gtk+) themes for vga and qvga devices, but I 
think it would be much nicer if one style could behave sanely on all  
devices, but I'm not sure what would be required for this.