Wayland support

[Quintus]

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.

[tecosaur]

Ooops, that pcase-let had a misplaced paren, and I've just merged Ken's fix in #84.

[andresilva]

I'll try to make this work on Hyprland. I'll also try replacing ydotool with wtype since that's much lighter (doesn't require having a background service).

[msin32]

I'll try to make this work on Hyprland. I'll also try replacing ydotool with wtype since that's much lighter (doesn't require having a background service).

I have a plan for sway and gnome-wayland support. The pasting doesn't work anymore even on KDE wayland, but it did in my PR. Maybe needs adjusting sway:

swaymsg [con_id=id] focus
swaymsg -t get_tree | jq '.. | select(.type?) | select(.focused==true) can be parsed to get id, app_id, name, and geometry (from rect)

[tusharhero]

Is KDE Plasma Wayland already supported? Perhaps, you could add a section about current extent of Wayland support in the README.

[tusharhero]

I tried installing kdotools-git from the AUR. The frame shows up now but it doesn't automatically paste the content on C-c C-c. It also doesn't pick up the text already in text area.

[Y0ngg4n]

Would be nice to not only support kde and also support hyprland too

[tecosaur]

There are notes on hyperland support in the wiki, and I'll be updating the readme to mention this in the near future.

[jvillasante]

Both Fedora and Ubuntu have switched to Wayland by default. It would be nice to have Wayland support status on the Readme. I figure that Wayland is supported on KDE but not on Gnome?

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

Hey kdotool just got merged into nixpkgs, so I will be able to actually test it sometime soon when it hits the unstable branch!

[zauster]

Hey, I have a basic implementation of the needed functions for sway/wayland here: #93 It works most of the time...

[msin32]

Hey, I have a basic implementation of the needed functions for sway/wayland here: #93 It works most of the time...

I have a PR here that uses dotool instead of ydotool by default which removes the hassle of starting a service and may also improve the reliability of pasting since ydotool doesn't seem to always work. The code is minimal so it should be easy to add it to your code and see if it improves functionality

[zauster]

Hmmm, at the moment it does not work any better than ydotool... Are you sure the line make-temp-file works as intended?

[msin32]

I'm fairly sure make-temp-file works as I intended. I would agree that it feels awkward to create a temp file every time the paste command is ran. I could modify it to delete the file afterwards.

For me using plasma wayland, pasting without a region selected works every time. After testing with using a marked region I found this: Marking a region and pasting as-is never seems to work. Running emacs-everywhere with region selected and editing the text and then pasting works, but only if the server has pasted before successfully. I tested this with another machine and by restarting emacs server and these results seem consistent. In the cases where the pasting fails, the clipboard is not updated either, so I think the copying and focusing code needs analysis in order to fix this bug

[andresilva]

I use wtype instead, it works fine.

[zauster]

Hey @msin32 and @andresilva ,

I tested ydotool, dotool and wtype again and came now to the conclusion that dotool works best. I must have done something wrong the first time, because with dotool it works very consistently and even marking text, changing that text and pasting it back works now! So, for me, the sway implementation seems ready, if someone wants to test it.

@msin32 yeah, creating a temp file for every paste is a bit weird, but that is a secondary problem at the moment, I guess...

[tecosaur]

The work on wayland here looks good. I can't push this myself currently, but I'm happy to review improvements :)

Oh, and see c188282a3ddc680bfce7740fed664be7692d8d02 for why temp files are used at all. Edit: this question seem to be just about #93 on second reading.