https://bugs.kde.org/show_bug.cgi?id=527782
--- Comment #2 from [email protected] --- (In reply to David Edmundson from comment #1) > >- add an option that only stops middle-click from pasting it (or make the > >existing setting do only that and add a separate, advanced option to remove > >the primary selection completely). > > Unfortunately that's not how it works. On middle click by convention the > application itself says "can I have your primary buffer content". We don't > do that translation. As a compositor we don't do anything on middle click. > > GTK does has a setting to disable middle click paste in gsettings, but > that's not a standard or usable anywhere else. > > You have my full support for building accessibility tools, but this idea as > presented cannot work. > > Alternatives would be openreader using the accessibility bus instead of > (ab)using the middle click paste buffer. Thanks for the quick and clear explanation, that makes sense. OpenReader actually already falls back to the accessibility bus when the primary selection is unavailable: it listens for object:text-selection-changed and reads the selection via the Text interface. That works well for GTK and Qt/KDE applications. The gap is Chromium/Electron applications (Chrome, VS Code, Discord, ...): they only enable their accessibility tree if accessibility is on when they start, and even then the web content tree seems to stay off unless a screen reader like Orca is detected. Is there a recommended way for a non-screen-reader assistive tool to get selection events from those apps, or is that something that has to be solved on the Chromium side? -- You are receiving this mail because: You are watching all bug changes.
