SHR First steps

Bobby Martin bobbymartin2 at
Sun Jul 6 06:06:47 CEST 2008

I'm just going to give my impressions here as if they're facts -
everyone feel free to correct me where I'm wrong :-)

The FSO is the build with the most stable calls and suspend/resume.
Those seem to be the real sticky bits of the suite (as well as some of
the most important for day-to-day use), so I think our first target
for SHR should be simply to reproduce a stable (and repeatable) build
of the FSO, but in an environment in which we can apply our future

To that end, I know Asheesh has created a git repository.  I think
mwester is probably the one best suited to tell us what repositories
we should be pulling from to generate our build products, and how to
get there.  If he can either outline for us what to do, or, better
yet, just get access to Asheesh's repository and do it, I think that's
how we should get started.

Once we can reproduce an FSO build, I think we need to figure out how
we're going to launch programs.  IMO it should be one of the existing
launchers - probably the one the ASU uses, but I'm open to suggestions
since I have yet to run ASU at all :-)  If it turns into a morass to
bring in the ASU launcher, and if another full-featured launcher is
easier to port, I think that's the way to go.

I think the 2007.2 suite of phone & PIM applications are the most
ready for day to day use right now, so I propose that we change those
apps to use ophoned as the backbone instead of phonekit/gsmd.  I
*think* they almost exclusively use the PhoneKit dbus interface to
access the gsm now, so I intend to write an adapter from PhoneKit to
ophoned and modify the dependencies so those apps that access the
phone depend on our new adapter.

At this point I think we have a baseline that will let us have a phone
that works and will last 1 day+ using suspend, and let us pull in lots
of individual applications that don't conflict with the things we
already have in the image.  There is IMO one biggish thing missing...

We need to figure out our keyboard solution.  I'm not sure how the
existing keyboards work... is raster's keyboard in the ASU ready to
go, and can we bring it in without needing a bunch of conflicting

Now we have the full basic suite, and we just try all the different
packages we can find and see if we need to write some adapter for
popular ones, and maybe produce a list of tested apps as well as those
that have been shown to have some problem.

We're still feeling this stuff out, so if I've gone way off track, or
missed the obvious (either obvious problems or obvious solutions),
please chime in.

I would love it if this could eventually just turn into a part of the
ASU, with people replacing the old 2007.2 apps (without breaking
them!) with alternatives that work better or look nicer as a part of
the ASU.  Our goal is *not* to create another competing release
(although I know that's essentially what we're doing right now).  Our
goal is to take the goodness of the future and the goodness of the
past and patch together something that gives us both until the future
can catch up on all counts with the past :-)

Thanks for any feedback!

If it doesn't make you smile, you're doing something wrong.

More information about the openmoko-devel mailing list