jtgans / g13gui Goto Github PK

Right now, we have a bunch of unit tests in the modules for the g13gui, but it would be far better if we had these tests running as part of the cmake build. We should investigate getting that done.

In keeping with "maintaining state of last use", the AppletManager should automatically bring the last applet that was running to the foreground when the configurator restarts. This would require a bit more persistence to disk (maybe via Preferences/PreferencesStore), but also would include an order-of-operations issue in case the last applet hasn't registered yet.

We need to be able to swap between profile sub-pages using the M1-M3 buttons. This would require quite a lot of work on the profile code, so I've been avoiding it up until now.

Build in keyboard capture for the MR button, triggered by g13d, including storage of the change to the current profile.

Writing applets should be cheap and easy -- we have a full widget set, registration flow, and even a helper function to run them and keep their design down to a single page of code. What they're missing now is persistence of settings. It would be nice if we had a simple key-value datastore, similar to the GUI's Preferences object that simply pushed its entire set of data to disk every time a value changed.

Maybe something standardized, like python's built-in @property decorator to help with this?

Right now, most of the functionality built into the configurator is available only as internal configuration changes in the Preferences object. External applets will need to be able to call into this functionality as well, so we should expose the profile switching behavior via GLib Actions or via explicit D-Bus objects exposed for this purpose via the AppletManager.

This blocks #10, since the profile switcher should probably be implemented as an external applet.

It would be good to have gUnit integrated into the build system so that we can start testing the various backend component behaviors of the system. Ie: command processing, internal data structures, etc. Actual behavior of business logic need not be tested, but we do want to make sure our foundations are good.

Right now the Gtk windows we use are hand-rolled, code-based, UI layout messes. We should clean this up to use Gtk templates and the Gtk Builder UI resource files instead. This should really be fixed before we hit Beta.

Hi, I downloaded the package and tried to compile it, I get the following message.
Makefile:14: Building on debian
make: Nothing is done for 'all'.

I currently have g13 running with ecraven build, but I would like to modernize it, I have no idea about python.

Thanks in advance.
Alex; Debian-Trixie

Right now we don't have one, so we can't start the application from the various desktop launchers.

Right now, we're kinda punting on not having an icon for the configurator. This works fine for Alpha, but when we start going toward Beta, we'll want to resolve this, since we can't really exist in the GNOME launcher, or as an appicon, or even as a normal Gtk3 application without one.

This means we can't do unicode strings in bitwidgets. This should probably be fixed somehow before we hit 1.0, otherwise folks that speak different languages won't be able to read.

Build in basic profile switching into the LCD, by way of the applet interface.

It should be possible to introspect D-Bus to find every object published that implements the com.theonelab.g13.Applet interface, with objects published under /com/theonelab/g13/applets/$APPLET_NAME path. From that, we can determine their registration, and only start them when we want them.

IOW, the GUI should be the only thing a user should need to add to their session startup routines. The applets should be automatically started via dbus discovery and activation. This would do two things:

1. Eliminates the weird backward connection validation flow we use for applets (applet calls AppletManager#Register, then periodically pings the AppletManager to ensure connectivity, AppletManager itself doesn't really monitor applet liveness)
2. Lends itself toward more accessible user-specified controls of which applets to start (Gnome's concept of "auto-start" for the session is only available via Tweaks, which isn't exactly "user-serviceable").

Basically, what we actually want is to only start the G13 Configurator for everything to be up and running.

Seems to be something relating to how the window is being destroyed. We probably want to instead re-create the MainWindow instance from the appindicator class and show that instead of having the main loop do so.

The original Logitech G13 driver software for Windows allowed for lua scripting of various buttons. It would be nice if we could do something like this as well, since scripting these buttons would allow for crazy things like key chording, etc.

We'll need to redesign a few things, such as the way profiles are stored in memory, how we trigger profiles vs. key events, etc. This is going to be a big undertaking. Probably something we might want to push off until 2.0.

It would be really awesome if we could display the LCD output in the GUI as well, including the LED backlight color. We already have support for rendering the resulting screen bitmaps via the tests, so it shouldn't be all that difficult to achieve. Super low priority, though.

g13d segfaults with a hard crash when it encounters a bare "dump" command in its input fifo. Seems to be some kind of bad string manipulation error:

[g13] omoikane:~/Projects/g13/build/g13d$ gdb --args ./g13d --pipe_in /run/g13d/in --pipe_out /run/g13d/out
GNU gdb (Ubuntu 9.1-0ubuntu1) 9.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./g13d...
(gdb) run
Starting program: /home/jtgans/Projects/g13/build/g13d/g13d --pipe_in /run/g13d/in --pipe_out /run/g13d/out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[2021-04-28 23:33:58.065597] [0x00007ffff7809b80] [info]    set log level to info
[2021-04-28 23:33:58.065685] [0x00007ffff7809b80] [info]    set_string_config_value pipe_in = "/run/g13d/in"
[2021-04-28 23:33:58.065700] [0x00007ffff7809b80] [info]    set_string_config_value pipe_out = "/run/g13d/out"
[2021-04-28 23:33:58.065966] [0x00007ffff7809b80] [info]    Known keys on G13:
[2021-04-28 23:33:58.065984] [0x00007ffff7809b80] [info]    BD DOWN G1 G10 G11 G12 G13 G14 G15 G16 G17 G18 G19 G2 G20 G21 G22 G3 G4 G5 G6 G7 G8 G9 L1 L2 L3 L4 LEFT LIGHT LIGHT2 LIGHT_STATE M1 M2 M3 MISC_TOGGLE MR TOP UNDEF1 UNDEF3
[2021-04-28 23:33:58.065990] [0x00007ffff7809b80] [info]    Known keys to map to:
[2021-04-28 23:33:58.066022] [0x00007ffff7809b80] [info]    0 1 2 3 4 5 6 7 8 9 A APOSTROPHE B BACKSLASH BACKSPACE C CAPSLOCK COMMA D DELETE DOT DOWN E END ENTER EQUAL ESC F F1 F10 F11 F12 F2 F3 F4 F5 F6 F7 F8 F9 G GRAVE H HOME I INSERT J K KP0 KP1 KP2 KP3 KP4 KP5 KP6 KP7 KP8 KP9 KPASTERISK KPDOT KPMINUS KPPLUS L LEFT LEFTALT LEFTBRACE LEFTCTRL LEFTSHIFT M MINUS N NUMLOCK O P PAGEDOWN PAGEUP Q R RIGHT RIGHTALT RIGHTBRACE RIGHTCTRL RIGHTSHIFT S SCROLLLOCK SEMICOLON SLASH SPACE T TAB U UP V W X Y Z
[New Thread 0x7ffff7803700 (LWP 9989)]
[2021-04-28 23:33:58.080313] [0x00007ffff7809b80] [info]    Found 1 G13s
[2021-04-28 23:33:58.115525] [0x00007ffff7809b80] [info]    Active Stick zones 
               STICK_UP   { 0 x 0.1 / 1 x 0.3 }   SEND KEYS: UP
             STICK_DOWN   { 0 x 0.7 / 1 x 0.9 }   SEND KEYS: DOWN
             STICK_LEFT   { 0 x 0 / 0.2 x 1 }   SEND KEYS: LEFT
            STICK_RIGHT   { 0.8 x 0 / 1 x 1 }   SEND KEYS: RIGHT
           STICK_PAGEUP   { 0 x 0 / 1 x 0.1 }   SEND KEYS: PAGEUP
         STICK_PAGEDOWN   { 0 x 0.9 / 1 x 1 }   SEND KEYS: PAGEDOWN
[2021-04-28 23:34:02.719611] [0x00007ffff7809b80] [info]    command: dump

Thread 1 "g13d" received signal SIGSEGV, Segmentation fault.
__strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
65	../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory.

Right now, most of our user-visible strings are hard-coded blobs. We should fix this to use gettext underscore (_) calls so we can get started on adding translations. Applets, though, are okay to ignore for now -- bitwidgets has the use of X11 PCF fixed bitmap fonts hardcoded, so unicode characters won't render.

Honestly, it's a bit annoying to have to go through and toggle on all of the settings I want every single time I start the configurator. It would be nice if the clock applet persisted its settings to disk somehow.

Right now the AppletManager is pretty rough, and has no idea what to do and simply dumps an exception when one of the following happens:

• An applet on D-Bus dies off
• An applet on D-Bus throws an exception in its D-Bus method handler

At the moment, this is okay-ish since we're still pre-alpha code, but obviously it's not ideal. We need some way of tracking the applet peers on D-Bus. Maybe something like this:

1. Applets register D-Bus objects using the interface com.theonelab.g13.Applet under the path /com/theonelab/g13/Applet/AppletName
2. AppletManager uses the list of objects under /com/theonelab/g13/Applet/... as it's literal dictionary of applets available every single time it needs to do something with one. IOW, it polls D-Bus for applets and does a loose mapping between applet object name and its internal list of "registered applets".

This would reduce some of the sources of the above two problems, but ultimately, I think we need lots of exception handling written around D-Bus proxies. Maybe a new class that wraps dbus.proxy.ObjectProxy to handle these things more gracefully?

Given that over half of the g13gui module is expected to be used by third-party applications (bitwidgets, applet, observer), we should at minimum have the following things documented:

• Every public method and object in each module should at least have a one line description of what it does, what the arguments it takes are, and what it returns
• Unit test case methods should have a short docstring explaining what they test, and how.

One of the things that was really neat with the scriptability of the G13 drivers was the ability to write an "overlay" or "chording" setup in Lua and then it just sorta-worked, by switching key sub-profiles. It would be neat if we could write something in the driver itself that handles this layering/chording behavior naturally. Effectively making the assigned G key like a momentary M1-M3 key.

I've already done a first pass on this, but it really needs to be verified. There's a couple of places where Boost junk just absolutely permeates whole translation units. Given g13d's age, it's unsurprising, but with C++11, most of this stuff can be removed.