UI ideas/questions or can we animate things as smooth as iPhone?

[Bradley Hook]

You *could* do what many existing linux apps do... write the functional
part of the app as a console program, and then use many simple GUIs as
options to interface with it. Think about cdrecord and K3b as an example.
For the handful of us out there that intend to use the Neo as a remote
administration device, being able to boot the thing into a GUI-less
console mode (using bluetooth HID for input) would be a "killer app" as
far as I can see. I use a full blown GUI desktop for most of my
day-to-day stuff (KDE), but when I really want to get a bunch of
remote-admin or compiling done, I just boot into run level 3, since I'd
be in a terminal window anyway. Why waste the CPU cycles, especially on
such a constricted CPU.
If someone really wanted to keep things lightweight, you could even do a
curses based interface as an option. 31337 HaXoRs and their console
based phones.

~Bradley

Florent THIERY wrote:
> I would say, considering the fact that the apps ecosystem hasn't
> "flourished" yet, is it really too late to switch? In the rest of this
> mail, please assume it is not.
> 
>> How detached is the underlying processes/functions and GUI from each
> other? How difficult will it be to just pull a different GUI layer on
> top of
> the phone functions?
> 
> The openmoko team can choose among technos that separate the two layers.
> 
> If you choose to develop (local) web applications for instance, then
> only the backend of the web rendering engine is the criteria.
> Switching from gdk to qt libs (which have had lots of
> embedded-oriented optimizations) will require only changing the
> rendering engine (webkit-gdk or webkit-qt), the backend isn't a
> concern.
> 
> Yet, for "traditional" applications... If you choose to develop your
> applications using a general purpose scripting language
> (python/ruby/whatever), using GUI bindings that support multiple
> backends (such as [1] [2] ) could let time for the final decision...
> 
> The clutter toolkit seems more and more interesting, because it supports:
> * GTK+ embedding
> * Language bindings for Perl and Python
> * Provides a fixed-point API [4]
> 
> But it would also mean:
> * no apps before P2 model
> * no clutter-based openmoko devices on non-OpenGL-capable devices
> 
> [1] http://wiki.python.org/moin/AnyGui
> [2] http://wiki.python.org/moin/Ocean
> [3] http://cairographics.org/backends/
> [4]http://www.clutter-project.org/docs/clutter-clutter-fixed.html
> 
> Any thoughts?
> 
> Florent
> 
> _______________________________________________
> OpenMoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
> 
>