You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is an RFC around an idea we had around a year or so ago but so far nothing has come out of it.
libwacom is a static database and the only dynamic part of it is libwacom_new_from_path() which looks up a device. Everything else is const.
libwacom is a C library and while this makes it easy to wrap in language bindings it also introduces a run-time dependency on a library (that uses glib) just to look up some static information.
Arguably we could ship what libwacom does as a single (or set of) json files1. Something like
Notably, the content of the json is not the content of the .tablet files but matches the output of the C API. Our .tablet files remain an implementation detail.
The JSON format would have to be stable, same as the C API, the semver version field can help denote which fields one can expect, and clients are required to ignore unknown fields. Either way this would make using libwacom's data files from other languages easier than writing FFI bindings.
The main thing we'd lose is the ability to dynamically add files in /etc/libwacom but that can be worked around by having the json-generating tool pick those up and dump the combined output into /etc/libwacom/libwacom-database.json.
I'm not 100% sure there's a use-case for this - our (few) users already have the code for handling libwacom and there isn't a huge queue of new users. It's unlikely existing users would switch and we'd have to maintain the C library anyway.
This is an RFC around an idea we had around a year or so ago but so far nothing has come out of it.
libwacom is a static database and the only dynamic part of it is
libwacom_new_from_path()
which looks up a device. Everything else is const.libwacom is a C library and while this makes it easy to wrap in language bindings it also introduces a run-time dependency on a library (that uses glib) just to look up some static information.
Arguably we could ship what libwacom does as a single (or set of) json files1. Something like
Notably, the content of the json is not the content of the
.tablet
files but matches the output of the C API. Our.tablet
files remain an implementation detail.The JSON format would have to be stable, same as the C API, the semver
version
field can help denote which fields one can expect, and clients are required to ignore unknown fields. Either way this would make using libwacom's data files from other languages easier than writing FFI bindings.The main thing we'd lose is the ability to dynamically add files in
/etc/libwacom
but that can be worked around by having the json-generating tool pick those up and dump the combined output into/etc/libwacom/libwacom-database.json
.I'm not 100% sure there's a use-case for this - our (few) users already have the code for handling libwacom and there isn't a huge queue of new users. It's unlikely existing users would switch and we'd have to maintain the C library anyway.
Footnotes
or some other easy-to-process file format ↩
The text was updated successfully, but these errors were encountered: