Andre Brightway wrote in message
<88************ **************@ posting.google. com>...
I need a script to draw a keyboard to the screen and animate the
marking each key when the key is pressed (among other things like
being able to draw menus). This script is for testing keyboards and
needs to be run by people who may never have touched a computer before
so it needs to have an easy to follow GUI interface. But the Linux
boxes these will be runned on are very low-end, 'diskless' terminals
where running a full X-Windows system would be very slow. Does anybody
know of a GUI toolkit (or a way to draw to the screen) that can be
used from Python script in Linux without having to run X-Windows?
You may want to try PicoGUI (least mature), nano-x, or qt/embedded. They
all seem to claim Python bindings, although I'm only absolutely sure about
the first. PicoGUI is also network transparent; don't know about the other
two.
There's also pygame, which draws to a framebuffer using SDL, but I don't
know that it provides any gui-toolkit-like abstraction layer (also I think
SDL is a bit heavy). You could also use ncurses (in standard library) for a
character-based gui, instead. If things are really tight, I don't see that
there's any other way.
However, I'm suspicious of your statement that running a full X-Windows
system would be very slow. (Well, maybe a *full* system, but I assume you
just mean the server, not the 500+ MB of X stuff that usually gets installed
along with it.) If it's too slow for X, it's too slow for just about any
GUI, and it's certainly too slow for running Python locally *plus* all the
other not-X gui stuff you'd need to run because you gave up on being network
transparent.
All you need on the client side is the X server, and all the X server does
is *draw*. This doesn't take very much. The bloat usually associated (I
think falsely) with X is X clients and their libraries, and a diskless
terminal doesn't need to host any of that stuff. I've personally run setups
like this with 16mb 486s, and it was still perfectly usable, and in the past
X servers were run on custom hardware much less powerful even than that.
There are projects like ltsp.org and pxes (a bit heaver) which can make
diskless X terminal setups painless to put together.
If your terminals are in a very narrow grey zone where X is still too big
(because of ram starvation, perhaps) but running a gui is just about
possible, you might want to look at vnc, which is even *simpler* than an X
server: it's a remote framebuffer. At least one variant uses DirectFB for
display: directvnc. A terminal runs a vnc client, which connects to your
server, which starts an X server for that client, then echos the (virtual)
display to the vnc client. Now your server is running several copies of X,
you're passing through another abstraction layer, and your latencies are
higher, so it may end up *feeling* slower than just running X on the
terminals in the first place. I'd only use this approach if running X were
absolutely impossible.
--
Francis Avila
