RE: [iPAQ] Browsers and Mail Clients

Actually....I think we should connect the record button to a sound recorder at some point. I didn't find that feature really that wonderful under CE, but it was impressive and I think others like it.

> -----Original Message-----
> From: Chris McFarlen [mailto:chrismc@fastlane.net]
> Sent: Wednesday, September 20, 2000 5:17 PM
> To: Vladimir Vukicevic; Chris McFarlen
> Cc: ipaq@handhelds.org
> Subject: 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
>
> _______________________________________________
> iPAQ mailing list
> iPAQ@handhelds.org
> http://handhelds.org/mailman/listinfo/ipaq
>
Received on Wed Sep 20 16:00:28 2000