Great news! I'll wait next release, then I want to help in building extra ipk packages... d
On Mon, Nov 2, 2009 at 10:59 AM, Sander van Grieken <san...@3v8.net> wrote: > 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 <sebast...@sspaeth.de> > > An: shr-de...@lists.shr-project.org, shr-u...@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@lists.openmoko.org > > http://lists.openmoko.org/mailman/listinfo/community > > > > _______________________________________________ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community >
_______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community