mirror of
https://github.com/Stirling-Tools/Stirling-PDF.git
synced 2026-09-03 05:10:16 +03:00
main
9
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
79686a3a09 |
form field editing (#6655)
# Description of Changes Building ontop of a users draft PR for form creation tools **Fill Form** becomes a full **Form Editor**: fill, create, modify and delete AcroForm fields visually. Builds on the community form-creation draft, plus a UX/UI rework pass. - **Backend**: `/api/v1/form` endpoints — `fields-with-coordinates`, `add/modify/delete-fields`, combined `edit-fields` (one round-trip), `fill`, `extract-csv/xlsx`; supports text (multiline, comb), checkbox, dropdown, list box, radio, button actions (reset/print/URL/submit) and signature placeholders - **Create**: type palette, click-or-drag placement with snap guides, inline property editor, batch "Add N fields" - **Modify**: move/resize on the page, arrow-nudge + Delete key, X/Y/W/H inputs, staged edits/deletes with chips, discard - **Fill**: live progress + required tracking, flatten toggle, Export menu (JSON/CSV/XLSX), Ctrl/Cmd+S - **Safety**: confirm dialog before discarding staged work; empty required fields warn with "Save anyway" instead of blocking - **UI**: consistent panel skeleton (fixed header / scrolling list / pinned actions), empty states that link into Create, full i18n with plural keys [walkthrough.html](https://github.com/user-attachments/files/30508976/walkthrough.html) --- ## Checklist ### General - [ ] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [ ] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (if applicable) - [ ] I have performed a self-review of my own code - [ ] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have run `task check` to verify linters, typechecks, and tests pass - [ ] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#7-testing) for more details. --------- Co-authored-by: Denys Vitali <denys@denv.it> Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> |
||
|
|
cf49742d97 |
Fix the top bar styling (#7544)
Every top bar styled itself, so none of them matched the new UI. Also, colors on the premium banner (and possibly others) clashed since the theme changes. ## Before Example Issue <img width="1934" height="348" alt="Screenshot 2026-08-17 at 11 47 20 PM" src="https://github.com/user-attachments/assets/b6f13207-2f47-4084-bd3b-2392f572c1a1" /> ## After (all) <img width="2880" height="800" alt="danger__dark" src="https://github.com/user-attachments/assets/6b311dec-23e7-4059-a6bb-75527cbd2e34" /> <img width="2880" height="800" alt="danger__light" src="https://github.com/user-attachments/assets/3b04b109-5146-4874-88b3-d99770ea51f8" /> <img width="2880" height="800" alt="default-app__dark" src="https://github.com/user-attachments/assets/b0101b98-fce8-467a-99a6-dd40b8864da1" /> <img width="2880" height="800" alt="default-app__light" src="https://github.com/user-attachments/assets/8aa21f01-6549-4d78-b217-c5547d60ab5b" /> <img width="2880" height="800" alt="free-tier-limit__dark" src="https://github.com/user-attachments/assets/07fd7498-f44f-408f-8c79-9b5ea55e13df" /> <img width="2880" height="800" alt="free-tier-limit__light" src="https://github.com/user-attachments/assets/f38c527b-9f64-4db0-b84c-56ca48e464cc" /> <img width="2880" height="800" alt="server-attention__dark" src="https://github.com/user-attachments/assets/447a36fa-056d-4ca9-8b30-04aa0ccd6ed1" /> <img width="2880" height="800" alt="server-attention__light" src="https://github.com/user-attachments/assets/f0311d45-a218-4846-b0ac-47996e2637c5" /> <img width="2880" height="800" alt="team-invitation__dark" src="https://github.com/user-attachments/assets/cc368473-3b9f-4ab0-878a-67da993874c2" /> <img width="2880" height="800" alt="team-invitation__light" src="https://github.com/user-attachments/assets/19d52a3e-4028-46f0-8562-9bd9cef9397a" /> <img width="2880" height="800" alt="upgrade-prompt__dark" src="https://github.com/user-attachments/assets/e9d20daa-f41f-46d9-b827-a84f276e8af1" /> <img width="2880" height="800" alt="upgrade-prompt__light" src="https://github.com/user-attachments/assets/9b6250c1-6a61-40d6-a7ab-e37398d67322" /> ## What changed - `InfoBanner` exposed 8 colour-override props (`background`, `borderColor`, `textColor`, `iconColor`, `buttonColor`, `buttonTextColor`, `closeIconColor`, `buttonVariant`), so every caller invented its own look. Replaced with a closed tone set: `info` · `promo` · `warning` · `danger`. - Tone drives the whole bar — fill, border, icon and the button — so a CTA can't drift from the bar it sits on. Text is neutral in every tone; only the icon carries the tone colour. - All colour comes from `--c-*` tokens mixed over `--c-surface`, so the bars follow light and dark instead of ignoring them. The old bars were hardcoded: in dark mode the two licence warnings stayed cream-on-white. - `promo` keeps the gradient it was always meant to have, built from the existing `--c-hue-indigo`/`--c-hue-purple` stops (documented in `colors.css` as gradient hues, deliberately not accent-following), with the existing `premium` button accent on it. - Deleted the hardcoded colours from all four callers: the purple gradient (`#667eea`→`#764ba2`), the orange soup (`#FFF4E6` / `#9A3412` / `#EA580C`) duplicated across the urgent banner and the admin plan section, and the fixed dark bar (`--mantine-color-dark-7`) on the team invitation. - `UpgradeBanner|AdminPlanSection` sat on the theme linter's exemption list, which is how those colours survived the theme migration. Exemption removed, so `code-colors` now guards them. - The banner's class was colliding with `core/ui/Banner.css`'s `.sui-banner` (16 live rules), which restyled it in the app but not in Storybook — that's why the two disagreed on radius, border and tone. Renamed to `.app-banner`; the two surfaces now render identically. - Bar is square and full-bleed with a single hairline rule underneath; button labels are optically centred. - Added `--c-warning-subtle`, matching the existing `--c-danger-subtle` / `--c-success-subtle`. - New `Shared → Top bars` story renders all six bars at once, so a change to the shared component is visible against the whole set. - Unrelated one-liner: `frontend/.prettierignore` now ignores the gitignored `editor/screenshots/` capture artifacts, which were failing `format:check` locally. Happy to drop it if you'd rather keep this PR to the bars. ## Testing - `task frontend:check` — typecheck, lint (oxlint + 4 theme-lint passes + stylelint), format, 244 files / 2119 tests. - `frontend:storybook:a11y:changed` — clean in light and dark. - The a11y gate caught a real defect mid-change: giving each banner `role="region"` with the same label produced duplicate landmarks, which the app hits for real whenever two banners show at once. Landmark removed. - All six bars captured in the running editor, light and dark, and diffed against `origin/main`'s component rendered with each caller's original props. |
||
|
|
dc75d399bc |
Editor url role routing (#7409)
# Description of Changes - `/` is now a router, not a page: signed-in users go to the processor or the editor by role. The editor lives at `/editor`. - `/editor` never routes — always the editor, so processor users have a URL that won't bounce them. - Core and desktop keep the editor at `/` (no processor, nothing to route between). - `/editor` signed out → `/login` → back to `/editor` after signing in. - Signed-out visitors aren't redirected: `/` renders the app and Landing owns it (login page / SaaS inline sign-in / backend-down screen). - `RootGate` wraps the app instead of being its own route, so nothing boots on the way to the processor and nothing remounts on the way to the editor. - Login resolves its own destination instead of bouncing through `/`. - Replaces the old once-per-login `LoginLandingRedirect` + sessionStorage flag. Landing flag and Settings preference unchanged. - Separate commit: theme-lint crashed on files deleted in the working tree (`git ls-files` is the index view). Any branch deleting a source file hit it. - Sign-out untouched. Tool routes stay top-level, so no deep links or SEO break. Future PR to allow users to configure their own routing from / for their profile --- ## Checklist ### General - [ ] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [ ] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (if applicable) - [ ] I have performed a self-review of my own code - [ ] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have run `task check` to verify linters, typechecks, and tests pass - [ ] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#7-testing) for more details. |
||
|
|
7bf18cc4c7 |
Storybook: render off the app's real theme CSS, stop hardcoding story colours, and gate a11y in dark mode too (#7187)
## What Makes Storybook render components with the same CSS the app gives them. - The preview loaded the token primitives but **not the editor's semantic token layer** (`styles/theme.css`), so components styled on those variables rendered unthemed — three onboarding stories were importing it by hand to stop their modal surfaces rendering transparent. It's now loaded in the preview and the workarounds are gone. - **Portal stories render inside the `.portal-scope` wrapper** PortalApp mounts, so the portal's scoped reset and typography apply to them exactly as in the app — and, deliberately, to nothing else. - The folder stories invented their own hex colours, two of which aren't values the app's `FOLDER_COLOR_PALETTE` can produce. They now use the palette, so they can't drift from what a user can actually pick. Deliberately does **not** load `tailwind.css` — tailwind is on its way out of the editor, so matching the token layer alone is the target state. ## Story colours route through the tokens, enforced Stories were exempt from the `code-colors` lint, and it showed: hardcoded hexes for surfaces the tokens already name (chat bubbles, borders, demo backgrounds), `var(--x, #hex)` fallbacks that mask a renamed token by silently painting the stale colour, and mocked category accents for which real `--color-cat-*` tokens exist. - Styling literals now use tokens; the dead fallbacks are stripped. - The stories exemption is removed from `theme-lint`, so this can't regress. - Colours that are **the datum itself** — `ColorInput` values, signature ink, per-policy accents, brand-mark swatches — stay literal via `theme-allow-color`, hoisted to named consts so the exemption and its reason sit together. A practical side effect: stories styled on tokens actually respond to the dark-mode toolbar toggle, which is what makes a dark-theme a11y pass meaningful later. ## The a11y gate now runs dark as well as light Contrast is most of what axe reports and it is theme-dependent, so a light-only gate left half the surface unmeasured — and it only becomes measurable at all once the tokens above actually flip. `SCAN_THEME=dark` pins the theme for a whole scan run, every a11y task runs both themes, and each theme has its own baseline: - **light** re-recorded against the themed rendering (the old baseline measured colours the app never shows): 831 stories with violations - **dark** recorded for the first time: 798 stories with violations, 980 story-rule pairs, zero render failures across the full sweep Verified end to end: dark scans measure against dark surfaces (`#18181b` vs `#ffffff`), both baselines self-check clean, and a live scan of stories that changed on main after recording passes both gates. Nightly's timeout doubles for the second sweep. ## Testing Typecheck (all variants), ESLint and Prettier pass. Onboarding, folder, portal and control stories render in the browser scan (39/39) with the per-story CSS imports removed; every story touched by the colour sweep renders too (58/58). `task frontend:lint:colors` passes with stories included. |
||
|
|
d7c130fca9 |
Serve SPA shell for deep frontend routes (#7145)
# Description of Changes stops the /new urls crashing page on f5 --- ## Checklist ### General - [ ] I have read the [Contribution Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md) - [ ] I have read the [Stirling-PDF Developer Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md) (if applicable) - [ ] I have read the [How to add new languages to Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md) (if applicable) - [ ] I have performed a self-review of my own code - [ ] My changes generate no new warnings ### Documentation - [ ] I have updated relevant docs on [Stirling-PDF's doc repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/) (if functionality has heavily changed) - [ ] I have read the section [Add New Translation Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags) (for new translation tags only) ### Translations (if applicable) - [ ] I ran [`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md) ### UI Changes (if applicable) - [ ] Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR) ### Testing (if applicable) - [ ] I have run `task check` to verify linters, typechecks, and tests pass - [ ] I have tested my changes locally. Refer to the [Testing Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#7-testing) for more details. --------- Co-authored-by: Reece Browne <74901996+reecebrowne@users.noreply.github.com> |
||
|
|
c91d63f215 |
New design, part one: shared branding, nav surfaces and theme tokens (#7163)
## Overview First part of the move over to the new designs. This lays the groundwork (shared brand components, button/nav styling, theme tokens) and applies it across the editor and the processor. Later parts will build on top of it. ## What's changed **Branding** - Shared `Logo` and `BrandMark` components used everywhere, so the mark and wordmark are identical across the editor, processor, auth pages and the chat FAB. - The sidebar logo doubles as the editor to processor switcher, morphing into a chevron on hover. It only appears for users who can actually reach the processor. **Navigation and layout** - Both sidebars restructured onto the floating nav surface treatment, with rounded panels sitting on the app canvas. - The editor file sidebar is now three sections (controls, PDF Library, settings) and the workbench top bar and tools panel match. - Added a collapse toggle to both sidebars, with an animated expand and collapse and a tidy icon rail when collapsed. The processor did not have a desktop collapse before. **Components** - Buttons and action icons now share one styling system, so both react to the same tokens. - Secondary buttons in dark mode use a neutral fill and border instead of inheriting the primary colour. - Status badges default to a clean dot with no background, with a filled pill as the alternative. - Metric strips gained a row layout with an optional leading icon. **Theme** - Colour tokens consolidated. Literal colours live only in the palette file, everything else references the semantic `--c-*` tokens. - `saas-theme.css` removed and the parts that were genuinely needed moved into the shared theme, so all builds get them. - The colour linter enforces this across the app and runs in CI. ## Notes - Nothing functional should change here, it is styling plus the sidebar collapse feature. - Main has been merged in. The Sources and billing pages picked up changes from main during that merge and are worth a look alongside the new styling. --------- Co-authored-by: Reece Browne <74901996+reecebrowne@users.noreply.github.com> |
||
|
|
1681b5d298 | Source and connections changes to integrations (#7068) | ||
|
|
67e10138b5 |
Follow-up: colour token migration (compat → --c-*, hardcoded hex) (#7011)
Follow-up to #7009, which built the theme token layer (`primitives` → `colors` → `compat`). This PR moves the whole app onto it, removes hardcoded colours, turns on enforcement so they can't come back, and adds a user-selectable accent. ## What this does - **Semantic tokens everywhere** — legacy colour aliases and raw hex are rewritten to `--c-*` tokens (`--c-surface*`, `--c-text*`, `--c-primary`, …). Straight rename, no visual change. Genuine literals (brand/OAuth, colour pickers, data-viz) are left as-is. - **Fixes missing colours** — some tokens the migration referenced were never defined, so a few surfaces (login button, auth banners, badges, procurement view) silently lost their colour. All defined now, and they adapt to light/dark and the accent automatically. - **Blocking colour lint** — CI now fails on hardcoded colours, undefined tokens, or unreadable low-contrast status colours. - **User-selectable accent** — light and dark each get their own accent from Settings → Appearance, contrast-clamped so text stays legible. "Default" keeps the standard blue. ## Still to come Remaining inline-style hex, the legacy token-definition files (`theme.css`, `tokens.css`), and folding `zIndex.ts` onto the dimension tokens. ## Testing `task frontend:check:all` green; light/dark and accent switching spot-checked. |
||
|
|
b86e963c9d |
initial colors and theme improvements (#7009)
## What this does Consolidates the frontend's colour/theme system into a small, well-defined token layer and reworks the theme picker. The goal was a minimal, scalable set of semantic tokens that the editor **and** the Processor/portal (and Storybook) all share, plus a theme model that's easy to reason about. ## Token architecture (`core/theme/`) A four-file layer, imported once via `index.css`: | File | Role | |---|---| | `primitives.css` | The raw palette — the **only** place literal colours live (neutral ramps `--p-gray-*`/`--p-zinc-*` + status hues). | | `colors.css` | ~21 semantic `--c-*` tokens (surfaces, text, borders, primary, status) mapped from primitives per theme. **Reference these.** | | `compat.css` | Legacy names (`--bg-*`, `--text-*`, `--color-*`) aliased onto `--c-*` via `:root:root` so ~200 existing files keep working. | | `dimensions.css` | All non-colour tokens (spacing, radius, z-index, type, motion) — single source, resolving prior collisions. | A blocking linter (`scripts/lint/theme-lint.mjs`, run in `frontend:lint`) enforces "literals only in `primitives.css`" within `core/theme/`, and has a non-blocking WCAG contrast report. See `core/theme/README.md`. ## Theme model - **Mode** (`light` / `dark` / `system`) and **accent** are independent. Each mode has its own accent (`lightPrimary` / `darkPrimary`). - The editor is always `data-app-theme="custom"`; `ThemeProvider` injects the accent as `--user-primary` and sets `data-accent`. - **Two accent states:** - A **colour** (preset or custom hex) → tints every surface that hue (whole-app theming). - The **`default`** sentinel → neutral surfaces (white/grey light, zinc black/grey dark) with blue buttons, no tint. (`data-accent="default"` opts surfaces out of the tint.) - Accent contrast guardrails (`utils/customPrimary.ts`): lightness clamps so an accent can't collapse into the base, a contrast-picked on-primary foreground, and an accent-as-foreground variant so accent text is never dark-on-dark. ## Theme picker (Settings → General) - 3×5 grid: a distinct **Default** icon chip (not a colour) + 14 curated accents, in a dropdown per mode. - **Custom** colour via the shared `ColorInput`, with a live gamut clamp (`clampValue`) that refuses white/grey/black — the picker handle sticks at the boundary and preserves the working hue at achromatic extremes. - "Restore theme to default" resets both modes. ## Other - Dark mode is a true neutral zinc (no navy "midnight" tint); the Mantine dark ramp and Tailwind dark channels were neutralised to match. - Pre-paint inline script in `index.html` applies theme + accent before first paint (no FOUC); portal and editor now share the same `preferences.theme` source of truth. - High-visibility surfaces migrated to tokens (FAB, landing upload buttons, portal hero banners); scattered per-component colour swaps were intentionally **left for a follow-up** to keep this PR focused. ## Testing - `task frontend:check:all` (typecheck all variants + eslint + prettier + colour-lint) green. - Verified light/dark, default vs tinted accents, and the custom clamp via computed styles in the dev preview. > Note: the `prerender-og` build step failing in the e2e/deploy jobs is unrelated to this diff — it's in `vite.config.ts` (untouched here) and builds cleanly locally. |