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 > [email protected] > http://lists.openmoko.org/mailman/listinfo/community > > _______________________________________________ OpenMoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
