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]