Since GDK/GTK filter events through Xorg, libinput, and everything else in
between, we can't use their keypress detection code to actually figure out what
the linux key codes are, instead we read directly from all keyboard-like evdev
devices on the system.
This is less than ideal, but directly due to Linux/Xorg/libinput/XKB/GDK/GTK/GNOME's
completely batshit insane input model. On Wayland it gets better, but not by
much since most compositors still use XKB and libinput.
*sigh*
Unfortunately, strings are iterable in python, so without this a call with a
single string, or a construct of "('foo')" would result in creating keys for
each letter of the string 'foo'. "('foo',)" works, because , creates the tuple,
not the parens...
This isn't ideal, since opening all of the devices in /dev/input is slow, and
this runs on the UI thread, but it works for now. Ultimately, InputReader should
probably be restructured as a threading.Thread and use GLib.idle_add to send the
signals out.
This allows us to be a bit more flexible in the way we define bindings. We still
have to use the scancodes for the actual bindings (since we're outputting to
uinput), but this should be a little easier to digest.
...also it fixed a bug... =op
This adds a whole bunch of tests and additional widgets we can use to draw up
interfaces on the g13's LCD. It also abstracts the backend a bit so we can draw
to X11 rather than a g13.
- Added a Button and ButtonBar class so we can start making use of those great
L* buttons
- Added a Label class so we can stick text all over the screen
- Added a Screen class to abstract away common display elements such as the
button bar, as well as send along the next frame to the display.
- Created the Widget class to make a lot of common boilerplate code live
somewhere useful.
- Added X11DisplayDevice so we can test on desktops without needing a G13.
This is based upon most of the code written in g13d's device and manager classes
as a means to actually "manage" the g13 itself from the GUI. This eliminates the
silly daemon, fifos, bad protocol design, and overall a whole slew of security
issues.
Our key binds will now use actual key codes from evdev instead of using made up
key symbol names from G13D. This results in a *major* change, of which this is
just the start. Effectively, we're going to move away from using the old and
crufty g13d for everything, and just write our own g13 manager instead.
The trick with the LPBM format is that it's actually just the native LCD format
used by the G13. Each byte of the buffer corresponds to a vertical strip of 8
pixels, all monochrome. This stretches across the screen, for a full buffer of
960 bytes.
This is the first step to actually rendering to the G13's display by way of the
g13d daemon. The bitmap format is kinda weird: it's actually 860 bytes of
useable pixel data, but padded out to 960. Each byte corresponds with one
vertical column of 8-pixels, going from top to bottom.
The tests for this effectively check to make sure the length is correct, and
also dumps it out to a running g13d (if there is one). This should probably be
automated a bit more by checking the bytes directly, but given that this is a
visual task anyway, I'm being a bit lazy.
This makes use of pillow as a means for drawing up a bitmap. The overall idea is
to have applets send a series of widget draw commands over dbus to g13gui, which
then proxies it across to the actual g13.
Have to latch it using _ignoreSelectionChange to prevent loops on application
start, but this does allow us to change the profile either from the main window
or from the appindicator menu.
This allows us to quickly switch between profiles in a normal environment. It's
kinda a hack until we have proper applet support, though this will require
changes to g13d to be possible.
We weren't cloning the defaults from the bindings module, so when we went to go
modify those bindings, we'd change the defaults instead of just that instance.
yay for lack of immutability. :|
So at this point, g13gui has quite a lot of functionality built into it now. We
can bind keys, we can unbind keys, we can upload whole profiles to g13d, we can
create and edit profiles, and we can even set LCD colors per-profile.
We're not loading the configuration from disk, sadly, since I had to rework
quite a lot of the UI infrastructure to get observer notifications to work with
GTK. Lots of simplifications in here, though, which reduces the complexity of
the code considerably.
- Migrated all model related classes into the model module.
- Migrated UI classes into the ui module.
- Migrated observer-related stuff into observer.
- Created the GtkObserver adaptor for GTK UI threading. This makes heavy use
of GObject signals and queuing to dispatch to the UI thread.
- Migrated all of the G13 buttons into their own class.
- Renamed ButtonMenu into G13ButtonPopover.
- Setup the profile combo box as its own class.
- Created the profile popover so we can add/remove/edit profiles.
The BindingProfile class had a bunch of untested code that was assigning to
things by the wrong name, or making logic errors all throughout. With the added
unit tests, that cleans it up considerably.
This reduces some of the notifications during changes by reducing the scope of
changes that are monitored by other components in the system. IOW, this allows
keys to only care about their particular changes, rather than all key binding
changes in a BindingProfile.
