Roman
pygame, of course
it runs nicely on framebuffer, and seems to be ideal for the task
you describe
--
-----------------------------------------------------------
| Radovan Garabík http://melkor.dnp.fmph.uniba.sk/~garabik/ |
| __..--^^^--..__ garabik @ kassiopeia.juls.savba.sk |
-----------------------------------------------------------
Antivirus alert: file .signature infected by signature virus.
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
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
If SDL has good enough support for framebuffers, you might be able to
use Pygame to do what you want. See http://www.pygame.org and
http://www.libsdl.org for details.
Paul
PyQt binds against Qt/Embedded which runs directly on the framebuffer.
We're using this on PDAs and WebPads.