Index: [thread] [date] [subject] [author]
  From: becka@rz.uni-duesseldorf.de
  To  : ggi-develop@eskimo.com
  Date: Mon, 10 May 1999 17:55:15 +0200 (MET DST)

Re: Troubles with ggiSetEvent

Hi !

> 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.

You can do so, but you gain nothing. If we want to keep the APIs of LibGGI
and LibGII separate, you need a wrapper function in between to transparently
do changes if necessary.

And forget about the function call overhead. The ggi/giiEvent* functions
tend to call select() or other expensive stuff, so speed isn't much of an
issue here ...

> Of course, some visual won't have such a input device (like memory for
> example).

This one has such an input device, if you use the shmem option ;-).

> 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 ?

Yes. As it can be hard for the application to find out, what the "natural"
event source for a visual is. Especially, if it (as recommended) opens the
default (NULL) visual.

> What are the criteria to select the correct input associated with the visual
> ?

This is usually determined by the target, which knows, what is available.
The X target for example knows that ouput will be in an X window, so it
directs the input from there to the application as well.
The fbdev target knows it is running on Linux and thus opens Linux_kbd
and linux_mouse. If you want joystick, too, you have to add that with
GGI_INPUT*="...".

Note, that most targets have options like -noinput to disable that behaviour,
should that be desireable.

CU, ANdy

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

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