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!


Openmoko community mailing list

Reply via email to