From: Steve Cheng <elmert@ipoline.com>
  To  : ggi-develop@eskimo.com
  Date: Tue, 4 Aug 1998 13:41:16 -0400 (EDT)

Re: setinfoflags and mansync changes

On Tue, 4 Aug 1998, Marcus Sundberg wrote:

> > Been trying to do the ggiSetInfoFlags changes,
> 
> What changes? Have I missed something?

Targets can override ggiSetInfoFlags(), rather than flags being silently
set, usually to set mansync stuff.  Some patch I posted several weeks ago,
now converting targets to use it.

> >    We'll leave it as taking no arguments for MANSYNC_CHILD, and all mansync
> >    visuals should share the mansync_hook_with_a_clashpreventing_name hack so
> >    you can use e.g. X and AAlib sync mode together.
> 
> Yes, this is a good idea.
> But it will require that the mansync-handling code be moved either
> into the core libggi or into a helper-mansync library.
> I vote for the latter.

The whole mansync-handling code, or just the little structure?

> This also reminds me that I still think dlopen()ing the same
> library several times is a bad idea, because I don't think
> the reulting behaviour is really defined.
> 
> Is there any reason we shouldn't cache opened libraries and
> keep a usagecount on them?

The manpage says:

       If the library exports a routine named  _init,  then  that
       code  is  executed  before  dlopen  returns.   If the same
       library is loaded twice with dlopen(), the same file  han-
       dle is returned.  The dl library maintains link counts for
       dynamic file handles, so a dynamic library is not  deallo-
       cated until dlclose has been called on it as many times as
       dlopen has succeeded on it.

Or it is unportable, implementation-defined/unspecified/undefined behaviour?

> >    And I suggest renaming the variable to _GGI_mansync_hook because the
> >    above name is too long!
> 
> Agreed. I also suggest we create a GLOBAL_INTERNALS file listing
> all global symbols that are internal to libggi, to prevent
> clashes in the future.

>From doc/namespace.txt:

  o  Anything that GGI exports to the world shall be prefixed with ggi_,
     ggi, Ggi or GGI (kgi_, kgi, Kgi or KGI respectively) as it would be
     done for other prefixes of the object in question.

So what's the difference between them?  

- ggi* is obviously real functions that are to be used by apps.  

- GGI* is used by display targets as GGIsetmode(), etc.
- _ggi_* are other internal functions.

- add _GGI_ for internal variables.

- What the heck is Ggi*?  
- Is there some mirror standard in KGI that I'm not aware of?

I remember seeing some rules on their respective usages but I can't find the
document anymore.

--
Steve Cheng               

email: steve@ggi-project.org   
www: <http://shell.ipoline.com/~elmert/>;