Can developement for Autotype on wayland be resumed?

[Luciogi]

#2281 's comment #2281 (comment) mentioned its upstream issue.
Wayland developers did not accept proposal.
XDG protocol flatpak/xdg-desktop-portal#624 issue is solved.

[droidmonkey]

There is no point at this time, Wayland does not allow for switching windows and reading window titles. That is a critical part of Auto-Type.

[MarkJaroski]

I thought the community might like to know that I'm making progress on replacing autotype for my main use case: sudo in shells:

kovidgoyal/kitty#1222 (comment)

So far of course this is dependant on kitty, the virtual termanal I've so far found most amenable to this work.

[MarkJaroski]

hargoniX/keepassxc-proxy-client#4 (comment)

[Ian2020]

There are other apps that share the same problem (reading window titles) and some are pushing for a solution e.g. ActivityWatch

This is a good issue to watch for more progress on this:
Add a portal to see currently open windows · Issue #304 · flatpak/xdg-desktop-portal · GitHub. Yes it's about flatpak but the author spoke with GNOME devs first.

Developers of the various other apps (including KeePassXC) are already included on the thread. Discussion seems active but at the moment bogged down in how new flatpak permissions for this functionality might be presented to the user.

[droidmonkey]

It's unclear to me why wayalnd cannot simply add this to their protocol and the respective compositors implement it and wrap it with security permissions like everything else. Wayland is also missing the protocol to switch to another window (active window) and the protocol to register a global shortcut. Sure these might not be what wayland was designed to do, but nothing else has stepped in to normalize the situation.

[Ian2020]

In the issue I link to above some commenters described these needs as niche so perhaps this is why it's not getting much attention, I think it's a perception problem. However I am hopeful that as there is a whole family of apps that need these features, including big ones like OBS it'll get there eventually.

[mesonium]

Regarding KDE KWin Wayland and libei + ext_foreign_toplevel_list_v1 (#2281 (comment)) protocol,

This information was provided by @GalaxySnail

Currently, we have the global keyboard shortcut portal and libei, which should be good enough for auto-type.

For enumerating windows, there is a foreign toplevel list protocol.

there's an answer to this approach (https://bugs.kde.org/show_bug.cgi?id=483227) from Xaver Hugl, one of the KWin main dev:

This sounds a lot like a workaround for missing password manager APIs. I don't think that's a good approach.

For example, a password manager API should make sure that the input actually goes into the right window - with libei you just get global input, but if some other window pops up during the "typing", it would just type into the wrong window.

Likewise I think it would be good to have an actual password manager API for apps to opt into good password store handling. Maybe it could be done similar to input methods - the trusted password manager, which is set in system settings and started by the compositor, can get and set username + password combinations, and the compositor could manually input text instead if the app doesn't support the API.

I don't really have any time to work on anything like that myself right now though