On Wed, 27 Jun 2001, Stefan Seefeld wrote:
> > > I guess a more flexible scheme would be a dictionary of name/value pairs,
> > > both dynamically allocated strings. Is there any way to add that to GII ?
> I don't see how a single long (parsable) string would solve any of the
> problems. Given that it would be an (untyped) list of pairs of strings,
> you can print that out (may be with a little helper function) without
> caring what these strings contain. But when you care, i.e. when you want
> to know the version string, you would in your case need to parse the
> whole string, while in my case you simply look for a pair where the first
> member is "version". Or did I miss something ?
I don't get what you mean by having a pair of strings; I was thinking just
one string.
I believe the strings given by the evdev driver are pulled out of the device
firmware, at least for USB. Also, just because the evdev (==USB right now
on Linux) API has a driver name, a device name, and a vendor name does not
mean all LibGII input targets will have these three values. They may have
more, in fact, like, for example, a locale code. By using/parsing a string,
we have a solution that will always extract the correct field, and when joe
user goes to MediaPlay and buys his "PowerSandle" in May of 2006, the crusty
old installed-from-CD libc7 RedHat version of LibGII he has on his computer
will allow an app to say:
"Found Input Device: PowerSandle v3.2, (Logitech) 6 axis, 0 buttons"
even though the PowerSandle didn't exist when it was compiled.
Now, an app that wanted to know the version, would call an API
function giiExtractVersion(str) to get the version string out. Versions,
BTW have to be strings because not everyone uses the same notations.
If we cleverly choose the format of the string, we should be able to
make escape characters rarely needed.
The main problem though, is that there is likely a reason why fixed size
was used. We need to carefully review the implications of adding a
variably sized event; at minimum I anticipate we will need to malloc
the event and the string in the same inscestuous structure such that
nothing leaks if you just free the event.
--
Brian
