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.
This gets us nearly to a proper profile manager and keybinding tool! Very very
close, despite the messiness of the codebase. There's lots of low hanging fruit
for those who are interested in contributing.
- Made BindingProfile serializable to a python dict
- Fixed a bug in BindingProfile that named keys in the g13d command stream
incorrectly.
- Made ButtonMenu attempt to grab the keyboard when it shows so we can get
more correct keypresses. This is only half the battle -- need to stop GTK's
event loop for other widgets from catching events and handling them.
- Added a g13d communications worker thread, including saving of profiles to
disk as well as uploading profile configurations to g13d. This uses a Queue
for incoming tasks from the GUI thread, and dispatches results back by way
of GObject signals. Could use some work to make this less clunky.
- Made MainWindow load the profiles from disk. This is done on the GUI thread,
which isn't ideal.
- Added an Upload button to push changes over to g13d. This reacts to the
worker thread's connected/disconnected signals.
This represents a full day of work just to get the binding behaviors correct and
the profile behaviors correct. At this point, this should be possible to turn
into something useful for controlling g13d with.
Things left to do:
- Setup a thread for communicating with g13d with
- Setup a worker queue to send profile changes or updates to the g13d daemon
Once those are in there, we can consider this to be feature complete for 1.0.
Additional functionality, such as LED colors, drawing to the LCD, and things
like supporting dbus IPC so we can handle applets on the LCD will come later.
Late night hacking causes all kinds of silliness. We only want to stop running
an action when the key is not pressed now, but was prior pressed. My logic
caused it to fire when not pressed and not prior pressed, erroneously, leading
to stuck keys.
Totally misread the code in the Action_keys::act method -- the code actually
reverse sends events in an up condition. Still, keeping the C++11 iteration and
improving by using boost::adaptors::reverse.
Double underbars are reserved for the compiler and system, so we shouldn't use
them for header guards. Additionally, remove a bunch of these line breaks.
Lots of cross-translation unit messes in here cleaned up finally. This should be
the last change necessary to clean up these refs between translation units.
This is the first half of some major rework of the g13d codebase to make things
a bit more manageable. This splits out a great deal of stuff from helper.h into
separate translation units, and also breaks out a great deal of the g13.h header
into separate translation units as well.
Doing this saves in compilation time as we make changes to the system, and also
helps to clean up a whole bunch of leaking symbols.
