Commit Graph

7 Commits

Author SHA1 Message Date
Yaroslav Chvanov
ac999da26c data: remove usage of the deprecated LED type field 2023-02-25 13:39:41 +03:00
Julian Kandlhofer
4f36371af3 implement 'DeviceType' property
Signed-off-by: Julian Kandlhofer <julian.kandlhofer@gmail.com>
2023-02-14 16:29:20 +03:00
mistepien
6dcd17d340 data: add additional USB id for Logitech G102 (046d:c09d) 2023-01-06 17:45:30 +03:00
Nguyễn Chính Hữu
1e72ebaa7b data: add the G203 name to the .device file 2020-08-29 22:23:35 +01:00
Dejan
02226d0428 data: add another device ID for G203 mouse 2020-07-09 21:54:56 +01:00
Peter Hutterer
734977f176 Drop the SVG handling from libratbag
The SVGs must not be part of any stable API, there is too much behavior
implied that we cannot/do not specify. So it's perfectly likely that a future
change in the SVGs or rendering libraries breaks things in some detail. But
then we cannot update the SVGs without risking breaking other clients that
rely on the current behavior.

Besides: we only have one theme, called "gnome" because a push
towards having SVGs for other themes never happened.

And that theme isn't gnome-specific, it merely looks GNOMEy. The theme is very
much piper-specific in that it requires certain elements that piper cares
about. Currently anyway, if we make this part of our API, piper cannot change
that behavior ever without breaking others.

So let's drop SVG handling completely and rely on the clients to sort it out
for themselves.

For now the SVGs are left in the tree to make it easier to copy to Piper. Once
that's done, we will remove those too.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2019-02-22 11:17:09 +01:00
Luke
9b848084fd data/gnome: added device entry for G203/G102, artwork needed (#490) 2018-07-05 03:01:35 +01:00