mirror of
https://github.com/storytold/pdfcraft.git
synced 2026-11-09 04:22:20 +00:00
85c8a2a0bf108984173fa892f91894de34909a23
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 aiongg
|
64e0868b84 |
feat(ui): menus from craft-menu, native on macOS (#4752)
* feat(ui): menus from craft-menu, native on macOS One menu definition (crates/ui-egui/src/menus.rs) built from the command registry drives the native macOS menu bar (craft-menu's muda backend) and an in-window egui bar on Windows, Linux and the web, which takes the place of the "Menu" button at the start of the top bar. - File, Edit, View, Sign, Window and Help, with separators and submenus. Edit gains Cut, Paste, Delete and Select All (they act as their keys do) and a Pages submenu; View gains a Tools submenu built from the All tools groups; Sign holds Fill & Sign and the certificate commands; Window lists the open documents. - Toggles are check items and the page layouts, side panels and themes radio items, with their state from the app. - File > Open Recent lists the recent files (file.open_recent with an index). - A menu click and its shortcut run the same dispatch, including the form-field deferral (#166) and macOS Cmd+W closing the window (#869). Dialogs and the palette grey the menus through craft-menu's gate. - Quit goes through craft-quit, so the unsaved-changes prompt runs. - craft-ui, craft-quit, craft-menu and craft-keymap pinned to storytold/craft-libs 70ade1fb. Menu state and dispatch follow #2610 by @hajdukste; the menu tree and the view and panel items follow #3870 by @RivanJarjes. * test(ui): the menu model, native dispatch and the in-window bar - Unit tests for the menu definition: every registry menu command is listed once with its registry shortcut; check and radio items follow the app; a dialog greys document commands and drops their clicks; the recent files and open documents are listed once each; a native menu click (through a fake craft-menu backend) runs its command once. - The kittests that opened the old "Menu" button use the menu bar, and the ones that look up a label the bar's titles share (Edit, File, Sign) skip the bar. - The in-window bar takes its titles' width, so the mode tabs, search and buttons keep their place in the top bar. - Edit menu clicks that stand for keys (Copy, Cut, Delete, Select All) reach this frame's input from `logic`, where test hosts see them too. * test(ui): the language switch test opens File in the menu bar Translated titles and rows carry their mnemonic ("ファイル(F)", "開く(O)…"). * feat(ui): the menu bars run Quit themselves, the bar shrinks to its titles, and AppKit's window list stays off craft-libs main edc41f6 (craft-libs#354): MenuBarUi runs Quit and Minimize, shrink_to_fit sizes the in-window bar, Key::parse reads the registry's arrow and minus glyphs, and mac::install_with(.., window_list(false)) keeps the Window menu to PdfCraft's own document list. * fix(ui): the menu command filter is an if, for clippy * test(ui): drop a needless borrow in the edit-tab helper * test(ui): two tests follow the menu bar The tests were wrong, not the app. The Preferences language test clicked the old Menu button; it opens Edit in the menu bar and its Preferences row. The prepare Actions test counted the Edit labels: the narrower menu bar leaves room for the Edit tab, so the rows' Edit buttons come third and fourth. |
||
|
aiongg
|
01b696df2c |
test(ui): CJK interface tests skip without craft-fonts (#4706)
* test(ui): CJK interface tests skip without craft-fonts * test(ui): a build that requires craft-fonts never skips the CJK interface tests |
||
  alehelandClaude Opus 5.5
|
cc4726f6e6 |
fix(ui): one page pointer per frame, so taps work and nothing over a page lets it through
The page view had no single reading of the pointer. About twenty page modules each read egui's raw state (hover_pos, latest_pos, interact_pos, press_origin) and tested it against an unclipped page rectangle. That state knows nothing of what is drawn over the pages, and hover_pos is None on the frame a finger or a Windows pen lifts: egui-winit sends PointerGone with every touch release, and winit reports Windows pen input as touch. So a tap placed no stamp, followed no link and ticked no check box. A touch drag of a comment never committed, and the next drag anywhere on the page moved the comment. The Stamp crosshair showed on the command palette, on the quick bar and on the chrome over a page scrolled under it, a link's tip floated over the Unlock prompt, and a double-click on a dialog's backdrop selected the word under it. canvas::document_area now reads one PagePointer per frame from the pages' content widget (step 1 of the page pointer router in the cursor-handling review): - pos: interact_pos, which keeps the position through a touch release, only while egui has the pages under the pointer with nothing over them (contains_pointer, and the top layer there is the pages', as the closed #2626 did) or while the pages hold a press. - origin: where the held press began, also on the frame that brings both the press and its release. This replaces the text layer's raw-event fallback (#2100). - edges: the frame's primary presses and releases on the pages, in order. It reaches the page modules through comments::PageCx and as an argument: the stamp blocks, text layer, page press and link and comment hover in canvas.rs; comments and the signature drag preview; forms and Prepare a form; Fill & Sign and the Sign area; crop, marquee zoom, snapshot, camera and measure; redact and the Link tool; added content, Edit text, images and objects. page_covered, a hand-kept list of what covers the pages that missed the Unlock prompt, is gone. The pages' hover tip is click-through, as a tooltip is, so a quick move onto it does not take the pointer off the link under it. Tests: tests/it/support/input.rs sends pointer input in the frames the platform delivers it in (a touch tap and drag, a click in one frame, a double-click). kittest otherwise runs one frame per event, so the suite never saw a touch release. tests/it/pointer.rs holds the review's probes and #2626's layer tests. With the fix reverted, the tap (stamp, link, check box), touch drag, palette, quick bar, chrome, Unlock tip and dialog double-click tests fail, and the mouse-click and one-frame-click controls pass. The tip test fails with the tip interactable, and each page_pointer unit test fails under a mutation of the part it pins. The probes for later steps stay ignored: the link hand and the I-beam over other tools' targets (step 2), paragraph edges (step 3) and Escape mid-drag (step 4). touch_tap_ticks_a_check_box is ignored until the check box focus fix that follows: since #2223 a tap on a check box counts as a click away from its focus. tests/it/comments.rs: the multiline markup hover test (#3541) hovered a point below the window on a page rotated 270 degrees, and its tip showed only because the hover was tested against the page's whole rectangle. Its harness now zooms to 100 %, so every rotation shows the whole page, and the hover helper asserts the point is on screen. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
||
 Jayesh Prajapati
|
86730ed144 |
Tests: UI tests wait for background work by time, not frame count (#4186) (#4242)
* Tests: UI tests wait for background work by time, not frame count (#4186) A frame count is not a time: on a busy runner the worker had not finished the open, or the page text had not arrived, within 30 frames or 50 hover rounds. support::step_until (#[must_use]) steps frames until a condition holds or 30 s pass, sleeping briefly between frames, and says whether it held; each test asserts on that with its own message. - control_open_replies_pending_while_the_worker_opens_and_focuses_once_it_has and mode_tabs_keep_the_hand_over_page_text_scrolled_under_them wait with it, and so does control.rs call() for its reply. - support::settle waits for every pending render and fails if the pages are not rendered within 30 s. It replaces all the render-pending settle loops (40 to 3000 frames) and the local settle/wait_for_pages wrappers, except text_select's double-click wait, which is held to 8 frames on purpose to stay inside egui's multi-click window, and view.rs's loops that already wait by a deadline. - wait_until is built on step_until, keeping its diagnostic message. - tabbing_back_to_the_same_field_then_saving_keeps_the_committed_value already waited 30 s for its file. It failed because its "same-frame" case shared its scratch directory with typing_and_saving_in_the_same_frame_saves_the_last_keystrokes, which runs in the same test process (since |
||
|
aiongg
|
9526363152 |
Build each crate's integration tests as one binary (#4087)
* Build each crate's integration tests as one binary Every tests/*.rs file is its own executable that links the whole crate graph. Move each crate's test files into tests/it/ as modules of one tests/it/main.rs, for apps/pdfcraft, apps/pdfcraft-cli, automation, cos, crypt, engine, render, sign and ui-egui. ui-egui's ui_group binary and the support modules move into tests/it/ too. Crates with a single test file keep it. The test executables go from 150 to 52, and every crate runs the same number of tests as before. ui-egui perf keeps its own binary (own process): its frame-time budgets would charge each measurement for the other tests running beside it. What the move needs: - include_str!/include_bytes! and #[path] paths gain one "../". - ui-egui: one GPU lock in tests/it/main.rs replaces the five per-file ones (content, document_links, editing, fill_sign, view), so one process creates one wgpu device at a time. The drop-line test in ui.rs and the screenshot blocks behind PDFCRAFT_*_SHOT(S) and CRAFT_UI_DOCKING_DIR, which render without holding it, take it too. - pdfcraft winit_wayland_scroll: the vendored winit source it compiles names crate::event, so that shim lives in main.rs. - parity evidence names the new paths. * Name the one-binary test paths in docs and comments - READMEs, docs, ATTRIBUTION and source comments name tests/it/<file>.rs. - The oracle README's example filters with --test it encryption::qpdf_agrees. - pdfcraft's GPU lock comment points at the UI tests' shared lock in crates/ui-egui/tests/it/main.rs. |