Installation in OpenSuse Tumbleweed

[algnor]

I have currently not found a way to fully run this program in Opensuse Tumbleweed. Would it be possible to add support for OpenSuse TW?

I have currently tried running src/main.py with the required dependencies installed, the rgb changes to rainbow fade, and the keys does seem to be detected. (not shown in console output, but it definitely does work) However the GUI never appears

OS: OpenSuse Tumbleweed Keyboard: G910 orion spark python 3.10.9

 ~/Documents/tests/keyboard-center   master  python3 src/main.py
[root] INFO: 01.02.2023 11:27:27  ------------ starting -------------
[Configparser] DEBUG: 01.02.2023 11:27:27  Config file location: /home/XXXX/.config/keyboard-center/settings.yml
[Configparser] DEBUG: 01.02.2023 11:27:27  loading config file /home/XXXX/.config/keyboard-center/settings.yml
[Configparser] DEBUG: 01.02.2023 11:27:27  config loaded: {'mappings': {'MEMORY_1': {'MACRO_1': {'name': 'example-A', 'string': 'A', 'type': 'key', 'value': [1, 30]}, 'MACRO_2': {'name': 'example-cut', 'string': [['Ctrl', 'X'], ['Ctrl', 'V']], 'type': 'macro', 'value': [[[1, 29], [1, 45]], [[1, 29], [1, 47]]]}, 'MACRO_3': {'name': 'example-nice', 'string': [['N'], ['I'], ['C'], ['E']], 'type': 'macro', 'value': [[[1, 49]], [[1, 23]], [[1, 46]], [[1, 18]]]}}}, 'settings': {'retryCount': 5, 'usbDeviceID': 2, 'usbTimeout': 1000}}
[BGService] INFO: 01.02.2023 11:27:27  setting up service...
[BGService] INFO: 01.02.2023 11:27:27  searching for supported keyboard...
[BGService] INFO: 01.02.2023 11:27:27  keyboard found: Logitech G910 Orion Spark
[Configparser] DEBUG: 01.02.2023 11:27:27  setting deviceID to 2
[BGService] DEBUG: 01.02.2023 11:27:27  time taken to find keyboard in ms: 42.72031784057617
[BGService] DEBUG: 01.02.2023 11:27:27  requesting USB endpoint...
[BGService] DEBUG: 01.02.2023 11:27:27  searching HIDpaths...
[BGService] DEBUG: 01.02.2023 11:27:27  HIDraw write endpoint found: /dev/hidraw0
[BGService] DEBUG: 01.02.2023 11:27:27  HIDraw read endpoint found: /dev/hidraw1
[BGService] DEBUG: 01.02.2023 11:27:27  HIDraw read endpoint found: /dev/hidraw1
[BGService] DEBUG: 01.02.2023 11:27:27  HIDraw read endpoint found: /dev/hidraw1
[BGService] DEBUG: 01.02.2023 11:27:27  HIDraw read endpoint found: /dev/hidraw1
[BGService] DEBUG: 01.02.2023 11:27:27  Checking for HID availability...
[BGService] DEBUG: 01.02.2023 11:27:27  Connected to /dev/hidraw1
[BGService] DEBUG: 01.02.2023 11:27:27  creating uinput device
[QT] DEBUG: 01.02.2023 11:27:27  start health check...
[BGService] INFO: 01.02.2023 11:27:27  starting service loop...
[BGService] DEBUG: 01.02.2023 11:27:27  Sending sequence to disable G keys
[QT] DEBUG: 01.02.2023 11:27:27  setting up GUI...
[Configparser] DEBUG: 01.02.2023 11:27:27  loading config file /home/XXXX/.config/keyboard-center/settings.yml
[Configparser] DEBUG: 01.02.2023 11:27:27  config loaded: {'mappings': {'MEMORY_1': {'MACRO_1': {'name': 'example-A', 'string': 'A', 'type': 'key', 'value': [1, 30]}, 'MACRO_2': {'name': 'example-cut', 'string': [['Ctrl', 'X'], ['Ctrl', 'V']], 'type': 'macro', 'value': [[[1, 29], [1, 45]], [[1, 29], [1, 47]]]}, 'MACRO_3': {'name': 'example-nice', 'string': [['N'], ['I'], ['C'], ['E']], 'type': 'macro', 'value': [[[1, 49]], [[1, 23]], [[1, 46]], [[1, 18]]]}}}, 'settings': {'retryCount': 5, 'usbDeviceID': 2, 'usbTimeout': 1000}}
loading 0 0
AAAAA Key: name <example-A>, type <key>, string <['A']>, value <[(1, 30)]> example-A 

[zocker-160]

Thank you for this report, it reminds me that I need to change some defaults to what the user expects.

Currently, if you run directly from the repository, no GUI will be shown as it will default to showing a tray icon instead. You can show the GUI by clicking on the icon.

Apart from that, the log looks good and also you seem to already have the udev rules for your keyboard in place (probably by some other application you have installed), so it should work.

As for OpenSuse support:

Theoretically it is possible, but practically I have absolutely no idea nor experience with packaging for anything that is .rpm based.

Furthermore, there is sadly the problem that one .rpm will not make everybody happy, as Fedora, CentOS and Rocky Linux etc. etc. users will also come in and expect it to work (or complain when it doesn't).

In short: I personally am not willing to offer packages outside of Ubuntu LTS and Archlinux, sorry :(.

[algnor]

Ahh I see, that's understandable. I would love to help but I have absolutely no idea how to package programs. I might look into it and see if I can get something working. But I really cant guarantee anything.

Anyways as long as I'm able to run the program I'm happy. And the gui does seem to work perfectly after actually opening it.

I think it starting in the background is the "correct" choice for a program that's mainly supposed to be run in the background. But a notification like: "Keyboard Center: Press tray icon to open GUI" Would be great.

Anyways thanks for the help :)

[zocker-160]

And the gui does seem to work perfectly after actually opening it.

Nice glad to hear.

I think it starting in the background is the "correct" choice for a program that's mainly supposed to be run in the background.

True yes, but it is a simple checkbox in the UI, so I think I will change to show it by default and when the user does not want to see it, he can just check the box to hide on start.

But a notification like: "Keyboard Center: Press tray icon to open GUI"

This has caused issues in the past, where on some GNOME setups it would not show the icon and / or not be clickable, so in those cases the user would see nothing. It is very rare though, so I will think about it.

[ptrsmk]

@algnor Did you manage to get this working to any meaningful extent?

[algnor]

yes, run /src/main.py and then press on the tray icon to open the gui. Everything seemed to work fine for me in wayland, and since i don't reboot that often i just manually started the program.

However sadly i never got it fully working as i wanted, but that was because I'm running wayland, and the alternatives to xdotool turned out to be rather... bad. But that being said, the program did its job perfectly fine.