A GUI toolkit for Python that is NOT x-windows dependent
Andre Brightway
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?
Roman Yakovenko
May be this will help you. This module built-in in Python distribution.
Roman
Radovan Garabik
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!
Francis Avila
<88f9e356.03121...@posting.google.com>...
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
Paul Boddie
> 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?
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
Michael 'Mickey' Lauer
PyQt binds against Qt/Embedded which runs directly on the framebuffer.
We're using this on PDAs and WebPads.