From: BERNARD Sebastien <sebastien.bernard@cegetel.fr>
  To  : 'ggi-develop@eskimo.com' <ggi-develop@eskimo.com>
  Date: Mon, 10 May 1999 16:55:30 +0200

RE: Troubles with ggiSetEvent

See my last post :
why not having some ggi_input_t that maps to gii_input_t.
When you need to get some input from the target just do :
	MyInput = ggiGetInput(MyVisual);
Then play with MyInput.
Of course, some visual won't have such a input device (like memory for
example).
So you have to check the result of the function.
By the way, it is normal that the opening of the visual automagically opens
a ggi_input ?
What are the criteria to select the correct input associated with the visual
?

> -----Message d'origine-----
> De:	becka@rz.uni-duesseldorf.de [SMTP:becka@rz.uni-duesseldorf.de]
> Date:	lundi 10 mai 1999 16:41
> À:	ggi-develop@eskimo.com
> Objet:	Re: Troubles with ggiSetEvent
> 
> Hi !
> 
> > I just looked at my copy of the source, and I'd like to wonder something
> > on this topic:
> > Why are the GGI wrappers around the GII functions not implemented, where
> > not too complex, as macros? As it is, they are in the library, and the
> > compiler can't inline from a library. So we end up with an extra
> > function call, for no good reason.
> > Or am I an idiot, and there is a reason?
> 
> There is. Opacity of the ggi_visual_t. The idea is, that the application,
> in order not to need relinking, if we change internal structs, should
> never
> access something inside such internal structs.
> 
> A Macro would need to access vis->input which would break that scheme.
> 
> Moreover, we migt one day decide, that LibGII should be replaced by 
> something superior we found somewhere, so the function allows to even 
> transparently do this.
> 
> CU, Andy
> 
> -- 
> Andreas Beck              |  Email :  <Andreas.Beck@ggi-project.org>