RE: [iPAQ] Browsers and Mail Clients

>
> I would vote for Gtk+/Gnome in this position (Caveat: I work for Helix
> ;-), mainly because it's done in C, and thus can be easily interfaced to
> other languages -- I think it's very possible that people start writing
> apps in, say, python. Using C++ as the framework would limit us, and it
> would also cause all sorts of development headaches (getting a working
> g++, getting all the standard C++ libs built [extra bloat], etc.).

I agree with all of this. Is it feasible to rewrite the GTK draw routines
for a flat look, and invert any menu bars to anchor to the bottom? I would
think this could be done as a GTK theme(GTK advertises the ability to
override draw functions in themes). That would keep us from having to
rewrite anything. We could even get evolution running ;) (Do you work on
that project?)

>
> I personally like most of WinCE's interface elements -- I think the
> single menu bar at the top of the screen and a status bar at the bottom
> is just about right for this type of device. I agree that we need some
> sort of pseudo-WM (afaik, the panel doesn't do this -- it's the WM that
> manages the desktops, the panel just displays the applets to let you
> switch 'em.)
>

Here is my vision: gnome-panel on top, foot on the left(not 3d), clock on
the right, small icons in the middle to switch tasks (I don’t know why all
of that space is waisted between “start” and the clock on WinCE). If we can
really do the above GTK theme, then our WM could just force windows to fill
the rest of the space below the gnome-panel. What do we do about non-GTK
applications...In this environment, conformity is almost necessity.

> Another question that I was pondering is how to deal with xscribble --
> it would be nice if one of the buttons could be a scribble toggle, and
> then you could scribble anywhere on the screen instead of just in the
> xscribble window. This would save a lot of screen real estate, and make
> the machine more useful overall.
>

If we are going to take the time to write a mini-WM, we could take the time
to incorporate xscribble into that. As focus moves around, depending on the
event mask, “do the right thing” (as Jim Gettys said). The program he
speaks of could be our mini-WM.

Another alternative to the input problem, is to write X4.0 input drivers.
Instead of having a toggle button, the touchscreen driver could be “taught”
the difference between a stroke and a tap. Then the XInput driver for a
keyboard could register with the device driver to only get strokes. The
XInput mouse driver could only get taps (The drag could get tricky, but I
think its doable...)

Hmm...Maybe the button to toggle is better, or join the two, if the button
is toggled one way, data goes to keyboard-alike device, if the other, the
mouse-alike device. Yes, I like that ;) I think the “record” button on the
side is well suited for this function, maybe hold it down to mouse, release
to scribble, whatever window has focus, gets the input. Holding it down
eliminates guesswork, or the need for feedback as to which mode you are in.

Food for thought,
Chris
Received on Wed Sep 20 14:14:12 2000