First beta release of Aurora
Heyho, a little bit late but it's still august so who cares? The first release of the aurora project has finally arrived. It is still in beta state but ready to be flashed on your Palm Pre / Pre Plus / Pre 2 devices. The images for each device you find in [1]. Just download them and follow the guide in [2] to get it working on your device. A short overview about the the first release you get in [2] too. Whats is Aurora? The aim of Aurora is to replace zhone and zhone2 as development UIs for FSO. From the viewpoint of a middleware architect, it's essential to have clients available that use the various features of the FSO services. On the other hand though, this time we want to create something that is also suitable for day to day use. Aurora is supposed to be something we call a featurephone client – featurephones being those things we used for telephony before smartphones were invented. Aurora being a featurephone client does not necessarily mean it will never get the smartphone features Android or iOS are popular for, it rather describes our approach as being as-simple-as-possible. So for now you will not be able to install additional apps or features. Everything (you need) is part of the Aurora client. If you have any questions feel free to ask and we're happy about bug reports! regards, Simon [1]: http://amethyst.openembedded.net/~morphis/aurora/2011-08-beta1/ [2]: http://wiki.freesmartphone.org/index.php/Aurora/Version_0_1 -- Simon Busch - http://mm.gravedo.de/blog/ ___ 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: 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
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 morp...@gravedo.de 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: Aurora
On Monday 16 May 2011 23:22:03 Neil Jerram wrote: Some words about the technology choices we have made for Aurora. The UI components of Aurora will be based on Qt's QML (Qt Markup Language) and will have parts written in C++ and Vala (although we're going to use Python for prototyping as well). We will support both Qt/X11 and Qt/Embedded, the latter being useful on If you strongly favour Qt, you could take QtMoko as your reference set of applications. That would be especially helpful right now, as Radek is just looking at converting QtMoko to use FSO. QtMoko is just too complicated - i think the idea of reference feature phone is good and in the end we can even have Aurora packaged for QtMoko - e.g. for testing. I have been playing with FSO for week now. It's great api - easy to use. Writing feature phone is not that much work. I have my FSO test app that can register to network, make calls, blink with leds - check how simple it is [1]! I have spent just a few hours on it. Having many frontends for FSO is probably not that much problem. I'd not panic now ;-) Regards Radek [1] https://github.com/radekp/qtmoko/blob/master/src/libraries/qfso/test/mainwindow.cpp ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] Aurora
Dnia 2011-05-16, pon o godzinie 18:02 +0200, Michael 'Mickey' Lauer pisze: NOTE: Cross-posted to three mailing lists, please keep it that way, if you want to reply. Might be troublesome, as I am not subscribed to smartphones-userl...@linuxtogo.org but I'll try. [cut] non-maintainable Edje file. We have therefore decided to develop a new testing/demonstrator for FSO named Aurora that is supposed to be the driving force for further development. [cut] very good idea! This might also be a good starting point as a simple reference application for those who want to start developing for embedded devices. And I hope FreeRunners will be your next target platform :) -- Patryk LeadMan Benderz Linux Registered User #377521 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Aurora
Hi Corey, On Monday, May 16, 2011 09:02:58 AM Michael 'Mickey' Lauer wrote: NOTE: Cross-posted to three mailing lists, please keep it that way, if you want to reply. Aurora is supposed to be something we call a featurephone client – featurephones being those things we used for telephony before smartphones were invented. Could you please elaborate a bit further for those of us who are unsure of the specific functional differences between a featurephone and a smartphone? For sure. Featurephone vs. Smartphone is resembling the difference of, lets say, a Sony Ericsson K700, and an iPhone. On the K700, the whole OS is designed around the telephony. While it has additional features, it doesn't allow you to install native applications (well, yes, there are some Java applets, but these don't count as they are not at all integrated into the system and they can't access the phone databases nor talk to each other) – it sells because of the quality of the telephony. On the iPhone, the whole OS is designed around the idea of a mobile computer that allows you to perform a vast variety of tasks. You can install a myriad of apps and only a very minor percentage of these apps have anything to do with telephony. The telephony is a feature among many others. In fact, telephony is pretty lousy on an iPhone, but that's ok, because it is not the feature that sells this device. Bottom line: feature phone is less flexible, comes with everything preinstalled, and is designed around the telephony. Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] Aurora
On Tue, May 17, 2011 at 05:47:46PM +0200, Dr. Michael Lauer wrote: Hi Corey, On Monday, May 16, 2011 09:02:58 AM Michael 'Mickey' Lauer wrote: NOTE: Cross-posted to three mailing lists, please keep it that way, if you want to reply. Aurora is supposed to be something we call a featurephone client – featurephones being those things we used for telephony before smartphones were invented. Could you please elaborate a bit further for those of us who are unsure of the specific functional differences between a featurephone and a smartphone? For sure. Featurephone vs. Smartphone is resembling the difference of, lets say, a Sony Ericsson K700, and an iPhone. On the K700, the whole OS is designed around the telephony. While it has additional features, it doesn't allow you to install native applications (well, yes, there are some Java applets, but these don't count as they are not at all integrated into the system and they can't access the phone databases nor talk to each other) – it sells because of the quality of the telephony. On the iPhone, the whole OS is designed around the idea of a mobile computer that allows you to perform a vast variety of tasks. You can install a myriad of apps and only a very minor percentage of these apps have anything to do with telephony. The telephony is a feature among many others. In fact, telephony is pretty lousy on an iPhone, but that's ok, because it is not the feature that sells this device. Bottom line: feature phone is less flexible, comes with everything preinstalled, and is designed around the telephony. There is nice description of feature phone and smartphone in Chapter 2 http://gnumonks.org/~laforge/papers/gsm_phone-anatomy-latest.pdf but I guess this doesn't help much to imagine featurephone client :) -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com pgp2tA8FZVg4E.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] Aurora
Am 17.05.2011 um 18:06 schrieb Martin Jansa: Bottom line: feature phone is less flexible, comes with everything preinstalled, and is designed around the telephony. There is nice description of feature phone and smartphone in Chapter 2 http://gnumonks.org/~laforge/papers/gsm_phone-anatomy-latest.pdf but I guess this doesn't help much to imagine featurephone client :) Yeah, Harald focuses on the BP vs. AP/BP separation, which is a hardware- centric view – while I tried to capture the 'spirit' ;) Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Aurora
Thankyou for the clarification! On Tuesday, May 17, 2011 08:47:46 AM Dr. Michael Lauer wrote: Hi Corey, On Monday, May 16, 2011 09:02:58 AM Michael 'Mickey' Lauer wrote: NOTE: Cross-posted to three mailing lists, please keep it that way, if you want to reply. Aurora is supposed to be something we call a featurephone client – featurephones being those things we used for telephony before smartphones were invented. Could you please elaborate a bit further for those of us who are unsure of the specific functional differences between a featurephone and a smartphone? For sure. Featurephone vs. Smartphone is resembling the difference of, lets say, a Sony Ericsson K700, and an iPhone. On the K700, the whole OS is designed around the telephony. While it has additional features, it doesn't allow you to install native applications (well, yes, there are some Java applets, but these don't count as they are not at all integrated into the system and they can't access the phone databases nor talk to each other) – it sells because of the quality of the telephony. On the iPhone, the whole OS is designed around the idea of a mobile computer that allows you to perform a vast variety of tasks. You can install a myriad of apps and only a very minor percentage of these apps have anything to do with telephony. The telephony is a feature among many others. In fact, telephony is pretty lousy on an iPhone, but that's ok, because it is not the feature that sells this device. Bottom line: feature phone is less flexible, comes with everything preinstalled, and is designed around the telephony. Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Aurora
NOTE: Cross-posted to three mailing lists, please keep it that way, if you want to reply. Dear FOSS-Telephony lovers, today we want to announce something that has been brewing in our minds for quite a while and will change the way we develop the freesmartphone.org middleware. In the past, FSO has been too much developed without considering how the features will actually be used by the API consumers. Apart from the great work our friends from SHR did, there has only been a handful of special purpose FSO clients, such as the Emacs client, Zhone, and Zhone2. Zhone (and its successor Zhone2) is currently an oversimplified approach based on a non-maintainable Edje file. We have therefore decided to develop a new testing/demonstrator for FSO named Aurora that is supposed to be the driving force for further development. AURORA The aim of Aurora is to replace zhone and zhone2 as development UIs for FSO. From the viewpoint of a middleware architect, it's essential to have clients available that use the various features of the FSO services. On the other hand though, this time we want to create something that is also suitable for day to day use. Aurora is supposed to be something we call a featurephone client – featurephones being those things we used for telephony before smartphones were invented. Aurora being a featurephone client does not necessarily mean it will never get the smartphone features Android or iOS are popular for, it rather describes our approach as being as-simple-as-possible. So for now you will not be able to install additional apps or features. Everything (you need) is part of the Aurora client. DEVELOPMENT PROCESS At the top of every application stack is the user. Pleasing him or her is the topmost priority. Technology should not stand in the way, but rather support the user. Hence, Aurora releases will be done as user milestones. For every user milestone, we will pick a number of user stories to be implemented. We will then split a user story into tasks and distribute among the contributors. 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. TECHNOLOGY Some words about the technology choices we have made for Aurora. The UI components of Aurora will be based on Qt's QML (Qt Markup Language) and will have parts written in C++ and Vala (although we're going to use Python for prototyping as well). We will support both Qt/X11 and Qt/Embedded, the latter being useful on smaller systems, such as the OpenEZX family of devices (48MB RAM, no GFX acceleration, etc.) For the first release we will only provide Qt/Embedded based images for the Palm Pre devices; those flashable images will be based on OpenEmbedded, however we'd welcome people taking care of creating releases based on Debian, Gentoo, etc. THE CODE At the moment, there is not much to look at, but feel free to download the current status via git.freesmartphone.org - aurora. HOW TO HELP Speaking about welcoming people, the major aim of this announcement is to find people who want to share this vision and give us a bit of a hand. We are especially lacking artists and folks who can improve our user interaction. Apart from the technical reasons, we chose QML to have a very low barrier of entry. QML is easy to understand and it also comes with a GUI design tool. If you are interested and share our vision, please feel free to contact us. We can then see how you could help us to get to the end goal (see roadmap) even faster. There are two possibilities to make us aware of you: - IRC: irc.freenode.net; channel: #openmoko-cdevel - Mail: smartphones-userl...@linuxtogo.org Thanks for your attention, Mickey Morphis. -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Aurora
On Monday, May 16, 2011 09:02:58 AM Michael 'Mickey' Lauer wrote: NOTE: Cross-posted to three mailing lists, please keep it that way, if you want to reply. Aurora is supposed to be something we call a featurephone client – featurephones being those things we used for telephony before smartphones were invented. Could you please elaborate a bit further for those of us who are unsure of the specific functional differences between a featurephone and a smartphone? Thanks! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Aurora
On 16 May 2011 17:02, Michael 'Mickey' Lauer mic...@vanille-media.de wrote:
NOTE: Cross-posted to three mailing lists, please keep it that way, if
you want to reply.
If you can persuade them all to accept emails from non-subscribed
email addresses... (For weird historical reasons, I'm subscribed to
different lists with different addresses.)
In the past, FSO has been too much developed without considering how the
features will actually be used by the API consumers.
Apart from the great work our friends from SHR did, there has only been
a handful of special purpose FSO clients, such as
the Emacs client, Zhone, and Zhone2. Zhone (and its successor Zhone2) is
currently an oversimplified approach based on a
non-maintainable Edje file. We have therefore decided to develop a new
testing/demonstrator for FSO named Aurora that
is supposed to be the driving force for further development.
I'm afraid I don't understand. Why not just have SHR as your
reference set of applications? If you don't think they are using the
FSO APIs in the pattern that you would recommend, presumably you could
work with them to correct that? Or, if they are missing applications
or features to showcase some of the latest FSO API features,
presumably you could help them to add those?
At the top of every application stack is the user. Pleasing him or her
is the topmost priority.
Speaking as a user, I would be pleased not to see more unnecessary
fragmentation of front-end efforts; also for the FSO2 middleware to be
rock-solid, with things fixed like RequestResource('bluetooth')
starting bluetoothd.
To be fair, it may be that FSO2 already is rock-solid now. I haven't
reviewed the situation recently, but I can't immediately think of any
known and clear issues, about from the bluetoothd one. But in that
case I'd still prefer focus on the SHR front end, over some new UI.
Some words about the technology choices we have made for Aurora. The UI
components of Aurora will be based on Qt's QML
(Qt Markup Language) and will have parts written in C++ and Vala
(although we're going to use Python for prototyping as well).
We will support both Qt/X11 and Qt/Embedded, the latter being useful on
If you strongly favour Qt, you could take QtMoko as your reference set
of applications. That would be especially helpful right now, as Radek
is just looking at converting QtMoko to use FSO.
Speaking about welcoming people, the major aim of this announcement is
to find people who want to share this vision
and give us a bit of a hand. We are especially lacking artists and folks
who can improve our user interaction.
Apart from the technical reasons, we chose QML to have a very low
barrier of entry. QML is easy to understand
and it also comes with a GUI design tool.
If you are interested and share our vision, please feel free to contact
us. We can then see how you could help us to get to the end goal (see
roadmap) even faster.
I'm almost lost for words here. Starting from scratch seems so
obviously the wrong thing to do, when there are mature projects that
you could contribute to...
I must be misunderstanding what you mean - please do explain more!
Regards,
Neil
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Aurora
On 16.05.2011 23:22, Neil Jerram wrote:
I'm afraid I don't understand. Why not just have SHR as your
reference set of applications? If you don't think they are using the
FSO APIs in the pattern that you would recommend, presumably you could
work with them to correct that? Or, if they are missing applications
or features to showcase some of the latest FSO API features,
presumably you could help them to add those?
SHR is a great thing, but it's too complex to be the first showcase for
new features. The main problem we have is time and man-power. We are
currentl two people doing most of the FSO work. With two people it's
even hard to get only the basics done.
SHR is based on the traditional design pattern of a window mananger
which runs some application you can work with. The work to integrate new
features like network (wireless, gprs, bluetooth pan) in a usable we
needs a lot of work (you need a new E Gadget, you need a application to
choose the network, you to adjust shr-settings, ...) to do.
I worked for now 2 two to get SHR running on the Palm Pre and it's so
much work that I will never finish it on my own. You invest a lot of
time to debug things, see how things work and never get your work
finished in a reasonable time frame.
At the top of every application stack is the user. Pleasing him or her
is the topmost priority.
Speaking as a user, I would be pleased not to see more unnecessary
fragmentation of front-end efforts; also for the FSO2 middleware to be
rock-solid, with things fixed like RequestResource('bluetooth')
starting bluetoothd.
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.
To be fair, it may be that FSO2 already is rock-solid now. I haven't
reviewed the situation recently, but I can't immediately think of any
known and clear issues, about from the bluetoothd one. But in that
case I'd still prefer focus on the SHR front end, over some new UI.
As you may know we are working hand-in-hand with all the SHR developers
and we are loving SHR too. But at some point we need to concentrate us
on FSO and FSO as framework only to be successfull in the future and not
only on the Openmoko devices. There are a lot of devices out which are
suitable to be driven by FSO but needs time to be integrated into the
framework. If we do everytime to full work for SHR and FSO we will never
do anything else with this phones in their lifetime. If you work for a
long time very hard on such a project you want to see something working
and usable to have. But currently with doing the doubled work for SHR
and FSO does not let us come the this point.
If you strongly favour Qt, you could take QtMoko as your reference set
of applications. That would be especially helpful right now, as Radek
is just looking at converting QtMoko to use FSO.
With QtMoko it's the same as I said above. We need some simple stupid
thing we can change within an hour to support a new feature like network
management. We cannot archive this with QtMoko or SHR.
I'm almost lost for words here. Starting from scratch seems so
obviously the wrong thing to do, when there are mature projects that
you could contribute to...
We are not starting from scratch with a completely new platform. We are
just reordering the reponsibility of the FreeSmartphone team which is to
develop the middleware and concentrate of integrating new devices and
get new features like network management in.
I must be misunderstanding what you mean - please do explain more!
Don't thing about aurora as something big, it's a very simple thing for
simple needs. You will see all new features even in SHR, but not done by
the core FSO team.
regards,
morphis
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
