Re: Q: Suitability of GTK+ for critical embedded application

[Michael Torrie <torriem chem byu edu>]

On Sat, 2005-12-03 at 17:38 +0100, Are Leistad wrote:
> If GTK+ gets adopted it will preferably run without X, but rather
> use a framebuffer, so or GTK+ on DirectFB is a possibility.
> It is noted that GTKfb is no longer maintained. The target platform
> is a x86 (ITX) with Suse Linux 2.6, but Windows is used for parts of
> the development cycle and the application must be able to run there.
> The application is demanding it that it will employ a high number
> of widgets. Several thousands of GUI objects will be created, and 
> several hundred of these may be exposed at any one time.
> Responsive interactivity and quick redrawing is important.

Actually I think you'll find that running GTK on an embedded X-server
works very well. In fact I think it's a much better idea than the
framebuffer, since GTKfb really has to implement GTK plus the stuff X
provides.  If you check out the kdrive X server from
www.freedesktop.org, I think you'll find it can be less than a mb in
binary size and run fine on just a few mb of RAM.  Not much larger with
GTK/X than GTKfb.  A tiny window manager, matchbox also works well for
an embedded system with a small screen.

When you say you are considering GTK for an embedded situation, I take
it you're not meaning real-time or microcontroller, but a small, full-
blown computer running a full protected-mode, virtual memory OS.  If
not, GTK simply can't work.  GTK must have dynamic memory allocation
available from the OS.

I'm found based on my experience with GTK and with many GTK apps that
the stable GTK libraries have no known memory leaks.  In fact the
underlying glib libraries are so well-written that I can in one of my
app (over the course of months) build and destroy millions of dynamic
tree stuctures containing glib objects (lists, strings, etc) and not one
leak.  It has been a while since a real memory leak has been discovered
in the gui stuff in GTK.  In fact most of the supposed leaks reported in
recent months were really just the programmer not quite understanding
how the reference counting and object destruction worked.

Michael



-- 
Michael Torrie <torriem chem byu edu>