On Sat, 30 Sep 2000, Lee Brown wrote:
> I think I see what you are trying to do. You could use a structure to associate the
>filename with the visual.
>
> struct texture {
> ggi_visual vis;
> char* filename;
> };
>
> Then work with the texture structure instead, dereferencing each member as
>appropriate when neccessary.
I think that he's trying to avoid the syntactical ugliness of
the dereference while calling normal LibGGI api functions.
What about if we came up with a libGGI extension specifically
_for_ carrying application specific data in a visual that would take
care of everyone who ever wanted to do it for any reason in one
swell foop. It would look something like this:
struct mydata {
int foo;
char *filename;
};
struct mydata *dh;
ggiMetaDataInit();
/* open a visual, yada yada */
mydataname = "mydata";
ggiMetaDataCalloc(vis, &mydataname, sizeof(struct mydata), 1);
/* Regular data can be accessed with no nuance */
#define TextureNum(vis) ((struct mydata *)(ggiMetaDataPtr(vis, "mydata"))->num)
/* e.g. */
TextureNum(vis)++;
/* Nested dereference requires a little more work if you want all the
data cleaned up when the visual is closed or for any other reason want
to keep it all inside the object. Probably this simple string example
is worthy of convenience macros in the extension header. */
#define TextureFilenamePtr(vis) \
((struct mydata *)(ggiMetaDataPtr(vis, "mydata"))->filename)
#define setTextureFilename(vis, str) \
{ ggiMetaDataFreePtr(TextureFilenamePtr(vis)); \
TextureFileNamePtr(vis) = \
ggiMetaDataAnonCalloc(vis, "mydata", strlen(str) + 1, 1); \
strncpy(TextureFileNamePtr(vis), str, strlen(str)); \
}
/* By-hand deallocation has two forms, named and anonymous. */
ggi MetaDataAnonCalloc is anonymous allocation, but still needs
string argument so this: */
ggiMetaDataFree(vis, "mydata");
/* Will clear any nested data structure as well. */
/* Otherwise... */
ptr = ggiMetaDataPtr(vis);
/* [...] */
ggiMetaDataAnonFree(vis, ptr);
...of course using strings to index data would make this not useful
for anyone that needed to hammer on the metadata of many visuals
heavily... but then many visuals aren't exactly an efficient way
to go about things to begin with.
Alternatively, the Christoph could write his program in Perl
and simply subclass GGI:: :-).
--
Brian
