admin
8f689ec479
Pasting from other applications. Neither Ctrl+V nor the middle button pasted into an ltk app anything copied in another application; only what was copied within the same process pasted. The Wayland backend bound its `wl_data_device` and its primary-selection device in `SeatHandler::new_seat`, which smithay-client-toolkit calls only for seats announced after start-up: `SeatState::new` binds the seats already in the registry without calling it, and on every compositor the seat is there when the app connects. The app therefore never had either device, the compositor never offered it another client's selection, and what it copied did not reach other applications through the compositor either. A Wayland trace of prompt shows both managers bound and neither `get_data_device` nor `get_device` sent. Both devices are now bound in `new_capability`, which comes for every seat, the first time it does; `new_seat` does nothing. The middle button and a selection just made. A compositor offers the primary selection to the window it gives the keyboard, and gives it on the press, so a middle click on a window that did not have the keyboard arrives together with the offer. ltk reads an offer on a thread of its own and pasted at once what it held, so after selecting in another application an ltk app pasted the selection before that. `Platform::primary_selection_pending` says whether another application's selection is still being read: the Wayland backend counts the reader threads it starts and the selections that arrive (`PrimarySelection::pending`), and the other backends answer `false`. A middle-button paste, into the text field under the pointer (`PrimaryPaste::Field`) or for an app that asked with `SelectionKind::Primary` (`PrimaryPaste::App`), goes through `AppData::paste_primary`, which while a read is pending keeps it in `pending_primary_paste`; `check_primary_paste`, run before every draw, makes it once the selection has arrived or after 500 ms with what there is, and `next_primary_paste_wakeup` wakes the loop every 10 ms meanwhile, since the reading thread does not. A field paste is made only if the field still has the focus. The clipboard and the primary selection in a browser desktop. On a page with forge/web, what an app copies goes to forge/web as a `set_selection` request as well as to the browser's clipboard, and the selection the middle button pastes, which did nothing in a browser, as `set_primary_selection` (`Connection::set_selection`). forge/web's `selection` and `primary_selection` events, which every client hears when one sets them and each hears on connecting, become `PageEvent::Selection` and so `AppData::clipboard` and `AppData::primary_selection`, as another client's selection does on Wayland. Copying, and selecting and pasting with the middle button, thus work between the page's applications whether or not the browser lets a page write its clipboard. A `paste` from the browser still brings what other applications of the computer copied; a browser has no primary selection a page can reach. The office icons. The default theme's word processor, spreadsheet and presentation icons came from Figma with a `foreignObject` backdrop blur that resvg ignores, and showed as flat white discs with pale glyphs. They are drawn again as the terminal's are: a dark gradient disc in each one's colour (blue, green, orange), a bright glyph and the terminal's filter. The doc comment of `ltk::files` links `write()` as a function, since `write` alone was ambiguous with the macro for rustdoc. `CHANGELOG.md` describes the changes.
3.6 KiB
3.6 KiB
