SHR First steps

Kevin Dean kevin at
Sun Jul 6 15:56:50 CEST 2008

On Sun, Jul 6, 2008 at 12:06 AM, Bobby Martin <bobbymartin2 at> wrote:

> 3)
> 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.

Just tossing things out here, but I've got to disagree. Now, like
Bobby, I'm very likely wrong here so please feel free to correct me
where needed, but at this point doesn't Illume (I'm assuming that the
slider/grid thing is actually Illume) actually require a behind the
scenes E17 desktop? Is there substantial gain for making this choice
in the beginning?

What is it that this launcher needs to do? I know Bobby personally
dislikes the GTK2007.02's scrolling list (as do I) but what do others
think on that? Would porting a "fully featured" launcher (like
Qtopia's) be "easier" than making a framework oriented one (like
Tichy) fully-featured?

> 4)
> 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...
> 5)
> 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
> dependencies?

Raster's keyboard is good and bad. I've used it for tapping out basis
SMS messages and it's a LOT like the one Qtopia calls 'Predictive'
(And yes, I'm aware of the differences ;) ). It has the additional
benefits of being re-mappable for different languages. That said, I'm
not sure if it's a standalone applet or an E module and that answer
would sway my personal opinion of "Is this chain of dependancies worth
including for the benefits of the keyboard".

I personally liked the Matchbox keyboard, but I recall it was removed
because of a bug pertaining to repeating ENTER being sent. I have to
wonder though, if this was a keyboard issue or an app side issue. I'm
pretty sure Maemo uses Matchbox without this issue.

As long as it's terminal capable, I'll use whatever though. :)

> 6)
> 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 :-)

Just tossing that out there, but if the goal is to blend the ASU,
shouldn't we drop the GTK 2007.02 stuff entirely and port the Qtopia
apps to the framework instead? I think it would be HARDER because of
the interlocking parts of Qtopia but I think it would help achieve the
goals you just stated. If the goal is to merge the framework and the
ASU, then that really should be worked on as it will benefit this
release AND the ASU quite a bit.

When I first heard of the ASU, my assumption was that the ASU was a
frontend project and the framework was the backend that would
eventually be one more advanced release. Learning that was not the
case, honestly, has me kind of jaded from the ASU. If it's going to
simply be a few goodies on top of Qtopia then I don't think it's
particulalry appealing long term. It seems to me that resurrecting and
porting the GTK stack is at odds with improving the ASU. I'm fine with
whatever happens, but I think that perhaps a bit more understanding of
the aim of the SHR's objectives would help in making technical
decisions. Do we push features over stability or, like the framework,
impliment fewer features but make them damn solid?

> Thanks for any feedback!
> Bobby
> --
> If it doesn't make you smile, you're doing something wrong.

More information about the openmoko-devel mailing list