Re: New source forge project ggitk

[Owen Taylor <otaylor redhat com>]

Bryan Patrick Coleman <bpcolema@uncg.edu> writes:

> On Sun, 25 Jun 2000, Andreas Beck wrote:
> 
> >> I have finaly chosen a direction for world domination, 
> >*hehe* Did you, Brain ? Really ?
> >
> >> Now I was currious to know if anyone has any sujested plans of attack.
> >> Should I just port GDK to raw LibGGI calls or should I use some other
> >> library underneath GDK such as SDL or something? 
> >
> >If there is a port to SDL, you can of course just use that, as SDL can 
> >display on LibGGI. Other than that I'd rather port it directly to LibGGI.
> >
> 
> Really what I ment here was should I truely port GDK to LibGGI or emulate
> the GDK API through preexisting libraries.
> 
> >> Would libXMI or libgwt help or is there focus too different for GDK?
> >
> >Hmm - Do you have an idea what LibGDK requires as API ? If more complex
> >stuff is used, LibXMI might help. If LibGDK emulates such things internally,
> >you won't need it. I don't know what LibGDK does about window- and
> >eventmanagement. You will probably need at least one of libgwt or libwmh.
> >
> 
> I'll have to sit down and dig through the code as I am not that familier
> with GDK. I was just not wanting to duplicate effort on the libgwt front.

GDK requires large subset of what the X api provides - arcs, 
polygons, stipples, fills, etc. A lot more than what GGI or SDL
provide by themselves.

And it requires windowing capabilities.

The linux framebuffer port uses code from the X mi layer to do the
drawing primitives, and it has its own simple windowing
implementation. 

Theis code be reused in a GGI port either by cut-and-paste, or
abstraction, but if there are existing windowing libraries built on
top of GGI, it may be better to use them, since they are probably more
mature than the stuff in the linux-fb code, and have the ability
to take advantage of GGI's acceleration support.

Regards,
                                        Owen