Make documentation standalone and generalize examples
This commit is contained in:
@@ -1,10 +1,10 @@
|
||||
import { SiGitea } from "react-icons/si"
|
||||
import { BookOpen } from "lucide-react"
|
||||
|
||||
const socialLinks = [
|
||||
{
|
||||
icon: SiGitea,
|
||||
href: "https://git.stroblme.de/Fluksio",
|
||||
label: "Gitea",
|
||||
icon: BookOpen,
|
||||
href: "https://docs.fluksio.com",
|
||||
label: "Documentation",
|
||||
},
|
||||
]
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
* Raised from anywhere through `notify()` in `lib/notificationStore`, which is
|
||||
* where the semantics live; this only draws them.
|
||||
*
|
||||
* Byte-identical with the portal's copy — see DESIGN-GUIDELINES.md § Sync rule.
|
||||
* See DESIGN-GUIDELINES.md at the repository root for notification styling.
|
||||
*/
|
||||
|
||||
import { CircleAlert, CircleCheck, Info, TriangleAlert, X } from "lucide-react"
|
||||
|
||||
@@ -2,10 +2,8 @@ import Avatar from "boring-avatars"
|
||||
|
||||
import useAuth from "@/hooks/useAuth"
|
||||
|
||||
// Shared avatar identity config, kept in step with the portal's copy
|
||||
// (index/frontend/src/components/Common/UserAvatar.tsx) so one account renders
|
||||
// the same face in both shells. The seed is the email, the only stable per-user
|
||||
// id both sides hold. These are decorative identity colours, not design tokens.
|
||||
// Email provides a stable seed for each account's avatar.
|
||||
// These are decorative identity colours, not design tokens.
|
||||
export const AVATAR_VARIANT = "marble" as const
|
||||
export const AVATAR_COLORS = [
|
||||
"#EAAC0F",
|
||||
|
||||
@@ -1,10 +1,8 @@
|
||||
/**
|
||||
* How each look moves.
|
||||
*
|
||||
* `lib/motion.ts` is the app's own set and is duplicated verbatim in the
|
||||
* website repo (`make design-check` holds the two byte-identical), so a
|
||||
* dashboard that moves differently needs its own table rather than an entry
|
||||
* there. The two looks are meant to *feel* different: material settles quickly
|
||||
* Dashboard motion has its own presets, separate from the app shell's
|
||||
* `lib/motion.ts`. The two looks are meant to *feel* different: material settles quickly
|
||||
* and squarely, glass carries a little overshoot.
|
||||
*
|
||||
* Physics only. What animates is each set's business; this is how it moves
|
||||
|
||||
@@ -10,9 +10,8 @@
|
||||
*
|
||||
* The result is written onto the canvas as the plain token variables the app
|
||||
* already themes with (`--background`, `--card`, `--primary`, …), which is the
|
||||
* same mechanism `.theme-light` and `.theme-dark` use on a subtree. Nothing here touches
|
||||
* `index.css`: that file's token blocks are byte-identical with the website's
|
||||
* and `make design-check` holds them there.
|
||||
* same mechanism `.theme-light` and `.theme-dark` use on a subtree. Palette
|
||||
* overrides leave the app's base tokens in `index.css` unchanged.
|
||||
*
|
||||
* Every value written out is a literal hex. uPlot draws on a canvas, and a
|
||||
* canvas takes neither `color-mix()` nor an unresolved custom property, so a
|
||||
|
||||
Reference in New Issue
Block a user