Questions and Answers

Carsten Haitzler (The Rasterman) raster at rasterman.com
Tue Jan 6 16:36:35 CET 2009


On Sat, 03 Jan 2009 02:13:45 +0100 "Marco Trevisan (Treviño)" <mail at 3v1n0.net>
babbled:

> > Let me give everyone a bit more background into the keypad issue. We
> > first saw the Qtopia predictive keypad back in February of 2008, and
> > became extremely exited. This keypad, we believed, had the potential to
> > become better than anything on the market.
> 
> Yes, it was...
> 
> > We asked Raster to integrate this keypad into Om 2008 and extend it to
> > make it more hacker friendly (i.e., usable from places like the
> > terminal). After two months of more or less silence he showed us his own
> > version, written from scratch. The design was a work in progress. And 
> > the dictionary was far inferior to what Qtopia had already. An internal 
> > battle started that lasted until one month before Om 2008 was set to be 
> > released when our product manager, Will Lai, couldn't take it anymore. 
> > He asked another engineer to just get the Qtopia keypad working.
> 
> Ok, I understand this. But, why have you asked Raster to improve a thing
> (like qtopia-x11) that should have been only a kind of placeholder?
> Wasn't it considered in a such way at that time? I always thought that
> the future of Openmoko was going to reach the Framework, and also if
> qtopia could be adapted to use it, we all know that its performances
> under X aren't the ones that we can bear.
> 
> > At that point Raster's keypad was getting stable. It had many new
> > features. But basic text entry was still not as good as Qtopia's. Major
> > parts of Om 2008, in the meantime, were still not finished (like the
> > Glamo or network manager).
> > 
> > Openmoko (the company) needs to focus on simplifying. We need to limit
> > ourselves to building what doesn't already exist. We cannot constantly
> > try to build better components from scratch. Our resources are just too
> > limited for that. Openmoko is trying to repackage the essentials (just
> > enough) to make people feel inspired. What's not there is often times
> > more inspiring than what is there.
> >
> > I emailed Raster, the other day, asking if my current perspective 
> > corresponds with his. The main motivation for writing a new keypad from 
> > scratch, he said, had to do with his ability to (easily) extend Qtopia's 
> > code. C++ and qt were not familiar to him. And he wanted something with 
> > more configuration options. To get there with Qtopia, he thought, would 
> > take more time then writing a new one from scratch.
> 
> So reading this I only think that what Raster said was not only true
> about the implementation difficulties, but also about the fact that at
> that time we needed something that should have survived to Om2008. The
> keyboard he wrote is actually what the future seems to reserve to us and
> also if it has some issues with accented words (maybe fixed in svn
> r38274?!?) and it performs worse with big dictionaries than the Qtopia
> predictive, I figure that he did the right move.
> 
> So maybe what happened wasn't in the spirit of the "backs to the
> basics", but he lead us the best input method available today.

since what i wrote really got distilled down and lost a lot of details and info
- i'll quote myself here on the keyboard issue:

----
"ok - here's my take:

looked at qtopia keyboard code. it's c++ and qt - not too familiar with qt but
readable. looked at code (very much qt/qws centric) and its all integrated into
the 1 big qpe process. it has no ability to change layout from config nor
anything to support using a terminal. we also will depend on a external app
that does phone handling for the most rudimentary of things. while it worked
well for english text input ONCe you learnt how to use it (someone told you the
tricks) it lacked: ease of discoverability (how do i enter space? how do i
type the return key? where are numbers? what happened to ctrl and alt? how do i
do backspace? etc.) there were a list of ui issues that i knew would be top of
the complaints list - they were already on the top of mine. now figuring the
work needed to add all of this and fix it vs. re-implementing - i chose to
re-implement given all the above concerns (it only took about 3 weeks for the
first cut - i was busy doing all sorts of other things at the same time, not
just keyboard).

so the work to fix it vs. the code to re-implement with all the other bits
"done better". i chose the latter as i saw it as a faster way to get to thew
right solution. in the end qtopia was meant to be a TEMPORARY solution until
FSO was done - and thus there would need to be a new keyboard implemented
anyway later so work would be duplicated probably by the same person - me. so
instead of doing it twice - did it once. there were enough other unsolved
problems at the time - like "how do i request a keyboard as an app properly?
(the matchbox protocol had holes you can drive a truck through to cause
problems so i ended up implementing that for compatibility, but also a newer
protocol involving properties). also how to select from one of N installed
keyboards and manage the running, killing of the old one etc. etc. were all
unaddressed problems - which would be (and were) significantly easier to
address using illume's keyboard. the problem space is a much more intricate and
complicated one than just "use the qtopia keyboard". that would be the view
when not accounting for all the other issues intertwined with the problem space.

to this date "how do i get rid of the qtopia keyboard and get the illume one"
is one of the most asked questions regarding the keyboard. along with "how do i
get the qwerty manual control" button. along with "hoe on earth does this thing
work? i can't put in a space or delete a word?" :)

so that's why i did a mimick that also put in all the other features i saw
were barriers to usage and learnability. indeed for a while qtopia's dictionary
was much better. illume's has caught up."
----

yes. you asked sean. and he answered and that's good. but there's details
missed.

n.b. no one asked me to make it more hacker friendly at all - in fact all i was
asked was to make the qtopia keyboard work as-is. no asking for hacker-friendly
features (ctrl, alt, terminal etc. etc.). focus was entirely on its ability to
do fuzzy dictionary correction and all its hidden swipes and text matching
selection. it was i that was worried about 'hacker-friendly' after the massive
negative feedback of the numberpad entry keyboard that had no "/" (well it did
but everyone kept asking where it is and complaining how its not usable for a
terminal) that replaced the old matchbox-qwerty keyboard in 2007.x - i paid
close attention to the community lists and what people were doing, what they
said etc. - i don't like to go make the same mistakes already made again.

as such in april holger agreed with my assessment that it was easier the way i
did it - wolfgang was told much earlier after i was asked to look at the qtopia
keyboard that it'd be easier for me to do the way i did. holger even said that
40% of the work was just be shared infra for handling virtual keyboards in
general (i would have said it was more) - be it the qtopia one or any other and
fixing protocols etc. also i was doing launcher, wm, general app switching,
helping with efl and some python binding issues, connman back end and also
front end testing tools for wifi, and more during the lead up to om2008.x
release

i also found that will (product manager) was weeks behind my source tree (which
was on projects.om.org and code went in as soon as it worked) so he was
complaining about things that were already fixed weeks before. i also heard the
complaints vicariously (2nd hand) - just mumbles but never anything specific
until much later when i asked for details a few times.

in the end om got what it wanted - the qtopia keyboard. users were given what om
wanted to give them - the qtopia keyboard working - as-is and that's it. "40%"
of my work was infra for that keyboard (and other possible ones - including
illume's own) to plug into. just the "other 60%" was never used. so as such they
were delivered just what om wanted to deliver and if the users dont like the
choice of the qtopia keyboard (with no other keyboards and layouts available),
that is what the "questions for sean" is for. so as such its not a
"controversy that led om to ship with the qtopia keyboard". that is EXACTLY
what om wanted in the first place the controversy is me disagreeing with it.

ask why om didn't think a keyboard that works for them with a terminal etc. was
considered important (sms/email/text etc. entry with dictionary correction was
considered of utmost importance). nothing to do with me. i always agreed the
idea inherent in the qtopia keyboard was nice and it was really cool - but it
had issues that needed fixing. om wanted the qtopia keyboard as it was - and
that's just what was shipped, and still is.

i was entirely unhappy with a basic thing like key entry depending on a big qpe
process that was temporarily there to be tossed out later. qpe was also the
dialler, sms and contact suite etc. keyboard entry just was out of place given
everything else it was doing was not related to basic "desktop ui".

anyway - i don't want to debate this. just it sounded like i sat on my hands
for 2 months ignoring everyone and arrogantly went off and just did my own
thing because i wanted to (since most of my answer was cut out). i made an
assessment - as asked. i responded with my results. i implemented accordingly
(and said i would), in a way that was able to accept alternatives.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com





More information about the community mailing list