Re: Porting GTK, requirements

[Owen Taylor <otaylor redhat com>]

"Joost Faassen" <listreader joost cx> writes:

> The relevant pieces of the picture are:
> 
> > - The operating system environment ... libraries etc.
> >   Porting GLib deals with differences here.
> The os env is not posix compliant at all, however a lot of basic
> functionality is in place such as memory management, filesystems, etc. Is
> there a central place where for example stubs need to be filled to hook
> into this ?

Try compiling GLib; either port or comment out the stuff that
doesn't compile. Move on from there. Find out what parts of
the stuff you commented out were really needed...
 
The big problem with getting GTK+ going on such a system is
probably not the requirements, but simply the amount of code
that you'll need to get compiling. Along with GLib/Atk/Pango/GTK+,
you'll need libiconv, gettext, and various image libraries.

> How dependant on scheduling / tasks etc is GTK ? Could it run in a
> monotasking system for example ? Does GTK create any tasks / processes on
> its own ? Does it require some form of IPC ?

GTK+ is completely single threaded and in a single process. It
requires no IPC. So, yes, you could run it on a monotasking
operating system.

Basically, all you need is some call a bit like select() that
can wait for events on your input devices or for a timeout.

DirectFB probably has bigger requirements in this area if you
decide to go that way.

> > - The font system in use (X11, FreeType, Win32, etc.)... This
> >  involves Pango.
> Hmm this might be a seperate issue, just some very simple bitmapped font
> rendering is in place, should I panic ?

I'd plan on using FreeType and the FT2 backend for Pango; why
reinvent the wheel? "Simple bitmapped font rendering" is definitely
not enough, but hooking up FreeType rendering onto a framebuffer
is simple.

Regards,
                                        Owen