search

zocker-160 / keyboard-center

Application for mapping macro keys on Logitech keyboards
GNU General Public License v3.0
66 stars 3 forks source link

Ability to hide tray icon #33

Closed Aditeya closed 1 year ago

Aditeya commented 2 years ago

Feature request to hide tray icon

The idea I have is to pass a flag like '--hide-tray-icon' or '--daemon-mode'. This flag would just run the program as a daemon and wouldn't launch any GUI or tray icon. Any instance thats started after wouldn't start because it'll check to see if the daemon is running. This way you can avoid multiple processes being spawned.

It can be a setting advertised in the help menu or the README for power users who'd like to hide it. Additionally if anyone wants to change the settings, they can:

  1. kill the process
  2. start keyboard-center normally
  3. do their changes
  4. Start with the flag
zocker-160 commented 2 years ago

Alright so I pushed a new version which implements something similar using a local unix socket. It is still a bit janky but it should work for the most part.

You now have a new CLI --background-mode flag, which will disable the tray icon.

You should be able to reactivate the primary window / instance by just executing the application again, it should close the secondary instance and trigger the primary one.

Let me know if that is a usable solution for you.

Aditeya commented 2 years ago

Yup it works well. The background instance gets killed upon spawning a new normal instance. However, it doesn't stop you from spawning multiple background instances.

zocker-160 commented 2 years ago

However, it doesn't stop you from spawning multiple background instances.

Are you sure you can spawn multiple background instances? It should not be possible, at least I cannot reproduce that.

Aditeya commented 2 years ago

2022-06-30+T17-29-09

The left window grep the process list for keyboard-center, then I spawn another instance. The right window I grep the process list for keyboard-center again. Both have the flags --background-mode.

zocker-160 commented 2 years ago

it should look like this when trying to start a secondary instance:

Screenshot_20220630_141838

Aditeya commented 2 years ago

2022-06-30+T18-54-08

Yup, its not working. I'm not sure whats causing it, but I think it might be caused by a permisson issue or a bug in QT / python. Also i got the normal instance running while the background instance was still there:

2022-06-30+T18-57-16

zocker-160 commented 2 years ago

yeah that is weird....but I don't think there is much I can do sadly, at least nothing obvious with no error message.

Are you on Wayland?

Aditeya commented 2 years ago

No Xorg, if you have any ideas on how to debug lemme know

zocker-160 commented 1 year ago

Could you try again with the latest version? (If you even still use it that is)

From my testing, I sadly could not reproduce this issue, I tried Ubuntu and Manjaro on bare metal, there the singleton for triggering the primary instance works just fine.

Aditeya commented 1 year ago

It didn't work :( image

this line https://github.com/zocker-160/keyboard-center/blob/88014fb267ead874fba125f5090b060ccddb8f48/src/main.py#L24

returns false on my system. Could it be due to a missing library?

zocker-160 commented 1 year ago

The singleton detection creates a local Unix socket in /tmp to check if another instance is already running.

There is probably something weird going on that does not let one instance access the socket of the other. I might look into changing from a Unix Socket to a simple tcp one.

Maybe you have something blocking the access to /tmp or some kind of isolation going on?

Aditeya commented 1 year ago

I just tried running it as root image

It auto launches from ~/.xprofile Is there a better way to handle this? maybe systemd-service?

zocker-160 commented 1 year ago

ok weird, looks like permission issues. Does a normal process not have write access to /tmp on your machine?

Is there a better way to handle this? maybe systemd-service?

No I am not going to go down the systemd rabbit hole again, there are good reasons why I moved away from that and switched to a tray icon.

I will look into bypassing file permissions by replacing the UNIX socket with a proper network socket. I will let you know once it is ready for testing.

Aditeya commented 1 year ago

ok weird, looks like permission issues. Does a normal process not have write access to /tmp on your machine?

it does. What happens is programs launched in .xprofile have root permissions, but programs launched from shell/app-launcher will have the users permissons (assuming your default shell is your signed in user).

so when I login in keyboard-center --background-mode is launched as root automatically. And when I run it normally, it can't detect because it doesn't have root permissions to read the unix socket. However, launching it as root works because it will have permission to read the socket.

zocker-160 commented 1 year ago

And when I run it normally, it can't detect because it doesn't have root permissions to read the unix socket. However, launching it as root works because it will have permission to read the socket.

It should not matter though, since /tmp should always have permissions set to 777, which means any process has full access. It seems to be different on your system for some reason, as from my testing it did work running as normal user.

Can you check to what permissions your /tmp folder is set to?

Aditeya commented 1 year ago

/tmp is 777. but inside, the files, have different permissions. image

zocker-160 commented 1 year ago

please retry with the latest version running as normal user

Aditeya commented 1 year ago

It Works!!!

zocker-160 commented 1 year ago

nice awesome, glad to hear!