@gjsify/adwaita-core 0.31.0 → 0.33.0

package/lib/types/chrome.d.ts

@@ -0,0 +1,355 @@
+/**
+ * The inputs every clamp computation needs: the two properties plus the child's
+ * measured minimum and natural size in the clamp's own orientation.
+ *
+ * Sizes are already-resolved PIXELS. `AdwClampLayout:unit` (default `sp`) scales
+ * them against the GTK text-scale factor, which is a platform capability rather
+ * than headless logic — a renderer that has one runs `adwLengthToPx` (exported
+ * from `./split-view.js`) before calling in.
+ */
+export interface ClampParams {
+    /** `maximum-size` — how wide the child may get. Default 600. */
+    maximumSize: number;
+    /** `tightening-threshold` — where the eased tightening starts. Default 400. */
+    tighteningThreshold: number;
+    /** The child's measured minimum in the clamped orientation. */
+    childMin: number;
+    /** The child's measured natural size in the clamped orientation. */
+    childNat: number;
+}
+/** The libadwaita property defaults (adw-clamp-layout.c:414, :438, :462-464). */
+export declare const ADW_CLAMP_DEFAULTS: {
+    readonly maximumSize: number;
+    readonly tighteningThreshold: number;
+};
+/** The three breakpoints every other clamp computation is written in terms of. */
+export interface ClampThresholds {
+    /** Below this the child gets ALL the available size — `MAX(MIN(threshold, maximum), childMin)`. */
+    lower: number;
+    /** The largest size the child will ever be allocated — `MAX(lower, maximum)`. */
+    max: number;
+    /** The available size at which the child finally reaches {@link max}. */
+    upper: number;
+}
+/**
+ * `lower`/`max`/`upper` (adw-clamp-layout.c:173-176, :210-213).
+ *
+ * Exported because both the measure and the allocate path need them, and
+ * because the two cases the renderers got wrong live entirely in these three
+ * lines: a threshold ABOVE the maximum collapses the tightening region
+ * (`lower === max === upper`), and a child whose own minimum exceeds the maximum
+ * raises all three to that minimum — which is how `maximum-size="0"` means "give
+ * the child its minimum", not "give it nothing".
+ */
+export declare function clampThresholds(params: ClampParams): ClampThresholds;
+/**
+ * `child_size_from_clamp` (adw-clamp-layout.c:193-232) — how much of `forSize`
+ * the child is allocated.
+ *
+ * The result is never larger than `forSize`, which is the whole point and what
+ * `view.width = maximumSize` in the NativeScript port broke: below `lower` the
+ * child gets EXACTLY the available size, so a narrow phone gets a narrow child.
+ * The cap only bites from `upper` upward; between the two the size is eased so
+ * the transition into the cap is smooth rather than a corner.
+ */
+export declare function clampChildSize(forSize: number, params: ClampParams): number;
+/**
+ * `clamp_size_from_child` (adw-clamp-layout.c:156-191) — the INVERSE, used while
+ * measuring: how much space the clamp itself must report for the child to end up
+ * at `childSize`.
+ *
+ * The inverse of `ease_out_cubic` is `1 + cbrt(t - 1)`, and the rounding goes the
+ * OTHER way from {@link clampChildSize} (`ceil`, not `floor`) so the reported
+ * request never lands a pixel short of what the child asked for.
+ */
+export declare function clampSizeFromChild(childSize: number, params: ClampParams): number;
+/** Which of the three size classes `adw_clamp_layout_allocate` stamps on the child. */
+export type AdwClampSizeClass = 'small' | 'medium' | 'large';
+/**
+ * All three size classes, so a renderer can CLEAR the ones that no longer apply.
+ *
+ * `adw_clamp_layout_allocate` removes the other two on every pass and removes
+ * all three from a child it stops laying out (adw-clamp-layout.c:333-336), so
+ * "which classes does the clamp own" is part of the contract, not a detail each
+ * renderer gets to restate.
+ */
+export declare const ADW_CLAMP_SIZE_CLASSES: ReadonlyArray<AdwClampSizeClass>;
+/** Everything one clamp allocation decides. */
+export interface ClampAllocation {
+    /** The size the child is allocated along the clamped axis. */
+    childSize: number;
+    /** `ceil(max)` — the cap the `large` class is keyed off. */
+    childMaximum: number;
+    /** `ceil(lower)` — the threshold the `small` class is keyed off. */
+    lowerThreshold: number;
+    /** The style class the CHILD must carry. */
+    sizeClass: AdwClampSizeClass;
+    /** Leading offset that centres the child along the clamped axis. */
+    offset: number;
+}
+/**
+ * `adw_clamp_layout_allocate` (adw-clamp-layout.c:317-386) — child size, the
+ * style class the child carries, and the centring offset, in one call.
+ *
+ * The class boundaries are INCLUSIVE at both ends and are compared against the
+ * CEILED thresholds, not the raw doubles; the offset is C integer division, so
+ * it truncates rather than rounds.
+ */
+export declare function clampAllocate(availableSize: number, params: ClampParams): ClampAllocation;
+/**
+ * Normalise a `maximum-size` / `tightening-threshold` coming from an attribute
+ * or a property assignment into the `g_param_spec_int (…, 0, G_MAXINT, …)` range
+ * both properties declare (adw-clamp-layout.c:413-416, :448-451).
+ *
+ * Three inputs used to produce three different results across the three
+ * implementations, and this is the one answer for all of them:
+ *   - `0` is IN RANGE and means "clamp the child to its own minimum". The web
+ *     port's `attr || '600'` never fired for the string `"0"` and produced
+ *     `max-width: 0`; the NS port's `value > 0` guard silently substituted 600.
+ *   - a value GObject would refuse (`NaN`, a non-numeric attribute) never
+ *     reaches the layout, so the property keeps its DEFAULT. The web port
+ *     assigned `NaNpx`, which the CSSOM drops — leaving whatever cap was set
+ *     before silently in force.
+ *   - a negative is out of range and clamps to the range floor, 0.
+ */
+export declare function normalizeClampSize(value: number | string | null | undefined, fallback: number): number;
+/** `AdwToolbarStyle` (adw-toolbar-view.c:120-125). */
+export type AdwToolbarStyle = 'flat' | 'raised' | 'raised-border';
+/** The toolbar-view property defaults (adw-toolbar-view.c:572, :608, :731-732). */
+export declare const ADW_TOOLBAR_VIEW_DEFAULTS: {
+    readonly topBarStyle: AdwToolbarStyle;
+    readonly bottomBarStyle: AdwToolbarStyle;
+    readonly extendContentToTopEdge: boolean;
+    readonly extendContentToBottomEdge: boolean;
+};
+/**
+ * Read an `AdwToolbarStyle` off an attribute or a property assignment.
+ *
+ * Anything outside the enum is the default: C rejects it outright
+ * (`g_return_if_fail (style <= ADW_TOOLBAR_RAISED_BORDER)`,
+ * adw-toolbar-view.c:1004) and leaves the property at whatever it was.
+ */
+export declare function parseToolbarStyle(value: string | null | undefined): AdwToolbarStyle;
+/**
+ * The style classes a bar box carries for `style`
+ * (adw-toolbar-view.c:1011-1024, :1097-1110).
+ *
+ * `raised-border` is `raised` PLUS `border` — the border replaces the shadow in
+ * the stylesheet, it does not replace the raised background.
+ */
+export declare function toolbarBarStyleClasses(style: AdwToolbarStyle): string[];
+/** Everything `update_undershoots` + the two style setters need to decide the classes. */
+export interface ToolbarViewClassInput {
+    /** `top-bar-style`. */
+    topBarStyle: AdwToolbarStyle;
+    /** `bottom-bar-style`. */
+    bottomBarStyle: AdwToolbarStyle;
+    /** `extend-content-to-top-edge`. */
+    extendContentToTopEdge: boolean;
+    /** `extend-content-to-bottom-edge`. */
+    extendContentToBottomEdge: boolean;
+    /** The ALLOCATED top-bar height, i.e. `Adw.ToolbarView:top-bar-height`. */
+    topBarHeight: number;
+    /** The ALLOCATED bottom-bar height, i.e. `Adw.ToolbarView:bottom-bar-height`. */
+    bottomBarHeight: number;
+}
+/** The classes a toolbar view owns on ITSELF, so a renderer can clear them. */
+export declare const ADW_TOOLBAR_VIEW_CLASSES: ReadonlyArray<string>;
+/** The classes a toolbar view owns on each BAR BOX, so a renderer can clear them. */
+export declare const ADW_TOOLBAR_BAR_CLASSES: ReadonlyArray<string>;
+/** The three class lists a toolbar view distributes over its own node and its two bar boxes. */
+export interface ToolbarViewClasses {
+    /** Classes on the VIEW — `undershoot-top` / `undershoot-bottom`. */
+    view: string[];
+    /** Classes on the top-bar box. */
+    topBar: string[];
+    /** Classes on the bottom-bar box. */
+    bottomBar: string[];
+}
+/**
+ * `update_undershoots` (adw-toolbar-view.c:215-232) plus the two per-bar style
+ * class setters, as one derivation.
+ *
+ * An undershoot is the scroll-fade under a FLAT bar, so all three conditions
+ * must hold: the bar is flat (a raised bar has its own shadow), the content does
+ * NOT extend under it (there is nothing to fade), and the bar was actually
+ * allocated a height (an absent bar fades nothing). The height being the
+ * ALLOCATED one — not "is there a bar widget" — is why this reads a number.
+ */
+export declare function toolbarViewClasses(input: ToolbarViewClassInput): ToolbarViewClasses;
+/** The measured sizes one toolbar-view allocation consumes. */
+export interface ToolbarViewAllocateInput {
+    /** The height the view itself was allocated. */
+    height: number;
+    /** Top bar minimum height. */
+    topMin: number;
+    /** Top bar natural height. */
+    topNat: number;
+    /** Bottom bar minimum height. */
+    bottomMin: number;
+    /** Bottom bar natural height. */
+    bottomNat: number;
+    /** Content minimum height. `0` when there is no content. */
+    contentMin: number;
+    /** `extend-content-to-top-edge`. */
+    extendContentToTopEdge: boolean;
+    /** `extend-content-to-bottom-edge`. */
+    extendContentToBottomEdge: boolean;
+}
+/** What one toolbar-view allocation produces. */
+export interface ToolbarViewAllocation {
+    /** `Adw.ToolbarView:top-bar-height`. */
+    topBarHeight: number;
+    /** `Adw.ToolbarView:bottom-bar-height`. */
+    bottomBarHeight: number;
+    /** The height the content is allocated. */
+    contentHeight: number;
+    /** The content's vertical offset from the view's top edge. */
+    contentOffset: number;
+}
+/**
+ * `adw_toolbar_view_size_allocate` (adw-toolbar-view.c:357-406) — the two chained
+ * GLib CLAMPs that turn measured sizes into the three slot heights.
+ *
+ * Read it as: reserve the content's minimum and the bottom bar's minimum, hand
+ * what is left to the top bar (clamped into its own min…nat), then repeat for the
+ * bottom bar with the top bar's ACTUAL height. Two consequences a naive
+ * "stack them" layout does not reproduce:
+ *   - a STRETCHY bar (`nat > min`) grows into spare height and shrinks back
+ *     toward its minimum as the content's minimum claims the space;
+ *   - once the view is squeezed below everything's minimum, GLib's `CLAMP` — which
+ *     tests the HIGH bound first — leaves the BARS at their minimum and lets the
+ *     CONTENT go short. `Math.min(high, Math.max(low, x))` gives the same answer
+ *     here only because both bounds arrive in order; the primitive is
+ *     {@link glibClamp} regardless, since the inputs are caller-supplied.
+ */
+export declare function toolbarViewAllocate(input: ToolbarViewAllocateInput): ToolbarViewAllocation;
+/** The measured sizes one toolbar-view measure consumes. */
+export interface ToolbarViewMeasureInput {
+    /** Which axis is being measured. */
+    orientation: 'horizontal' | 'vertical';
+    /** Top bar minimum along {@link orientation}. */
+    topMin: number;
+    /** Top bar natural along {@link orientation}. */
+    topNat: number;
+    /** Bottom bar minimum along {@link orientation}. */
+    bottomMin: number;
+    /** Bottom bar natural along {@link orientation}. */
+    bottomNat: number;
+    /** Content minimum along {@link orientation}. `0` when there is no content. */
+    contentMin: number;
+    /** Content natural along {@link orientation}. `0` when there is no content. */
+    contentNat: number;
+    /** `extend-content-to-top-edge`. */
+    extendContentToTopEdge: boolean;
+    /** `extend-content-to-bottom-edge`. */
+    extendContentToBottomEdge: boolean;
+}
+/** A GTK measure result. */
+export interface AdwMeasurement {
+    /** Minimum size along the measured axis. */
+    minimum: number;
+    /** Natural size along the measured axis. */
+    natural: number;
+}
+/**
+ * `adw_toolbar_view_measure` (adw-toolbar-view.c:266-354) — the four-way vertical
+ * combination keyed on the two extend flags, plus the horizontal MAX form.
+ *
+ * The four branches are not four spellings of the same sum: a bar the content
+ * extends UNDER contributes via `MAX`, a bar it does not contributes via `+`.
+ * With both flags set the two bars are summed first and MAXed as a pair, because
+ * they still cannot overlap each other.
+ */
+export declare function toolbarViewMeasure(input: ToolbarViewMeasureInput): AdwMeasurement;
+/** The bar heights subtracted before the content is measured horizontally. */
+export interface ToolbarViewContentForSizeInput {
+    /** `extend-content-to-top-edge`. */
+    extendContentToTopEdge: boolean;
+    /** `extend-content-to-bottom-edge`. */
+    extendContentToBottomEdge: boolean;
+    /** Top bar minimum HEIGHT (always the vertical measurement, whatever axis is being measured). */
+    topMinHeight: number;
+    /** Top bar natural HEIGHT. */
+    topNatHeight: number;
+    /** Bottom bar minimum HEIGHT. */
+    bottomMinHeight: number;
+    /** Bottom bar natural HEIGHT. */
+    bottomNatHeight: number;
+}
+/** The two heights the content has to be measured against. */
+export interface ToolbarViewContentForSize {
+    /** `for_size` for the content's MINIMUM — bars at their minimum heights. */
+    forSizeMin: number;
+    /** `for_size` for the content's NATURAL — bars at their natural heights. */
+    forSizeNat: number;
+}
+/**
+ * `adw_toolbar_view_measure`'s height-for-width branch (adw-toolbar-view.c:292-316).
+ *
+ * Two different `for_size` values, not one: a STRETCHY bar leaves the content a
+ * different width at the bar's minimum than at its natural size, so the content's
+ * minimum and natural have to be measured against different heights. They
+ * coincide exactly when every bar is rigid, which is why one value looked
+ * sufficient for as long as nobody had a stretchy bar.
+ */
+export declare function toolbarViewContentForSize(forSize: number, input: ToolbarViewContentForSizeInput): ToolbarViewContentForSize;
+/**
+ * `MIN_SIZE` (adw-spinner.c:14) — reported as BOTH the minimum and the natural
+ * size (adw_spinner_measure, :70-84), so a spinner never grows on its own; it
+ * only fills an allocation something else made larger.
+ */
+export declare const ADW_SPINNER_MIN_SIZE = 16;
+/**
+ * The largest ring Adwaita ever draws: `2 * MAX_RADIUS`
+ * (adw-spinner-paintable.c:19). Together with {@link ADW_SPINNER_MIN_SIZE} this
+ * is the documented "never smaller than 16×16 and never larger than 64×64"
+ * (adw-spinner.c:27-28).
+ */
+export declare const ADW_SPINNER_MAX_SIZE = 64;
+/** The circle `AdwSpinnerPaintable` strokes into a `width × height` box. */
+export interface SpinnerGeometry {
+    /** Ring radius, capped at `ADW_SPINNER_MAX_SIZE / 2`. */
+    radius: number;
+    /** Drawn diameter, `2 * radius`. */
+    diameter: number;
+    /** Stroke width — `diameter / 8`, the documented "2px for 16px". */
+    lineWidth: number;
+    /** Ring centre X within the box. */
+    centerX: number;
+    /** Ring centre Y within the box. */
+    centerY: number;
+}
+/**
+ * `adw_spinner_paintable_snapshot_with_weight` (adw-spinner-paintable.c:342-352)
+ * plus `calculate_line_width` (:314-321) at the default weight 400, where
+ * `width_apply_weight` is the identity branch (:303-306).
+ *
+ * Three details the renderers had each guessed at:
+ *   - the SHORTER side decides the radius, and it is FLOORED, so a 31px box
+ *     draws a 30px ring rather than a 31px one;
+ *   - the radius is capped at 32 while the CENTRE still follows the box, so a
+ *     200px allocation shows a 64px ring in the middle, not a 200px one;
+ *   - the stroke is `diameter / 8` exactly — 3px at 24, 6px at 48, 8px at 64.
+ *     The browser port's `max(2, round(size / 12))` drew 2px, 4px and 5px there.
+ *
+ * `MIN_RADIUS 8` (adw-spinner-paintable.c:18) is dead in the C source — nothing
+ * references it — so it is deliberately NOT a floor here. The real floor is the
+ * widget's measured {@link ADW_SPINNER_MIN_SIZE}.
+ */
+export declare function spinnerGeometry(width: number, height: number): SpinnerGeometry;
+/**
+ * The box a spinner is actually given for a requested `size`.
+ *
+ * `adw_spinner_measure` reports 16 as the minimum, and GTK never allocates a
+ * widget below its minimum — so a smaller request is not representable, and a
+ * request GObject would refuse (`NaN`, a non-numeric attribute, an unset one)
+ * leaves the natural size in force. There is no upper bound HERE: an oversized
+ * allocation stays oversized and {@link spinnerGeometry} caps the drawn ring,
+ * which is how the box and the ring can differ (a 200px allocation, a 64px ring).
+ *
+ * Replaces the two invented defaults this package shipped — `24` in the browser
+ * element and `32` in the NativeScript widget — neither of which is in the C
+ * source.
+ */
+export declare function resolveSpinnerSize(value: number | string | null | undefined): number;

package/lib/types/chrome.spec.d.ts

@@ -0,0 +1,2 @@
+declare const _default: () => Promise<void>;
+export default _default;

package/lib/types/conformance/about-dialog.d.ts

@@ -0,0 +1,314 @@
+/** One `parse_person` expectation. */
+export interface CreditPersonVector {
+    /** The raw credit line, as an app puts it in `developers` etc. */
+    input: string;
+    /** `*name` after `g_strstrip` (:520, :528, :533). */
+    name: string;
+    /** `*link` — `null` is "no link", `''` is an EMPTY link and still a link. */
+    link: string | null;
+    /** `*is_email`, i.e. `*q1 == '<'` (:521). */
+    isEmail: boolean;
+    /** The URI the row gets (`add_credits_section` :571-580). */
+    uri: string | null;
+    /** Why this row exists — the rule or edge case it pins down. */
+    rule: string;
+}
+/**
+ * `parse_person` (adw-about-dialog.c:490-534), verified against real GLib.
+ *
+ * Seven of these rows are the browser renderer's divergences, and each was a
+ * plausible-looking simplification: anchoring the angle pair at the end of the
+ * string, testing the link for `@`, requiring whitespace before a bare URL,
+ * accepting `mailto:` as a scheme, `String.trim()` instead of `g_strstrip`,
+ * treating index 0 as falsy, and never reaching the `r1 <= q1 + 1` branch.
+ */
+export declare const CREDIT_PERSON_VECTORS: ReadonlyArray<CreditPersonVector>;
+/** One `translator-credits` split expectation. */
+export interface TranslatorCreditsVector {
+    /** The raw `translator-credits` property value. */
+    value: string | null;
+    /** The names the "Translated by" section is built from. */
+    people: ReadonlyArray<string>;
+    /** Why this row exists. */
+    rule: string;
+}
+/**
+ * The sentinel guard + split (adw-about-dialog.c:603-608), with `g_strsplit`'s
+ * token behaviour verified against GLib 2.88.
+ *
+ * The empty-string row is the one a port gets wrong: `g_strsplit ("", "\n", 0)`
+ * is a ZERO-length vector, so `add_credits_section` bails at `!*people`
+ * (:545-546) and no section is drawn; JS `''.split('\n')` is `['']`, which
+ * draws the section with one blank row.
+ *
+ * CORE-ONLY: an internal step of a pipeline whose COMPOSED result is renderer-driven — driving it separately would assert the same thing twice (ABOUT_DIALOG_CREDITS_LEGAL_VECTORS)
+ */
+export declare const TRANSLATOR_CREDITS_VECTORS: ReadonlyArray<TranslatorCreditsVector>;
+/** One assembled credits-page expectation. */
+export interface CreditsSectionsVector {
+    /** The credit properties, as an app sets them. */
+    input: {
+        developers?: ReadonlyArray<string>;
+        designers?: ReadonlyArray<string>;
+        artists?: ReadonlyArray<string>;
+        documenters?: ReadonlyArray<string>;
+        translatorCredits?: string | null;
+        creditSections?: ReadonlyArray<{
+            title: string | null;
+            people: ReadonlyArray<string>;
+        }>;
+    };
+    /** The groups on the Credits page, in order, with each row's title + URI. */
+    sections: ReadonlyArray<{
+        title: string | null;
+        people: ReadonlyArray<{
+            name: string;
+            uri: string | null;
+        }>;
+    }>;
+    /** Why this row exists. */
+    rule: string;
+}
+/**
+ * `update_credits` (:593-627) — which groups exist, in which order.
+ *
+ * The order is fixed by the five `add_credits_section` calls (:611-619) followed
+ * by the app's own sections in insertion order (:621-625). An empty property is
+ * not an empty group, it is no group (:545-546).
+ */
+export declare const CREDITS_SECTIONS_VECTORS: ReadonlyArray<CreditsSectionsVector>;
+/** The `update_details` half of the truth table (:1102-1119). */
+export interface AboutDialogDetailsVector {
+    /** `website` non-empty. */
+    website: boolean;
+    /** `comments` non-empty. */
+    comments: boolean;
+    /** `add_link` was called at least once (:2820). */
+    customLinks: boolean;
+    /** `release-notes` non-empty (:1020-1021). */
+    releaseNotes: boolean;
+    /** The seven widgets `update_details` decides. */
+    visible: {
+        detailsGroup: boolean;
+        whatsNewRow: boolean;
+        detailsRow: boolean;
+        websiteRow: boolean;
+        commentsLabel: boolean;
+        linksGroup: boolean;
+        detailsWebsiteRow: boolean;
+    };
+    /** Why this row exists. */
+    rule: string;
+}
+/**
+ * `update_details` (:1102-1119), exhaustive over (website, comments,
+ * custom links) plus the two rows that show what release notes add.
+ *
+ * The row that matters most is `website only`: it is the ONE combination where
+ * the website link stays on the main page and no Details row is offered, and it
+ * is the combination a port reproduces incorrectly by folding `website` into
+ * its "has details" predicate. `show_details` is `has_comments ||
+ * has_custom_links` — website is deliberately not in it (:1108).
+ */
+export declare const ABOUT_DIALOG_DETAILS_VECTORS: ReadonlyArray<AboutDialogDetailsVector>;
+/** The `update_support` half of the truth table (:1121-1133). */
+export interface AboutDialogSupportVector {
+    /** `support-url` non-empty. */
+    supportUrl: boolean;
+    /** `issue-url` non-empty. */
+    issueUrl: boolean;
+    /** `debug-info` non-empty. */
+    debugInfo: boolean;
+    /** The four widgets `update_support` decides — all on the MAIN page. */
+    visible: {
+        supportGroup: boolean;
+        supportRow: boolean;
+        issueRow: boolean;
+        troubleshootingRow: boolean;
+    };
+    /** Why this row exists. */
+    rule: string;
+}
+/**
+ * `update_support` (:1121-1133), exhaustive.
+ *
+ * Every widget here is a child of `support_group`, which the template puts on
+ * the MAIN page (adw-about-dialog.ui:146-186) — the class docs say so outright
+ * ("displays the following two links on the main page", :87-90). The browser
+ * renderer put Support Questions and Report an Issue on the Details page
+ * instead, which hid the issue tracker behind a navigation step AND made the
+ * Details page appear for a dialog that has no Details content in GTK terms.
+ */
+export declare const ABOUT_DIALOG_SUPPORT_VECTORS: ReadonlyArray<AboutDialogSupportVector>;
+/** The `update_credits_legal_group` half of the truth table (:480-487). */
+export interface AboutDialogCreditsLegalVector {
+    /** `credits_box` has children (:629-630). */
+    hasCredits: boolean;
+    /** `legal_box` has children (:745-746). */
+    hasLegal: boolean;
+    /** `add_acknowledgement_section` was called (:3297). */
+    hasAcknowledgements: boolean;
+    /** The four widgets, all on the main page. */
+    visible: {
+        creditsLegalGroup: boolean;
+        creditsRow: boolean;
+        legalRow: boolean;
+        acknowledgementsRow: boolean;
+    };
+    /** Why this row exists. */
+    rule: string;
+}
+/**
+ * `update_credits_legal_group` (:480-487) with the three template bindings
+ * (adw-about-dialog.ui:198, :215, :233), exhaustive.
+ *
+ * Each row's visibility is bound directly to its page's box, so the group is
+ * the OR of the three and never appears empty.
+ */
+export declare const ABOUT_DIALOG_CREDITS_LEGAL_VECTORS: ReadonlyArray<AboutDialogCreditsLegalVector>;
+/** One main-page header-field visibility expectation. */
+export interface AboutDialogHeaderVector {
+    /** The property being set. */
+    property: 'application-icon' | 'application-name' | 'developer-name' | 'version';
+    /** Its value. */
+    value: string;
+    /** Whether the corresponding widget is shown. */
+    visible: boolean;
+    /** Why this row exists. */
+    rule: string;
+}
+/**
+ * The four `x && *x` visibility tests on the main page (:2313-2314, :2376-2377,
+ * :2426-2427, :2476).
+ *
+ * All four are FIRST-CHARACTER tests, so a single space is content. There is no
+ * fallback anywhere: an unset application name shows NO label, it does not show
+ * the word "Application", and an unset icon shows NO image, not a generic
+ * executable glyph. The browser renderer invented both.
+ */
+export declare const ABOUT_DIALOG_HEADER_VECTORS: ReadonlyArray<AboutDialogHeaderVector>;
+/** One template-label expectation. */
+export interface AboutDialogLabelVector {
+    /** Which label. */
+    label: 'dialogTitle' | 'detailsRow' | 'websiteRow' | 'supportRow' | 'issueRow' | 'troubleshootingRow' | 'creditsRow' | 'legalRow' | 'acknowledgementsRow' | 'whatsNewRow' | 'detailsPage' | 'creditsPage' | 'legalPage';
+    /** The template string, mnemonic marker included. */
+    text: string;
+    /** What a renderer with no accelerator layer paints (`stripMnemonic`). */
+    plain: string;
+    /** Why this row exists. */
+    rule: string;
+}
+/**
+ * The template labels (adw-about-dialog.ui), with and without their mnemonic
+ * markers.
+ *
+ * `dialogTitle` is the row that catches the invented one: the main navigation
+ * page binds its title to `AdwDialog:title`, whose template default is the bare
+ * word "About" (.ui:6, :19). The application name is NOT part of it — it appears
+ * on its own in the header revealer that fades in on scroll (.ui:29-31). A
+ * renderer that titles the page "About <app>" AND labels the dialog "About
+ * <app>" says the app's name three times on one screen.
+ *
+ * CORE-ONLY: a string table the renderers read THROUGH ADW_ABOUT_DIALOG_LABELS; the rendered text is asserted by ABOUT_DIALOG_HEADER/DETAILS_VECTORS
+ */
+export declare const ABOUT_DIALOG_LABEL_VECTORS: ReadonlyArray<AboutDialogLabelVector>;
+/** One `gtk_license_info` row expectation. */
+export interface LicenseInfoVector {
+    /** The `GtkLicense` value, i.e. the array index. */
+    licenseType: number;
+    /** `gtk_license_info[i].spdx_id`. */
+    spdxId: string | null;
+    /** `gtk_license_info[i].url`. */
+    url: string | null;
+    /** Why this row exists. */
+    rule: string;
+}
+/**
+ * Spot rows from `gtk_license_info` (:215-252) — the ends and the boundaries,
+ * not a second copy of the whole table.
+ *
+ * Index 18 is pinned because `G_STATIC_ASSERT (G_N_ELEMENTS (gtk_license_info)
+ * - 1 == GTK_LICENSE_0BSD)` (:253-256) is the C's own check that the table and
+ * the enum have not drifted; this is that assertion, ported.
+ *
+ * CORE-ONLY: an internal step of a pipeline whose COMPOSED result is renderer-driven — driving it separately would assert the same thing twice (ABOUT_DIALOG_CREDITS_LEGAL_VECTORS)
+ */
+export declare const LICENSE_INFO_VECTORS: ReadonlyArray<LicenseInfoVector>;
+/** One SPDX-id lookup expectation. */
+export interface LicenseSpdxVector {
+    /** The AppStream `project_license` value. */
+    spdxId: string;
+    /** The `GtkLicense` it resolves to, or `null` for no match. */
+    licenseType: number | null;
+    /** Why this row exists. */
+    rule: string;
+}
+/** The two lookup loops in `populate_from_appdata` (:1226-1239).  *
+ * CORE-ONLY: an internal step of a pipeline whose COMPOSED result is renderer-driven — driving it separately would assert the same thing twice (LICENSE_INFO_VECTORS → the legal section)
+ */
+export declare const LICENSE_SPDX_VECTORS: ReadonlyArray<LicenseSpdxVector>;
+/** One `get_license_text` expectation. */
+export interface LicenseTextVector {
+    /** The `GtkLicense` value. */
+    licenseType: number;
+    /** The `license` property. */
+    license: string;
+    /** What the Legal page shows, `null` meaning "no licence text at all". */
+    text: string | null;
+    /** Why this row exists. */
+    rule: string;
+}
+/** `get_license_text` (:635-651).  *
+ * CORE-ONLY: an internal step of a pipeline whose COMPOSED result is renderer-driven — driving it separately would assert the same thing twice (ABOUT_DIALOG_CREDITS_LEGAL_VECTORS)
+ */
+export declare const LICENSE_TEXT_VECTORS: ReadonlyArray<LicenseTextVector>;
+/** One licence-setter step. */
+export interface LicenseSetterStep {
+    /** Which setter is called. */
+    property: 'license' | 'license-type';
+    /** The argument. */
+    value: string | number;
+}
+/** One licence-setter sequence expectation. */
+export interface LicenseSetterVector {
+    /** The calls, in order, starting from the property defaults. */
+    steps: ReadonlyArray<LicenseSetterStep>;
+    /** `license` afterwards. */
+    license: string;
+    /** `license-type` afterwards. */
+    licenseType: number;
+    /** Every `g_object_notify_by_pspec` from every step, concatenated in order. */
+    notify: ReadonlyArray<'license' | 'license-type'>;
+    /** Why this row exists. */
+    rule: string;
+}
+/**
+ * The two setters (:3396-3416, :3459-3480), which are ONE state machine.
+ *
+ * Each notifies BOTH properties whenever it does anything (:3414-3415,
+ * :3476-3477), because setting either can move the other. The asymmetry in the
+ * early-outs is the trap: `set_license` bails on an unchanged STRING before it
+ * would have set the type to custom, so re-assigning the same text after a
+ * licence-type change does switch the type, while assigning `""` to an already
+ * empty licence does not.
+ *
+ * CORE-ONLY: a property-ordering table with no rendered surface — the RESULT is ABOUT_DIALOG_CREDITS_LEGAL_VECTORS, which both renderers drive
+ */
+export declare const LICENSE_SETTER_VECTORS: ReadonlyArray<LicenseSetterVector>;
+/** One Legal-page visibility expectation. */
+export interface LegalSectionVector {
+    /** The `copyright` property. */
+    copyright: string;
+    /** The `license-type`. */
+    licenseType: number;
+    /** The `license` text. */
+    license: string;
+    /** Whether the app's own legal section is drawn at all (:666-671). */
+    visible: boolean;
+    /** Why this row exists. */
+    rule: string;
+}
+/** `append_legal_section`'s early-outs for the default section (:666-671, :740).  *
+ * CORE-ONLY: an internal step of a pipeline whose COMPOSED result is renderer-driven — driving it separately would assert the same thing twice (ABOUT_DIALOG_CREDITS_LEGAL_VECTORS)
+ */
+export declare const LEGAL_SECTION_VECTORS: ReadonlyArray<LegalSectionVector>;