Low-overhead GUI toolkit for Linux w/o X11?

[Grant Edwards]

I'm looking for GUI toolkits that work with directly with the
Linux frambuffer (no X11). It's an embedded device with
limited resources, and getting X out of the picture would be a
big plus.

The toolkit needs to be free and open-source.

So far, I've found two options that will work without X11:

1) QTopia (nee QT/Embedded). I assume that I can probably get
PyQT to work with the embedded version of QT?

2) PySDL or PyGame. I'm not really sure what the differences
are between those two. The latter seems to be a little
more active. Are there any traditional GUI "widgets"
available for these two?

I've heard good things about PyFLTK, but it appears to depend
on X11 on the Linux platform.

Google found me this thread from a few years ago:

http://groups.google.com/group/comp...read/f173b27cb6ac84ce/da101ac750380057?lnk=st

Which mentions the same two choices and confirms that PyQt at
worked at one time with Qt/E (which would lead one to believe
it could be made to work with QTopia).

That thread also mentions Pico-GUI and Nano-X. Has anybody had
any experience using those with Python? Both of those seem to
have stalled. Neither has released anything since 2003.

 

[David Bolen]

I'm looking for GUI toolkits that work with directly with the
Linux frambuffer (no X11). It's an embedded device with
limited resources, and getting X out of the picture would be a
big plus.

Sounds like a reasonably modern "embedded" system since traditionally
neither X (nor Python) would likely have even been plausible in such
environments. Depending on the higher level GUI functionality you
require and how tight the resources really are, you might want to
consider investigating pure drawing libraries and then implement any
missing GUI elements (widgets and mouse handling) you need yourself.

When I was looking for an embedded graphics library for a prior
platform (ELAN 486, 2MB flash, 6MB RAM) under DOS, we took a look at
these:

* GRX (http://grx.gnu.de/index.html)
* Allegro (http://alleg.sourceforge.net/)

We ended up using GRX, primarily because it was the simplest to
develop a custom video driver for to match our platform, along with
having a simpler core. We were under DOS but also used it with a
later generation of the platform under Linux. Both libraries support
operation over the framebuffer in Linux. Our app was in C++ (Python
wasn't an option), and we implemented our own buttons and text
widgets (in our case we never needed any scrolling widgets).

There aren't any Python wrappers for GRX, but the library is straight
C which should be easy to wrap (manually or with something like SWIG).
No built-in widget support at all (some sample button processing code
in a demo module), but easy enough to implement your own if your needs
are modest.

Although we didn't end up using it, Allegro is more fully featured
(actually with some non-GUI cruft too since it targets games), and
also appears to have two work-in-progress Python bindings. Some basic
widget support in dialog processing routines.

-- David

 

[David Bolen]

When I was looking for an embedded graphics library for a prior
platform (ELAN 486, 2MB flash, 6MB RAM) under DOS, we took a look at
these:

* GRX (http://grx.gnu.de/index.html) (...)
There aren't any Python wrappers for GRX, but the library is straight
C which should be easy to wrap (manually or with something like SWIG).
No built-in widget support at all (some sample button processing code
in a demo module), but easy enough to implement your own if your needs
are modest.

I had forgotten, since we didn't use it, but there is an external mGui
library (http://web.tiscalinet.it/morello/MGui/index.html) that can
layer on top of GRX to provide higher level functionality. Of course,
it would also have to be wrapped for use from Python.

-- David

 

[Grant Edwards]

Sounds like a reasonably modern "embedded" system since traditionally
neither X (nor Python) would likely have even been plausible in such
environments.

Yes, it's "modern" enough to run Linux/X11 -- horsepower-wise
it's sort of in the PDA class of devices. wxWidgets has been
tried, but it's pretty sluggish. Hence the search for something
a littler lighter weight. Using Python is probably going to be
a little bit of a stretch, but using open-source libraries and
something like Python for the application langauge seems to be
an important part of the business model.

Depending on the higher level GUI functionality you require

That's still a bit up in the air. Routines to render text
would be nice, as would sprite graphics. I don't think text
entry or much in the way of windowing is required.

and how tight the resources really are, you might want to
consider investigating pure drawing libraries and then
implement any missing GUI elements (widgets and mouse
handling) you need yourself.

There is no mouse. I'm not sure how many "widgets" are
required. Probably not very many.

When I was looking for an embedded graphics library for a prior
platform (ELAN 486, 2MB flash, 6MB RAM) under DOS, we took a look at
these:

* GRX (http://grx.gnu.de/index.html)
* Allegro (http://alleg.sourceforge.net/)

We ended up using GRX, primarily because it was the simplest
to develop a custom video driver for to match our platform,
along with having a simpler core. We were under DOS but also
used it with a later generation of the platform under Linux.
Both libraries support operation over the framebuffer in
Linux. Our app was in C++ (Python wasn't an option), and we
implemented our own buttons and text widgets (in our case we
never needed any scrolling widgets).

There aren't any Python wrappers for GRX, but the library is
straight C which should be easy to wrap (manually or with
something like SWIG). No built-in widget support at all (some
sample button processing code in a demo module), but easy
enough to implement your own if your needs are modest.

Although we didn't end up using it, Allegro is more fully
featured (actually with some non-GUI cruft too since it
targets games), and also appears to have two work-in-progress
Python bindings. Some basic widget support in dialog
processing routines.

Thanks for the pointers.

 

[Bjoern Schliessmann]

Yes, it's "modern" enough to run Linux/X11 -- horsepower-wise
it's sort of in the PDA class of devices. wxWidgets has been
tried, but it's pretty sluggish. Hence the search for something
a littler lighter weight.

Erm, wxWidgets is implemented in C++ and wxPython is just a wrapper.
I don't think the "sluggishness" comes from wxWidgets. PyQt and
PySDL are AFAIK not much "less weight".

Regards,


Björn

 

[Grant Edwards]

Erm, wxWidgets is implemented in C++

Are you saying C++ software can't be large and slow?

and wxPython is just a wrapper.

Yes, I know. If we though Python was the problem, I wouldn't
be asking about other toolkits that had Python bindings.

I don't think the "sluggishness" comes from wxWidgets.

wxWidgets and GTK+ are both pretty large, and X11 is huge.

PyQt and PySDL are AFAIK not much "less weight".

They don't use X11. That's a _lot_ "less weight".

--

 

[Paul Rubin]

There is no mouse. I'm not sure how many "widgets" are
required. Probably not very many.

Back in the old days there were some lightweight toolkits for doing
text mode GUI's using ANSI graphic characters for MS-DOS. I did a few
of them. You could do quite usable and attractive gui's that way, as
long as you didn't require too much bling.

 

[Bjoern Schliessmann]

On 2007-11-04, Bjoern Schliessmann

Are you saying C++ software can't be large and slow?

No, but wxWidgets is quite mature and my experience is that it's
faster than Qt (partly, I think, because it always uses the native
widgets).

Yes, I know. If we though Python was the problem, I wouldn't
be asking about other toolkits that had Python bindings.

Ah, you know more than you wrote? If you've done measurements, I'd
find them quite interesting to see.

Regards,


Björn

 

[Grant Edwards]

Back in the old days there were some lightweight toolkits for
doing text mode GUI's using ANSI graphic characters for
MS-DOS. I did a few of them. You could do quite usable and
attractive gui's that way, as long as you didn't require too
much bling.

I do require graphics.

 

[Grant Edwards]

Ah, you know more than you wrote? If you've done measurements,
I'd find them quite interesting to see.

We know that wxWidgets is slow. That's why we're looking for
alternatives.

 

[Nick Craig-Wood]

I'm looking for GUI toolkits that work with directly with the
Linux frambuffer (no X11). It's an embedded device with
limited resources, and getting X out of the picture would be a
big plus.

The toolkit needs to be free and open-source.

So far, I've found two options that will work without X11:

1) QTopia (nee QT/Embedded). I assume that I can probably get
PyQT to work with the embedded version of QT?

2) PySDL or PyGame.

We did a similar project recently. We ended up using pygame and
writing our own GUI. For an embedded device you don't really want a
general purpose GUI which needs a mouse, you want something specific
which knows how many buttons the device has, what resolution the
screen is etc. It is not too difficult to make your own GUI in pygame
to do exactly what you want for your embedded device.

I'm not really sure what the differences are between those two. The
latter seems to be a little more active.

Pygame is the way I've always done SDL stuff in python - never even
heard of PySDL!

 

[Grant Edwards]

We did a similar project recently. We ended up using pygame
and writing our own GUI. For an embedded device you don't
really want a general purpose GUI which needs a mouse, you
want something specific which knows how many buttons the
device has, what resolution the screen is etc. It is not too
difficult to make your own GUI in pygame to do exactly what
you want for your embedded device.

Thanks for the pointer. I'm starting to like pygame for this
project. One of the application features needs to support some
simple animated graphics, and pygame's sprite support looks
like it might be a decent fit. I've been looking at the
different libraries listed on the pygame web site, and it looks
like there might be several that could make good starting GUI
points.

Pygame is the way I've always done SDL stuff in python - never
even heard of PySDL!

PySDL doesn't seem to be nearly as active or high-profile as
pygame.

 

[Chris Mellon]

Yes, it's "modern" enough to run Linux/X11 -- horsepower-wise
it's sort of in the PDA class of devices. wxWidgets has been
tried, but it's pretty sluggish. Hence the search for something
a littler lighter weight. Using Python is probably going to be
a little bit of a stretch, but using open-source libraries and
something like Python for the application langauge seems to be
an important part of the business model.

There's a DFB port of wx, although I'm not sure how much attention
it's received lately. I know it's been actually used for at least one
application. Gtk can also run directly on a framebuffer - that's what
openmoko does, for example.

That's still a bit up in the air. Routines to render text
would be nice, as would sprite graphics. I don't think text
entry or much in the way of windowing is required.

Sounds like a full scale widget toolkit is quite a bit heavier than
you need, though.

 

[Grant Edwards]

There's a DFB port of wx,

One where wx draws it's own widgets? I hadn't found that. I'll
have to take a look at that as well.

although I'm not sure how much attention it's received lately.
I know it's been actually used for at least one application.
Gtk can also run directly on a framebuffer - that's what
openmoko does, for example.

Yup, I just found the GtkFB project yesterday. That might be
an option as well. Persumably one could run wxWidgets on top
of that -- I'm not sure if the sluggishness of the wxWidgets
based stuff was due to wx/gtk or X11 (or a combination of
both).

Sounds like a full scale widget toolkit is quite a bit heavier
than you need, though.

Probably. The only UI input device is a set a half-dozen hard
buttons next to the display, so a lot of the mouse/keyboard
dependant features in GUI toolkits won't be of any benefit.

 

[Damjan]

PyQt and PySDL are AFAIK not much "less weight".

They don't use X11. That's a _lot_ "less weight".

Do you mean the X11 server or the libraries? The kdrive server should be
fairly small (depending on features). I think it builds from the main xorg
source today?? Isn't that what maemo uses.

I don't know about the X11 libraries, but the xcb libraries are pretty much
small too (126kb on i386 here) - there are additional libraries depending
on which features you want: render, shape, screensaver, shm, randr, dri
etc.. Shame the toolkits still don't use it directly.

 

[Grant Edwards]

Do you mean the X11 server or the libraries?

Both.