You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With apps that you want to trayify, it is very natural to use close button and expect the app to be continued working in tray. And I do it constantly. But of course, I am facing with the closed app, and I need to again open it and trayify.
This is already a feature request #15, and it was said
Desired behaviour
When I click the 'close' button for a window, kdocker minimizes it and sends it to my system tray
and
This was added in 4.3 but removed in 4.4 because it was unreliable and caused numerous issues.
While that feature request could still be opened waiting for solution, I have another idea for the solution, slightly more reliable.
We can watch if the app is still running. When user closes app, this is detected by watcher, and then we can launch it again minimized to tray. This way it feels like user closed it to tray.
Probably, it will not work for all cases (such as probably music apps?), that is why #15 is still a valid fr. But for my case it is totally ok. I need it for gtg (getting things gnome) application, and gnome apps is known to never receive tray functionality because of limitations of gnome.
I suggest adding new option for that. For example -c Relaunch docked when closing. Mimicking close to tray behavior..
And if user want to really close (stop restarting) the app, the close entry in tray menu can handle this.
The text was updated successfully, but these errors were encountered:
Then created the /home/andrew/bin/kdocker-fake-close-to-tray.sh. Take it from here.
Take a note:
kdocker and the app is launched using x11 backend. Needed under wayland, harmless if in x11. See here for more info.
at first launch, the app window is visible (-m option)
at following launches, it is there is no more -m option, so it will be initially trayed (to be precise, the app window is visible for a second, but this is another issue, probably could be solved by applying "minimized - apply initially" in window rules).
Result:
You launch app from start menu, its window is initially visible. You close the app with close button. You see that app is "still" in tray.
If you want to stop relaunching it, open task manager (ctrl + esc) and kill the fake close to tray process.
P.S. I this watcher could probably just be a kwin script instead. Instead of constantly querying running processes, just launch a needed command (relaunch app) at window close event.
With apps that you want to trayify, it is very natural to use close button and expect the app to be continued working in tray. And I do it constantly. But of course, I am facing with the closed app, and I need to again open it and trayify.
This is already a feature request #15, and it was said
and
While that feature request could still be opened waiting for solution, I have another idea for the solution, slightly more reliable.
We can watch if the app is still running. When user closes app, this is detected by watcher, and then we can launch it again minimized to tray. This way it feels like user closed it to tray.
Probably, it will not work for all cases (such as probably music apps?), that is why #15 is still a valid fr. But for my case it is totally ok. I need it for gtg (getting things gnome) application, and gnome apps is known to never receive tray functionality because of limitations of gnome.
I suggest adding new option for that. For example
-c Relaunch docked when closing. Mimicking close to tray behavior.
.And if user want to really close (stop restarting) the app, the close entry in tray menu can handle this.
The text was updated successfully, but these errors were encountered: