RFC: add gnome-shell compatibility #46
Conversation
|
This pull request introduces 1 alert when merging e9c4f3d into fbec7ed - view on LGTM.com new alerts:
|
this gives another ~23% performance increase for get_current_window_gnome_shell measured in wall clock time.
There was a problem hiding this comment.
Cool that you got this working!
Won't be complete without contributing similar changes to aw-watcher-afk, both sway and kwin implements the idle.xml protocol but I'm not sure if Gnome does that.
Not sure how well pydbus would work with pyinstaller due to it requiring system libraries, will have to look into that. Another option would be to only support Gnome when running/installing from source.
I'd prefer to avoid compositor specific code in aw-watcher-window, but since wayland is the way it is with fragmenting APIs for the linux desktop due to compositor developers making their own wayland APIs instead of working on having common wayland protocols I'm still not against possibly merging something like this in the future.
Having it as a gnome extension though would of course also be an option, but then the installation experience wouldn't be as good if you have to install two things instead of just one I believe.
| except ModuleNotFoundError: | ||
| logger.info("pydbus not installed, GNOME-Shell Wayland support disabled") | ||
| self.bus = False | ||
| self.gnome_shell = None |
There was a problem hiding this comment.
self.bus = None and self.gnome_shell = False would make more sense.
|
|
||
| def _setup_gnome(self) -> None: | ||
| js_code = """ | ||
| global._aw_current_window = () => { |
There was a problem hiding this comment.
Nice!
Much better solution now, no race conditions so seems like it should be reliable.
| else: | ||
| cls = xlib.get_window_class(window) | ||
| name = xlib.get_window_name(window) | ||
| class Linux: |
There was a problem hiding this comment.
All other platform specific changes are in seperate files so would make more sense to create a new gnome_wayland.py file and only check for which backend to use in lib.py
|
Is there any progress on this? I would be glad to start using this on GNOME wayland as I getting tired of useless reports from rescuetime (where I do not expect this will be ever implemented). |
|
@Jakuje Unfortunately there's no progress as you can see. If it important for you to use Wayland it is possible to use aw-watcher-window-wayland but that does not work on gnome due to it not implementing the wlr-foreign-toplevel-management Wayland protocol. Otherwise the status is the same as before, we'd like to avoid merging this if possible because it's gnome specific rather than Linux/Wayland specific, but if we have no option in the future we might merge it anyway. |
This comment has been minimized.
This comment has been minimized.
|
Any further thoughts on this request? |
|
This no longer works with GNOME 41 that restricts |
|
FYI, https://extensions.gnome.org/extension/4974/window-calls-extended/ might already provide the info you need |
Based on information from: ActivityWatch/aw-watcher-window#46 https://askubuntu.com/questions/1412130/dbus-calls-to-gnome-shell-dont-work-under-ubuntu-22-04 https://github.com/hseliger/window-calls-extended To avoid opening a security hole, it is wiser to install the "Window calls extended" extension by hseliger. Then we can regularly query the currently active window. Compared to the previous version, activity/passivity of the user is not detected anymore.
|
Thanks @sgraf812, based on the information here I was able to put together a primitive activity logging shell script for gnome+wayland, you can see it at https://github.com/JohannesBuchner/activitytracker/blob/master/track-gnome.sh |
Add gnome-shell specific way of getting current window. Allows the watcher to work on wayland.
This is gnome-shell specific and won't work on any other wayland based compositor and therefor does not solve #18
The poetry.lock needs updating but I have to figure out how to do it without updating all libs and just add the new dependency.
As this features requires a new dependency and is specific to one OS with one desktop environment, I marked that dependency as optional. Especially since it requires system libs to be installed to function, increasing the overall footprint quite a bit on non GNOME systems.