"Brian S. Julin" wrote:
> Well, I haven't read the code to see what guarantees of sequential receipt
> of events are there (and if the ones that are in the code are actually
> guarantees, we haven't documented that such that it is a part of the API
> that the guarantee exists, but how about this: send the devinfo query,
> then send an event to yourself through the loopback mechanism (see
> the libGII demo.c program in the current CVS where I did this to the null
> input.) I THINK, you will never receive the looped back event until
> you've received your devinfo responses.
uh, excuse me, but that sounds like a horrible hack. It basically assumes
that behind the asynchronous facade is hidden a pretty synchronous mechanism.
What about multi threading (I mean, if some day GGI uses threads internally
to 'watch' input devices) etc. ?
> Note for loopback events we
> are depricating checking the event origin to see if it is a loopback,
> instead you should check the event target field and see if it
> contains GII_EV_TARGET_QUEUE.
>
> /me looks at docs and sees this deprication thing hasn't been
> documented yet in some places. Hrm.
Yeah, you have a huge job documenting everything. There are so many unclear
things. The example code doesn't realy help, it is more a 'funny that this works'
kind of thing :)
> Anyway, while I appreciate that Berlin has other consoles now and
> needs its own event system, I wish things were different such that
> any work on specialized event filters could be done on the LibGII
> core instead thus enhancing LibGII... would making LibGII inputs
> for the other Berlin consoles allow a lot of this code to be
> moved into LibGII?
Well, I agree on you desire to capture as much flexibility inside libGII
as possible, that's its goal after all. However, berlin uses a pretty different
event type system:
There are a couple of 'event items' an event is composed of:
* toggles represent button/key press/release events
* bitsets represent modifier flags
* positions represent, well, positions
* valuators as well
An event is now a sequence of these items (something like a strongly typed
union). The idea is that depending on the user's h/w and preference settings,
an event can contain different things at once. For one, the stylus can be
mapped to a positional event with toggles (the x and y valuators map to
a position, the pressure maps to a toggle, given a thresold). Additionally,
the users decides what modifiers *can* be used, so the event size (the length
of the sequence) is trimmed to what is really needed. The mapping rules
would be written in a little script (for which I'm going to write a tiny parser).
An event thus contains one 'changed' item, and possibly a couple of 'state'
items. While each item comes from a single device, different items in one event
don't need to (i.e. you can have a position from a mouse together with a bitset
from a keyboard representing modifier keys).
While this could certainly be coded as part of GII, I'm not sure that everybody
agrees on this approach. It is what I use in berlin, especially in the light
of berlin being experimental and open towards new devices (i.e. devices that
don't exist at the time the display server is compiled).
Best regards, Stefan
