Index:
[thread]
[date]
[subject]
[author]
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/>
Index:
[thread]
[date]
[subject]
[author]