Re: Re: OFOQ- TO DO -TASK LIST !!

Mike Rowehl <[email protected]> Mon, 21 Jul 2003 15:06:28 -0700
Newsgroups gmane.org.handasarabia.ofoq
Message-ID <[email protected]>
On  0, Mohamed Eldesoky <[email protected]> wrote:
> On Monday 21 July 2003 20:31, Mike Rowehl <[email protected]> wrote:
> 
> > > What kind of trouble ??
> > > I managed to open the pdf file here normally.
> > > I used xpdf (Linux RH)
> >
> > I tried the same, but it's an older version of xpdf (screenshot up at
> > http://www.unrooted.net/screen.jpeg, the text is completely garbled).  I'll
> > give it another try on another system with a newer xpdf.
> >
> >                                                             Mike
> 
> ohhh, yes
> Sorry, I forgot, it wasn't xpdf, it was gv
> I use KDE, thus it was Kghostview.
> Tried it with xpdf, and it showed the same garbage.

Ahh, yes, gv works perfectly.  I see we're planning to use a HD44780, I've 
actually used one of these before.  It was attached to an ARM720 processor
(LinkUp 7210) using GPIO lines.  We didn't use it for interactive input though.
I has assumed that for the handheld we would be using a pixel mapped display,
mistake on my part.

Controlling a character mapped LCD like this is in itself pretty simple, 
meaning just writing out messages by cating them to the kernel lcd device.
However, getting it to act as a standard Unix terminal involves something more
than that.  To take an example, normally the input and output devices are bound
together in a tty configuration.  If the user presses a key on the keyboard the
character is echoed to the display.  This is not done by the program running on
the terminal, but normally by the terminal device layer within the kernel.  
I've actually never tried to code a set of terminal devices so that they act 
like this.  I think it's what we would want to do if we would like to be able
to just spawn a shell such as bash on the lcd/keyboard interface and type in
commands.

The other option is to stick with our own custom apps tailored for the small 
screen for now.  Say maybe a few apps along the lines of what the Z88 had 
available (http://www.zxplus3e.plus.com/z88forever/).  I would have to think a
little bit about which of these would make more sense from the software end.
My initial knee-jerk reaction is that writing a display handler with a number
of hotkeys that work with any application, and to write the applications as
small plugins to the overall display manager framework would work best if we
think that people are going to use this version 1 hardware for real user tasks.

So that's my question.  Is this version 1 hardware a temporary prototype which
we're going to use to make sure that we can make a functional unit?  Or do we
see people using a system like this to do real PDA type tasks?  Making a full
Linux I/O device out of the character LCD and keyboard combo would be a good
technical hack, and help out with further development somewhat (probably).  But
making a custom app to handle the keyboard and LCD and presenting functionality
through that interface would probably lead to a better overall user experience.

> 
> I like your WM, what is it ??
> 
The WM is blackbox, with a configuration that I've trimmed down quite a bit so 
that it consumes very little memory and runs fast.  fluxbox acheives the same
look at feel, it's what I use at home.  Both are excellent minimal window
managers.  I use bbkeys with both (it works with fluxbox no problem) to do 
hotkey binding for switching workspaces and bringing up new apps.

                                                                Mike

-------------------------------
OFOQ Mailing List
Handasa Arabia Organization
http://www.handasarabia.org
50