Wayland support

[Quintus]

trafficstars

I discovered this over at the org mailinglist, but I wonder if this project supports Wayland, the X11 successor for Linux. Given that the README currently says that

xclip, xdotool, xprop, and xwininfo

are required, I would not assume it does. There’s a Wayland alternative for xclip called wl-clipboard, but for the others I don’t know.

So, what’s the plan with Wayland?

[tecosaur]

Wayland is WIP with support for wl-copy so far.

[bevsxyz]

I am in Fedora 36 and I think xclip is mapped to wl-copy. The output on running xclip is wl-copy% .

On running emacsclient --eval "(emacs-everywhere)", it gives an error on not finding xdotool. Is wtype used in the WIP Wayland support as substitute for xdotool?

[tecosaur]

Not currently, that looks handy though.

[bevsxyz]

@tecosaur seems like wtype is not an option for gnome or rather mutter. See https://github.com/atx/wtype/issues/22#issuecomment-1174814111

[BenediktBroich]

Ther is also ydotool. Ydotool is working under Gnome.

As i see it emacs-everywhere does need:

• xdotool key is the same as ydotool key (Related Issue)
• xdotool windowactivate which seams to be missing in ydotool For security reasons wayland does not have a active window watcher. So gnome would have to implement the Watcher, but for security reasons Gnome does not do that. You would have to install a extension like this (src on github). to expose a window switcher in dbus. This could then be used by emacs-everywhere. The implementation would be specific for each other window manager. https://github.com/ActivityWatch/activitywatch/issues/92 https://github.com/ActivityWatch/aw-watcher-window/issues/79#issuecomment-1350470400
• So for gnome it would be possible to use https://github.com/flexagoon/focused-window-dbus and https://github.com/lucaswerkmeister/activate-window-by-title to get these information.

[MostHated]

It's not ideal, but initially I just made a tiny extension in which all it does is set the wayland context 'unsafe' to true, which then makes xdotool and all the typical tools work just fine again.

class Extension {
    constructor() {
    }

    enable() {
        global.context.unsafe_mode = true; 
    }

    disable() {
       global.context.unsafe_mode = false;
    }
}

function init() {
    return new Extension();
}

Since then, I have also made another small one that just exposes the info, which I can query from bash, presumaby similar to the links above. I would imagine that is what they are doing.

Multiple small functions like this:

GetTitle(winid) {
    let w = this._get_window_by_wid(winid);
    if (w) {
        return w.meta_window.get_title();
    } else {
        throw new Error('Not found');
    }
}

Making a custom extension to add the things you need/want ended up being much easier than expected if you look over a basic extension template. It's just a JS file and a json manifest with some details for name and what not, then you can expose most anything you want/need.

Doing the unsafe = true, though, just makes everything you expect to work, work, at the expense of potential vulnerabilities. Though, I don't think they are much different than when those apps all worked properly in the first place...

[edmundmiller]

This is still failing with

*ERROR*: Searching for program: No such file or directory, xwininfo

[andresilva]

Shouldn't this issue be left open given that it doesn't actually support Wayland?

[tecosaur]

Yep, it should be - particularly since now I can boot to Wayland without my WM crashing (a recent development), I can actually work on this

[tecosaur]

The challenge here is finding wayland tools that can provide all the needed functionality. What we're currently using for X11 is:

• [ ] xdotool key ...
• [x] xclip (we can use wl-copy for this)
• [ ] xdotool windowactivate --sync WINDOW
• [ ] xdotool getactivewindow
• [ ] xprop -id ... (might still work?)
• [x] xwininfo -id (for window geometry: x/y coords and height/width)

[msin32]

have you taken a look at kdotool ? It seems to have what is needed to get this working on plasma wayland. Here's my idea:

xdotool key -> ydotool key (or wtype, ydotool, dotool)
xclip -> wl-copy
xdotool windowactivate -> kdotool windowactivate
xdotool getactivewindow -> kdotool getactivewindow
xprop -id -> kdotool getwindowclassname {ID} for WM_CLASS, kdotool getwindowname {ID} for _NET_WM_NAME
xwininfo -id -> kdotool getwindowgeometry

currently working on this at: https://gitlab.com/mohsmth1/emacs-everywhere/-/tree/wayland-kde. Haven't gotten it to work yet. issues: no --sync or --clearmodifiers flags, I think it can still work without these.

[tecosaur]

Oh brilliant, I suspect that kdotool didn't have everything needed last time I looked.

[msin32]

I feel like I'm pretty close to getting it working. Emacs does pop up on hotkey, but I get error: Wrong type argument: commandp, emacs-everywhere--app-info-linux on C-c C-c. Here's what I get when tracing the function:

1 -> (emacs-everywhere--app-info-linux)
1 <- emacs-everywhere--app-info-linux: #s(emacs-everywhere-app :id 0 :class "org.kde.konsole" :title ".emacs.straight2.d : fish — Konsole" :geometry (54 0 1006 1200))

everything looks good, not sure why the id is 0 though because it gets the correct id. update: error fixed but doesn't seem to be pasting

[msin32]

It works Going to need others to test this, and then maybe I can clean up the code and do a PR Update: I have verified that the code works on another machine. prerequisites: wl-clipboard, kdotool, ydotool and start its service: systemctl --user start ydotool.

[msin32]

might be interested: @tecosaur @andresilva @edmundmiller @MostHated @Quintus

[NovaViper]

It works Going to need others to test this, and then maybe I can clean up the code and do a PR Update: I have verified that the code works on another machine. prerequisites: wl-clipboard, kdotool, ydotool and start its service: systemctl --user start ydotool.

Hey did you have to do any special changes to the package itself to get this working? Want to give this a try with Doom Emacs on NixOS

Edit: Actually just found out I can't properly test since kdotool isn't available on NixOS, made a package request so it can get added there

[tecosaur]

Brilliant! @msin32 have you considered opening a draft PR?

[msin32]

I don't see why it wouldn't work, give it a try and report back. My changes are in the wayland-kde branch here: https://gitlab.com/mohsmth1/emacs-everywhere/-/tree/wayland-kde. One liner install using straight: (use-package emacs-everywhere :straight '(emacs-everywhere :host gitlab :repo "mohsmth1/emacs-everywhere" :branch "wayland-kde"))

[msin32]

Brilliant! @msin32 have you considered opening a draft PR?

I will do it soon

[NovaViper]

I don't see why it wouldn't work, give it a try and report back. My changes are in the wayland-kde branch here: https://gitlab.com/mohsmth1/emacs-everywhere/-/tree/wayland-kde. One liner install using straight: (use-package emacs-everywhere :straight '(emacs-everywhere :host gitlab :repo "mohsmth1/emacs-everywhere" :branch "wayland-kde"))

I actually just found out I can't properly test it on NixOS because kdotool isn't on the nixpkg repository sadly 😢 Made a request here, so will have to wait til it gets added in.

[msin32]

I don't see why it wouldn't work, give it a try and report back. My changes are in the wayland-kde branch here: https://gitlab.com/mohsmth1/emacs-everywhere/-/tree/wayland-kde. One liner install using straight: (use-package emacs-everywhere :straight '(emacs-everywhere :host gitlab :repo "mohsmth1/emacs-everywhere" :branch "wayland-kde"))

I actually just found out I can't properly test it on NixOS because kdotool isn't on the nixpkg repository sadly 😢 Made a request here, so will have to wait til it gets added in.

It is available as a crate as well, cargo install kdotool

[tecosaur]

It looks like what we really need to end up with is support for an assortment of wayland-supporting cli tools, via a bunch of cond statements, or similar.

[msin32]

It looks like what we really need to end up with is support for an assortment of wayland-supporting cli tools, via a bunch of cond statements, or similar.

yes, this particular code should work with most kwin desktops including kde 5 and 6, kwinft/theseus, deepin_kwin and others.

[tecosaur]

Mmm, ideally we also want to work with gnome, sway, etc. though

[VitalyAnkh]

@msin32 Could it be implemented with ydotool to support gnome, sway...?

[msin32]

Mmm, ideally we also want to work with gnome, sway, etc. though

sway and many other wayland WMs use wlroots, I know that has libei for input but not sure about the other functions. I don't know if anything exists for Gnome either. uinput is a kernel module for input so it should work universally. tbh we will probably have to wait a long time before any other wayland environment will have support. I'm no expert, though. Maybe it's possible to write something likekdotool for mutter though.

Also, draft PR created

[msin32]

@msin32 Could it be implemented with ydotool to support gnome, sway...?

My code already uses ydotool, see my first comment. However, its capabilities are limited to input as of now. kdotool is the main reason this is possible and it is limited to kwin environments.

[tecosaur]

I've just pushed 2f2521769ae90689c5370e7580553f5b1b8f6945 based on @msin32's work as a starting point.

[msin32]

On keybind I get Wrong type argument: stringp and I haven't been able to get any more info even with toggle-debug-on-error Does it work for you?

[whatacold]

Hey @msin32,

I've also encountered this, and I've created a PR (#84) for it. If you're in a rush, you can just override emacs-everywhere--app-info-linux temporarily, otherwise wait for it to be merged.