Fwd: [Shr-User] What's going on in SHR land

[Sander van Grieken]

Thanks for the update!

Ever since I saw that the SHR feeds didn't get updated for a while I compiled SHR myself 
from the shr/import branch, so I already knew that there was a lot of activity going on 
under the radar.

For me the usage of opimd for contacts is the nicest new feature. It has a VCF backend, so 
I could just scp my Kaddressbook contacts over to the FR and have all my contacts 
available. nice!

Graphic speed felt a little slower though, and the interfacing with FSO was broken in some 
places, like the power management. Also the power button didn't bring up the popup menu. 
But these are all findings of a few weeks back, so most will probably be long fixed 
already.

Thanks again, looking forward to the next stable unstable release of SHR!

grtz,
Sander


On Sunday 01 November 2009 17:04:30 Thomas Zimmermann wrote:
> For the SHR users that aren't reading the SHR mailing lists i'm forwarding
> this message from spaetz:
> 
> 
> 
> Betreff: [Shr-User] What's going on in SHR land
> Datum: Sonntag 01 November 2009
> Von: Sebastian Spaeth <Sebastian at sspaeth.de>
> An: shr-devel at lists.shr-project.org, shr-user at lists.shr-project.org
> 
> Hi all, for those of you few that do not live 24/7 in IRC land, here is
> a not-so-brief update on what is happening in SHR land. No, we are not
> all dead :).
> 
> There are a couple of major transitions that have slowed down new images
> or indeed any updates in the SHR feed. Let me try to sum up a few and  I
> am sure others will chime in and list whatever I have forgotten:
> 
> - Transition from the obsolete kdrive-glamo driver to a proper xorg
> server infrastructure. This took some time, but it appears that it is
> working fine now. Don't expect any (initial) performance boosts, but
> being on a regular xorg server and having a driver that is actually
> being developed and maintained is a good thing for the future (thanks to
> Weiss and others for some really hard work here).
> 
> - More fso...d goodness. Rather than having Mickey Lauer's python
> prototyped phone backend, we are starting to his re-written bits and
> pieces (coded in vala, which should give us a nice performance boost
> over python). For the beginning we have the resource handling
> (fsoresourced) on board and look forward to the next bits and pieces. I
> know very little about the state of things here, so others might have
> more information.
> 
> -New phone apps: As if that were not enough changes, the core team
> (mrmoku, tasn, dos1, and others?) has started to redevelop the frontend
> applications for SHR. the old ophonekitd was initially developed by a
> guy called quickev who has been missing in action since quite some
> months now. Don't ask ME why, but apparently the now design allows for
> better/quicker/whatnot development. I'll let one of them speak out for
> themselves about the motivations. Besides lots of work,this gives us
> also a chance to redesign the screens and make the UI better. So goodbuy
> ophonekitd and libphone-efl, welcome phoneui, and libphoneui-shr.
> 
> -Bernd Prünzler(spelling?) is kind enough to help out with some theme
> development (BTW, you did know there is a theme contest going on, do
> you? So, go and design and submit something already!). The default theme
> has been designed for powerful desktops, and is using more transparency
> and other fancy stuff than the slow graphics can do. He is developing a
> theme that should be much faster on the Freerunner (but don't expect
> miracles, the hardware will still be barely able to drive a full
> VGA-resolution screen). So expect a big fight between dos1 (niebee
> theme) and bernd (gry theme) for the fastest performance (while
> retaining good looks).
> 
> Last but not least: what we had done the last few months, is basically
> taking a fork of OpenEmbedded and developing from that. While this gave
> us the stability to code apps without having others break our stuff (we
> are quite capabable of doing that ourselves it seems :-) ), this led to
> a quickly diverging SHR and OE tree. It was decided that we really
> should include our stuff into OpenEmbedded proper, rather than just
> doing our stuff in parallel. So we had first put all the stuff into an
> "SHR/import" git tree which is in the openembedded code repository.
> Next, mrmoku created the "shr/merge" tree which is kept in sync with the
> OpenEmbedded tree and we ported all our enhancements there. The plan is
> to take our bits and pieces from here and merge them into OE over time.
> This is where we currently stand, we want to keep using the shr/merge
> tree which gives us a current OE tree, but of courseby using more
> updated components, lots of stuff was broken. The guys have fought
> really hard in the last days (and weeks) to overcome compilation errors,
> nonbooting phones, and crashing components. It seems we are now really
> close. The new images compile fine (yay!), the phone actually boots, and
> many of the crashes have been eliminated. AFAIK, we are currently still
> stuck with a segfaulting dbus. As soon as these issues are ironed out,
> mrmoku will continue to put updated SHR-unstable images and packages
> out. This could take 1,2, or 4 days. I don't know how long and it
> depends on how good things will turn out. But there will be a new image
> soon. Expect some teething troubles with the new images at first (I am
> not sure an opkg upgrade will work), but this is all fancy new stuff
> that we are very happy about.
> 
> spaetz
> 
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>