Which Distro?

[Carsten Haitzler (The Rasterman)]

On Sat, 19 Jul 2008 15:42:58 -0700 Ken Restivo <ken at restivo.org> babbled:

> 
> #hank you for the detailed and informative response! I didn't understand any
> #of the above (which was probably very obvious), and you made it very clear
> #to me now. It seems to be a sensible approach. May I paraphrase some of this
> #and turn it into a Wiki page? (Where exactly to put it would be another
> #interesting question).

sure. no problem. rememebr - all are openembedded based. there WILL be small
issues between them - more to do with "competing" packages. eg on one u have
one package that provides a "panel" with applets on another that same
functionality is done by another piece of software and thus a different
package. so if you want to "integrate" into "desktop environment" parts in
detail (eg replace today screen or wallpaper stuff etc.) it's the same as
desktop distros - you may have issues, but for regular applications it's all an
easy walk in the park. right now for phone and such access its a mess of
qtopi's qpe in ASU vs gsmd in 2007.2 vs FSO's dbus based access daemons. as
such ASU is "for now" and likely will merge with FSO'd back ends. i
know i hope to do a different UI than ASU currently has, myself - a major
improvement over it, at least he core "desktop", and i am hoping to merge with
FSO in that way. ie make full use of FSO's back-ends and integrate and provide
a sexy front-end. :) but again - all of the distros use X11 (except the pure
qtopia one) so all toolkits work and apps should "just work". ASU even support
the matchbox kbd activation protocol as well as a newer one i brewed up (thats
much more reliable as it uses a window property for keyboard requests). ASU has
a fully-fledged desktop WM in it (modified via modules/plugins to have
different behavior on such a small screen device), so there isn't much it can't
do (given a small amount of work).

> 
> > think of it as ubuntu vs xubuntu vs kubuntu etc. its the same os. just
> > different starting point.
> > 
> > > > same if we said qt/c++ only, or phython only, or java only. why should
> > > > you be boxed into a single box and a distro is only allowed to have 1
> > > > box? why? just because every other phone maker works this way does not
> > > > mean we have to.
> > > > 
> > > > > So perhaps I can clarify: what distro do you intend to ship with to
> > > > > end users?
> > > > > 
> > > > > If it is ASU, and I must wait, thats just fine with me, but your
> > > > > response above seems to contradict that.
> > > > 
> > > > ASU is what openmoko is working on.
> > > > 
> > > > > I'd appreciate your helping us out here since I'm probably not the
> > > > > only one confused ... what am I missing?
> > > > >
> > > 
> > > Then ASU is the one I will work on too. I'm glad to be running it now. It
> > > seems excellent. All I need is to get the matchbox keyboard to replace the
> > > quite awful and useless keyboard that comes with ASU, and I'm all set to
> > > really enjoy this thing.
> > 
> > the default keyboard is just as usable as the matchbox one. there is a full
> > qwerty layout file available for it. keyboard layout is just a config file.
> > unlike the matchbox keyboard it is also usable with a finger not just a
> > stylus.
> > 
> 
> Great! I didn't know that. Is this documented anywhere on the Wiki or should
> I start some page, i.e. Customizing_ASU_keyboard ?

nup. not documented... yet. i am actually in the middle of a keyboard rewrite
for ASU. the code is much much much cleaner now and well abstracted, and i have
a keyboard layout selector button/icon in addition to "swipe up". i'm also
including the full qwerty keyboard by default for now - it may get split into a
separate package later, but as such the full qwerty keyboard works just like
matchbox's qwerty "stylus" keyboard, but uses the exact same kbd engine as the
predictive one. it's just a layout file. i am going from the principle that
it's easier for people to write for themselves little keyboard layout files
than write whole virtual keyboard programs. i['d eventually hope that people
can write a small plethora of them covering different languages and uses (eg
one with all the umlauts or accents for french or for german or swedish,
russian etc. etc.), and thus people can select variants of keyboard layouts to
use that work best for them or their usage. no need for whole new keyboards.

the keyboard code though is now abstracted into container - that can accept any
vkbd written specially (eg the matchbox multi-tap and qwerty ones) or the
internal built-in one. the built-in will be much more resource friendly as you
save on excess resources for a new process and new set of init code etc. but it
is still limited. no handwriting recognition etc. maybe over time i can
abstract "gesture" recognition into scribbling etc. subsystems... dunno. either
way - you get to choose what you want. right now it always creates the internal
keyboard - i haven't added code to disable that (and select something else to
run), but its not static project, it's under development like a lot of other
things.

but again - it is a virtual keyboard for x11 - if you have an x11 app - it
will work. you can send messages to the root window (or new as of this week)
set properties on your window to hint that you want a keyboard... and what
kind. the vkbd system will handle the rest. i'll eventually get to writing docs
about it all, but as such - i'm had down, bum-up in code, so it'll have to be a
bit nebulous/mysterious for now, unless you like to read the src code! :)

-- 
Carsten Haitzler (The Rasterman) <raster at openmoko.org>