Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: add gnome-shell compatibility #46

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

FlorianLudwig
Copy link

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.

@lgtm-com
Copy link
Contributor

lgtm-com bot commented Jun 10, 2020

This pull request introduces 1 alert when merging e9c4f3d into fbec7ed - view on LGTM.com

new alerts:

  • 1 for First parameter of a method is not named 'self'

this gives another ~23% performance increase for get_current_window_gnome_shell
measured in wall clock time.
Copy link
Member

@johan-bjareholt johan-bjareholt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

self.bus = None and self.gnome_shell = False would make more sense.


def _setup_gnome(self) -> None:
js_code = """
global._aw_current_window = () => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@Jakuje
Copy link

Jakuje commented Aug 6, 2020

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).

@johan-bjareholt
Copy link
Member

@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.

@rickdub2011

This comment has been minimized.

@jacksongoode
Copy link

Any further thoughts on this request?

@jopereira
Copy link

This no longer works with GNOME 41 that restricts Eval. There is a workaround (https://github.com/ramottamado/eval-gjs) but packaging _aw_current_window as a Shell extension seems to be now the best alternative.

@sgraf812
Copy link

FYI, https://extensions.gnome.org/extension/4974/window-calls-extended/ might already provide the info you need

JohannesBuchner added a commit to JohannesBuchner/activitytracker that referenced this pull request Dec 9, 2023
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.
@JohannesBuchner
Copy link

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

@mathieujobin
Copy link

Thanks @JohannesBuchner

its sad this never got merged/released...

@ErikBjare
Copy link
Member

ErikBjare commented Nov 26, 2024

@mathieujobin awatcher (https://github.com/2e3s/awatcher) supports GNOME Wayland if used with this gnome extension

@mathieujobin
Copy link

@ErikBjare

Oh thank you, i am going to try it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants