| Summary: | Support ext_foreign_toplevel_list_v1 | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | postix <postix> |
| Component: | wayland-generic | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | wishlist | CC: | nate, xaver.hugl |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
postix
2024-03-11 12:04:56 UTC
[4] https://invent.kde.org/plasma/kwin/-/merge_requests/5412 [5] https://github.com/pop-os/cosmic-comp/pull/76 (I had to split it into 2 posts as otherwise the spam detection throw a false-positive) This sounds a lot like a workaround for missing password manager APIs. I don't think that's a good approach. > I don't think that's a good approach. fair > missing password manager APIs. Could you please explain it a little bit more, how the API should/could look like? I think someone (TM) should communicate that then to KeePassXC team to work it further out. 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 Short update, there's a MR https://github.com/keepassxreboot/keepassxc/pull/10905, which states > Window detection isn't implemented, as there's no cross-platform way > to do this on Wayland currently, but could be done in the future for some platforms > (i.e. wlr-foreign-toplevel-management, KWin scripts, etc.) > As a consequence of the last point, activation of foreign windows isn't possible, > so typing occurring in the correct window relies on it being automatically activated > when the application window is deactivated (In reply to Zamundaaa from comment #4) > Likewise I think it would be good to have an actual password manager API for > apps to opt into good password store handling. You are absolutely right, the linked MR above sounds like an awful hack - utilizing a Remote Desktop Session in order to type passwords in other windows ... > I don't really have any time to work on anything like that myself right now though Too bad, some needs to shim in! :) |