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....0380057?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.

--
Grant Edwards grante Yow! .. I
at feel... JUGULAR...
visi.com

[David Bolen]

Grant Edwards <gr****@visi.co mwrites:

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]

David Bolen <db******@gmail .comwrites:

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]

On 2007-11-03, David Bolen <db******@gmail .comwrote:

Grant Edwards <gr****@visi.co mwrites:

>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.

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.

--
Grant

[Bjoern Schliessmann]

Grant Edwards wrote:

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 "sluggishne ss" comes from wxWidgets. PyQt and
PySDL are AFAIK not much "less weight".

Regards,
Björn

--
BOFH excuse #245:

The Borg tried to assimilate your system. Resistance is futile.

[Grant Edwards]

On 2007-11-04, Bjoern Schliessmann <us************ **************@ spamgourmet.com wrote:

Grant Edwards wrote:

>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++

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 "sluggishne ss" 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]

Grant Edwards <gr****@visi.co mwrites:

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]

Grant Edwards wrote:

On 2007-11-04, Bjoern Schliessmann

>Erm, wxWidgets is implemented in C++

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).

>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.

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

Regards,
Björn

--
BOFH excuse #295:

The Token fell out of the ring. Call us when you find it.

[Grant Edwards]

On 2007-11-04, Paul Rubin <httpwrote:

Grant Edwards <gr****@visi.co mwrites:

>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.

I do require graphics.

--
Grant Edwards grante Yow! Join the PLUMBER'S
at UNION!!
visi.com

[Grant Edwards]

On 2007-11-04, Bjoern Schliessmann <us************ **************@ spamgourmet.com wrote:

>>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.

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.

--
Grant Edwards grante Yow! Did you find a
at DIGITAL WATCH in YOUR box
visi.com of VELVEETA??