Repository navigation
Releases
v0.3.9
v0.3.8
v0.3.7
v0.3.6
v0.3.5
v0.3.4
v0.3.3
What's Changed
- Start and stop the Loader from the static logo by @dauglyon in #35
- Make composed triggers work on React 18, and let a tooltip say what it is by @dauglyon in #34
- Compile the component CSS into the pip package by @dauglyon in #36
- Ship Loader's stop, and size Chip's icon from its text by @dauglyon in #37
- Compute the palette in Python, and say what migrating onto the components requires by @dauglyon in #38
- Rewrite solara/MIGRATING.md as an executable migration procedure by @dauglyon in #39
- Solara-bridge gaps a full portal migration surfaced by @dauglyon in #40
- Finish the Solara button mounts, and let a pophost say which side it opens by @dauglyon in #41
- ds-v0.9.3: theme.skin() and theme.tokens(), every weight a token, tests against the wheel by @dauglyon in #42
- Links from --c-link, apart from the primary; MIGRATING §2 lookup is one variable by @dauglyon in #43
Full Changelog: v0.3.2...v0.3.3
Design system v0.9.4
One change since ds-v0.9.3 (#43): links keep KBase's blue when a skin moves the primary, and MIGRATING.md §2 no longer names a fleet-wide skin variable. No React component API changes; the Button and Collapsible sheets change colour only. Portals pinning ds-v0.9.3 upgrade to drop their own link overrides and any KBASE_SKIN fallback.
--c-link, held apart from --c-primary. Every rule drawn as link text took --ct-primary, so a skin that moved the primary moved link colour with it — purple links under a purple portal, which read as visited. tokens.css states --c-link: #007dc3 beside the semantic colours and derives --ct-link the way --ct-primary is derived, so it meets the same contrast on both schemes. The five link-text rules — .link, .prose a, .solara-markdown a, the link Button and the Collapsible trigger — take it; theme.tokens() returns c-link and ct-link. The code-block trigger stays ink and the breadcrumb hover stays the un-underlined accent; both keep the brand. A portal that carried a link-colour block in its skin sheet removes it on upgrade.
MIGRATING.md §2: the skin lookup is one variable, the portal's own. The guide told a portal to read KBASE_SKIN after its own <APP>_SKIN. Nothing in KIND, king or a pod sets one, and a portal reading it claims a shared selection layer that was never built. The example reads only PORTAL_SKIN; a portal that carries the fallback drops it.
Tests: 47 against the installed wheel (pip install '.[dev]', pytest tests), two new — --ct-link holds when the primary moves, and each of the five link rules names --ct-link and not --ct-primary, read from the built sheets.
Design system v0.9.3
Three additions since ds-v0.9.2 (#42): the Solara adapter resolves a skin and a palette, every packaged weight is a token, and the Python side has tests. No React component changes. Portals pinning ds-v0.9.2 upgrade for the resolvers and the guide; each portal's migration PR moves its skin lookup onto theme.skin() and converts its own weight literals.
theme.skin(resources, default, requested) takes the value of a portal's skin setting and returns a Skin holding the name and text of the stylesheet it names. The lookup that produces the value is the portal's — <APP>_SKIN else KBASE_SKIN today — and the package reads no environment. none selects nothing and the text is ""; None or blank selects the portal's declared default; a bare name reads resources/<name>.css from the portal's package; a path is read from disk on every call. A name with no file falls to the default rather than refusing the page, and Skin.note carries the reason for the portal's doctor to print.
theme.tokens(skin_css, scheme) resolves every opaque colour token to hex for one scheme, with a skin's overrides carried through the oklch(from var(--x) …) derivations, for code that draws outside the page's CSS: a plot rendered on the server, an SVG in a sandboxed iframe. The four translucent tokens are omitted: each carries an alpha, so it has no single hex until it is drawn over something. theme.vuetify() reads the same table and returns what ds-v0.9.2's did.
The sheets. Every font-weight is var(--fw-normal) or var(--fw-bold); only 400 and 700 are loaded, so the literal 600s rendered as 700 and the token states the weight that rendered. Fira Code's import loads 400;700 — ds-v0.9.2 loaded 400;500, so the browser had no bold face for code and synthesised one. --w-page: 1180px is the portals gallery's column. .v-btn.kb-row is square: the named-class reset's border-radius: inherit had handed a row inside a flush Frame the Frame's radius. prose.css gives h5 and h6 fallbacks — h5 at --fs-4, h6 the same in --c-ink3 — where they had rendered at h4's size; the utilities stay .h1–.h4.
Tests run against an install (pip install '.[dev]', pytest), because the name they import, kbase_design_system, exists only in one; the wheel job installs the wheel it just built and runs them. theme.tokens() agrees with Chromium within one unit per channel for all 59 tokens in both schemes.
solara/MIGRATING.md §2 requires the dependency in [project.dependencies] from the first migration PR; the optional extra, its guard and the stop-line PR are gone. A portal serves three kinds of look through its skin setting — none, a kbase sheet that sets only the portal's gallery colour, and any number of brands — and a new invariant puts a literal weight beside a literal hex. §9's matrix is none × every shipped skin × light and dark, for every PR, and the PR body opens with whatever the PR leaves outstanding.
Design system v0.9.2
Two changes since ds-v0.9.1, both from migrating a third Solara portal onto the components (#40, #41). No React component changes beyond one new Avatar colour; portals pinning ds-v0.9.1 upgrade for the Solara bridge and the guide.
solara/vuetify.css finishes the button mounts. A Python framework cannot mount a React component, so a portal puts the component's class on the widget Solara does render, and the named-class reset hands that class the box. Seven classes are named now: .kb-accordion--trigger and .kb-tree--label join, so a trigger and a tree row stop carrying Vuetify's 36px height floor, 64px min-width, Material radius and ripple. What the reset erases is given back in the same file — the segment's radius (it starts from all: unset and has none of its own; the control holds the radius and clips), and :focus-visible for the two named classes with no rule in their own module, a trail step and a tree label. Both are anatomies rather than labels when mounted as buttons, so their content spans the button and starts at the left.
New pairings and one pattern. A fold built on <details> turns its chevron from the element's own open attribute, since nothing sets data-panel-open without JS state. .kb-pophost is the hover-shown popup two portals had each hand-rolled around the packaged Popover and Tooltip boxes: the host anchors, the packaged box paints. It opens below the host, .kb-pophost--left opens it beside, and --pophost-width sets the width — the positioner picks a side from the room available and a stylesheet cannot measure, so the side is the host's to declare.
Avatar takes neutral, the colour a data-type marker wears when its colour means nothing — Chip's neutral, as an avatar.
solara/MIGRATING.md gains what the third migration paid to learn: ipyvuetify>=3 belongs beside the pin (an environment already holding 1.x satisfies Solara's own pin and renders Vuetify 2 markup no packaged rule matches — dark mode, fields and buttons all fail, each looking like a portal bug); the two step-2 identity traps; that an emoji's family hue survives conversion to a glyph; that a portal caching rendered HTML hides its own migration until the cache version moves; the unmount-loader exit; and a full-page screenshot that stops at one viewport because Solara scrolls its own div (Appendix 10).