02ab10b3ef0b758311ceddcc8c11c0a36097453c
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 admin
|
8f689ec479 |
An ltk app pastes what other applications copied, the middle button pastes the selection just made, a browser desktop's applications share the clipboard and the primary selection, and the office icons are drawn like the terminal's
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. |
||
|
admin
|
312fb7e0fd |
Tooltips in a window are popups beside their widget, theme SVGs with plus-lighter highlights are no longer painted grey, and the folder-files icon is shaped as a folder
A tooltip was a layer-shell surface spanning the output, placed at the coordinates of its widget in the main surface. In a layer-shell shell the two share an origin, but an xdg-shell window does not know where it sits on screen, so in a window the tooltip appeared shifted by the window's position, wherever that put it. The application icons of the default theme, exported from Figma, light their glass with `feBlend mode="plus-lighter"`, which resvg does not know and paints as `normal`, so the highlights came out as grey edges; at dock size those edges cover whole pixels and the icon looks dirty. And `archives/folder-files`, the icon applications show for a folder, was a clipboard and a sheet rather than a folder. Tooltips. `tooltip_popup` tells when the tooltip must be an xdg-popup, that is when the main surface is a window and the widget is on it, and gives its anchor rect and logical size. `reconcile_overlays` then creates the tooltip's overlay as a popup child of the window, anchored to the widget's rect, above it with a 6 px gap (`TOOLTIP_GAP`), flipped below or slid sideways when it does not fit, so the compositor puts it beside the widget. It takes no grab and keeps the empty input region, so it never takes the pointer from the widget it describes. Its view is the pill centred in the popup. Layer-shell surfaces keep the previous placement, now in `tooltip_on_screen`. `tooltip_id` and `tooltip_size` hold the id and the estimated size both paths share. `OverlaySpec` is unchanged, so applications that build overlays need no change. Blend modes. `decode_svg_bytes` replaces `plus-lighter` with `screen`, the closest mode resvg supports, before parsing; a document without it is parsed as it comes, without a copy. A test covers both cases. The folder icon. Both variants of `archives/folder-files` are now the outline of `folder-empty` with the sheet of the previous icon inside, placed and sized as the lock of `folder-locked`: drawn in strokes in `line`, cut out of the filled folder in `filled`. |
||
|
admin
|
1db7a026c9 |
Default theme: navigation/close-small drew nothing, in either variant
Both `close-small.svg` files, `line` and `filled`, held the two diagonals of the cross as bare segments, `M785 3221L799 3235` and its mirror, painted with `fill="#000000"` and no stroke. A straight segment encloses no area, so filling it paints no pixel, and `stroke` defaults to `none`: the file is valid SVG that renders as a fully transparent image, in ltk's rasteriser and in Inkscape alike. The rest of the catalogue is drawn as closed outlines, which is what lets an icon be filled and tinted without depending on a line width; this one looks like it was exported with its strokes never converted to paths. A scan of the 432 icons of the catalogue for the same pattern, no stroke and no closed subpath, turns up no other icon with the defect. Each diagonal is now a closed shape: two parallel sides 1.5 units apart joined by a half circle at each end, the rounded ends `close.svg` has. The width is a little heavier in proportion than that icon's (2 units on a 23.6 box), since this one exists to be drawn small. The `viewBox`, each variant's own `translate` and the visual extent of the original drawing, 0.5 to 14.5, are kept: the axes are inset by the half width so the caps end where the tips of the segments were. Both diagonals are subpaths of a single path filled with the default `nonzero` rule, on purpose: the `evenodd` that `close.svg` carries would punch a hole where they overlap. `line` and `filled` share the shape, as they do for `close.svg`. The outlines use elliptical arc commands, which no other icon of the catalogue does; they were checked by rasterising both files with Inkscape. |
||
|
admin
|
bbab5e238d | First commit. Version 0.1.0 |