Index: [thread] [date] [subject] [author]
  From: Andreas Beck <becka@rz.uni-duesseldorf.de>
  To  : ggi-develop@eskimo.com
  Date: Thu, 3 Jun 1999 16:57:40 +0200

Re: Sure-fire way to detect GGI.

> > If ggiInit() and ggiOpen() succeeds LibGGI works, if it

> I'm writing a multiplatform library. I would prefer to
> use GGI first and then any other library last. If GGI is
> not installed, won't GGIInit() bomb out the entire program
> rather than return an error code? 

The program will not link at loadtime and thus bomb out.
LibGGI makes quite some effort to avoid that behaviour for binaries.

You will at least need some kind of dynamic loading in place
to avoid this problem at runtime.

It can more easily be solved at compiletime, where I'd just detect the
presence of LibGGI and the includes and assume the user knows what he's
doing and sets an override (like ./configure --disable-ggi) , if he
knows that LibGGI doesn't work as expected.

If you want a runtime check rather, and you don't already have code to 
do that, I'd rather leave that problem to LibGGI and always use it.

> > extension for) you have to draw the cursor yourself,
> Yeah. But then I end up with two cursors in X11 target of GGI. 

Not really. The X cursor is set to a single dot for GGI-on-X. Shouldn't
be too noticeable.

One might also want to turn on relmouse Ctrl-Alt-M, which will turn off the
cursor entirely.

CU, ANdy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =

Index: [thread] [date] [subject] [author]