> Subject: joined irc meeting GGI - Berlin
> since I'm not subscribed to any of the GGI mailing lists,
> could you please forward this mail to an appropriate forum ?
So he did
> We'd like to design the appropriate structures/tools to be
> able to process events from arbitrary input devices. Since
> you probably already did some work in this direction, what
> about an irc meeting with people from GGI and Berlin so that
> we can learn a bit from your experience ?
Fine with us. Please suggest a time/date and we will see to find a common
denominator.
> The current idea is to manage attribute lists so that individual
> devices are flagged for each supported attribute. Each attribute
> in this property list then hints at an entry of some type within
> the event's attribute list.
> Possible attributes would be (together with the corresponding
> type in the event structure)
>
> telltale -> bitset
> positional -> (2D/3D vertex)
> key -> long (keysym)
> value -> float
>
> so that *every* input device would be described as a combination
> from the above elementary types.
This is relatively similar to what LibGII does. The basic types are Keys
(with Press/Release/Repeat events) which consist of three fields:
Code (arbitrary number just unique for the device in question)
Label (What is printed on the key ?)
Symbol (What symbol should be produced by it given the current modifiers).
and Valuators, which are sets of analog inputs divided into multiple
"values" or axes.
> An event would need (at least when
> thought of as the most general thing which can happen) to hold
> one such list (the changes triggering this event) and a set of lists
> (one per connected device) to show the total state of the input devices.
We decided to use a delta-only approach, as holding the complete device
state is usually not needed. If an application wants to track state, it can,
but most of the time it's just wasted ressources.
BTW in case you wonder: LibGII can send events _to_ devices as well. This
feature will be useful for force-feedback, and is now used for querying
device and axis-properties. A libGGI device can tell you what the individual
valuators mean, like if they are measuring angles, forces, ....
> Well, this is all theory. How this can be made efficient and whether
> we really need such a general approach is what we would like to discuss
> with you. If possible, we'd like to have such an irc meeting as soon as
> possible (before christmas that is)
Sure. Suggest a date and time. Regarding timezones, we seem to have MET for
the people on the GGI side I am thinking of (me and Marcus - others welcome
as well of course), which will also suit your swedish member.
Then we have US and CA, what probably calls for a time in the evening in
Europe, so that the US people have a reasonable time as well. Graydon: Where
are you from ? .com can be anywhere nowadays ... :-).
> since a working input system is what
> we need next to make text processing possible...
Well - your ideas are pretty close to what LibGII provides. Hopefully we can
make a very efficient interface layer.
CU, Andy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
