Re: Aurora
Hi Simon, Many thanks for your explanations of Aurora. I think I understand now, at least as regards what you are trying to do, and why. I have just one further comment below. On 17 May 2011 06:57, Simon Busch wrote: > Aurora is not about fragmentation. Zhone was already there before SHR > and Aurora will continue Zhone. We will take aurora as our new reference > application as it is quite simple and let us integrate new features very > fast. One question, then, is how will Aurora be different from Zhone? Having worked a bit with Zhone myself, I'd say that - on the one hand, its code seems pretty accessible and easy to experiment with - but on the other hand, it feels relatively hard to add completely new features into the UI (possibly because of my own familiarity with the Edje/embryo stuff). Is that roughly your feeling too? If it is, how will you make Aurora better? Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] faenqomod updated
Hi! This [ยน] is a little update of FaenqoMod, changelog: - added two icons for the addressbook; - new layout for the home screen with a BIG clock (: - new layout for the titlebar with the great return of the clock close to the battery icon; Screenshots at http://db.tt/vG5D0yZ I am grateful if Radek can make the deb (: Regards Joif [1] https://www.dropbox.com/s/2dnc2ld9pthmahn/faenqomod.tar.gz -- View this message in context: http://openmoko-public-mailinglists.1958.n2.nabble.com/QtMoko-faenqomod-updated-tp6090693p6387833.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Aurora
> Although we have seen a welcome level of standardization > via kernel class devices in the past years, there are still > too many home-grown vendor solutions and interfaces developed > out of the kernel tree. All those we (FSO) have to adapt > to provide a unified experience to the application level. And to expand on that... some of those device specifics have to be reverse engineered. As a scaring prime example: In September 2009, we launched the 'FSO on Palm Pre' challenge, trying to get a GSM voice call running within one month. Boy, how did we fail :) It took us (or rather 'Morphis, our hero') the better part of 12 months to get a proof of concept done. Even today, almost 20 months after we started working on the Pre, we don't have full coverage, e.g. we just started to work on SMS, and GPS is also still lacking. Our friends over @ HTC-Linux can sing many songs on that as well. And our friends from OpenEZX can tell a story as well... it has been 6 years now since the A780 has been introduced with Linux 2.4. Guess what, it's still not fully supported in kernel 2.6, i.e. no ALSA, no GPRS, no GPS. -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Aurora
Am Freitag, den 20.05.2011, 19:57 +0200 schrieb Enrico Zini: > On Mon, May 16, 2011 at 06:02:58PM +0200, Michael 'Mickey' Lauer wrote: > > > SUPPORTED DEVICES > > > > We decided to only support the Palm Pre devices (Pre/Pre Plus/Pre 2) for > > the first to-be-released version of Aurora. More > > supported devices will join after the 0.1 release. This decision has > > been forced by the fact that we are only very few people > > working both on FSO and Aurora (and also on OpenEmbedded). Later on, we > > expect to see the OpenEZX family of devices, > > the Openmoko devices, the Nokia N900, and possibly also a bunch of HTC > > smartphones supported. > > Thank you for the announcement, it sounds nice. This bit made me wonder, > though: why must each different platform require a separate effort? Is > there something in FSO which works differently on different kinds of > phones? Yes, unfortunately... but that's due to the nature of being a middleware. Middleware is an abstraction layer on top of the hardware which shields the applications from the underlying differences. That means while FSO provides always the same interface to the applications, the hard and daunting task is to cope with the device specifics and make them "disappear". FSO has to deal with varying kernel-level interfaces, such as to audio routing, GSM modem, accelerometers, LEDs, buttons, peripheral control... to name just a few. Although we have seen a welcome level of standardization via kernel class devices in the past years, there are still too many home-grown vendor solutions and interfaces developed out of the kernel tree. All those we (FSO) have to adapt to provide a unified experience to the application level. Cheers, -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] amd64 compilation trouble
On 05/16/2011 15:43, giacomo 'giotti' mariani wrote: Hi Ed Hi Giacomo, There might be something wrong with the libraries, can you check with: ldd /opt/toolchains/arm920t-eabi/bin/arm-linux-gnueabi-gcc-4.3 Kind regards, Ed here the output of ldd follows: jack@nb2-mariani:~$ ldd /opt/toolchains/arm920t-eabi/bin/arm-linux-gnueabi-gcc-4.3 linux-gate.so.1 => (0xf77bb000) libc.so.6 => /lib32/libc.so.6 (0xf763f000) /lib/ld-linux.so.2 (0xf77bc000) It looks good to me, but I'm not a guru at all. Thank you very much Giacomo Hello everyone, I don't know how, but after upgrading to 11.04 the problem disappeared. Regards Giacomo -- ## giacomo 'giotti' mariani gpg --keyserver pool.sks-keyservers.net --recv-key 0x99bfa859 O< ASCII ribbon campaign: stop HTML mail www.asciiribbon.org ## ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community