@jbrowse/core 4.3.0 → 5.0.0-beta.1

package/esm/ui/legendMenuItem.d.ts

@@ -0,0 +1,38 @@
+import type { Pin } from '../configuration/promotablePin.ts';
+import type { MenuItem } from './MenuTypes.ts';
+/**
+ * The "Show legend" checkbox, which seven displays build by hand — Hi-C, LD,
+ * alignments, LGVSynteny, multi-wiggle, multi-row features, both multi-sample
+ * variant displays and the Manhattan plot.
+ *
+ * Takes the value and the toggle rather than a `{ showLegend, setShowLegend }`
+ * model, because the Manhattan plot's pair is named for the LD legend it draws
+ * and would otherwise need an adapter object at the call site. Same argument
+ * order as `checkboxItem`, which is all this adds a label to.
+ *
+ * The `showLegend` **config slots** stay per display: their `promotedBase`
+ * values legitimately differ (a Hi-C color scale is off by default, a variant
+ * genotype key on), and their descriptions describe genuinely different legends.
+ * What they now share is being *promotable* — pass `opts.pin` and the row gains
+ * the pin that makes the current state this display type's session-wide
+ * default. Every display whose legend is backed by a config slot passes one,
+ * and gets it from `LegendMixin`'s `showLegendDisplayTypeDefault` rather than
+ * calling `makePin` itself: the slot is the per-display half, the accessors
+ * over it are not.
+ *
+ * `pin` is optional because two callers have no slot to promote: the Manhattan
+ * plot's LD legend and `LinearBasicDisplay`'s color key are a volatile and a
+ * per-legend `dismissed` flag respectively, neither of which is config at all.
+ * They get the plain row, which is what `checkboxItem` builds either way — the
+ * promotable form is that same row plus the pin, per `promotableToggleItem`.
+ *
+ * Deliberately not used by `synteny-core`'s "Show color legend", which sits
+ * inside a "Color by..." submenu where the bare word would not say which legend.
+ */
+/** #menuBuilder showLegendCheckboxItem | the shared "Show legend" checkbox */
+export declare function showLegendCheckboxItem(checked: boolean, onToggle: () => void, opts?: {
+    helpText?: string;
+    disabled?: boolean;
+    disabledHelpText?: string;
+    pin?: Pin;
+}): MenuItem;

package/esm/ui/legendMenuItem.js

@@ -0,0 +1,44 @@
+import { promotableToggleItem } from './promotableMenuItems.js';
+import { checkboxItem } from './toggleMenuItems.js';
+/**
+ * The "Show legend" checkbox, which seven displays build by hand — Hi-C, LD,
+ * alignments, LGVSynteny, multi-wiggle, multi-row features, both multi-sample
+ * variant displays and the Manhattan plot.
+ *
+ * Takes the value and the toggle rather than a `{ showLegend, setShowLegend }`
+ * model, because the Manhattan plot's pair is named for the LD legend it draws
+ * and would otherwise need an adapter object at the call site. Same argument
+ * order as `checkboxItem`, which is all this adds a label to.
+ *
+ * The `showLegend` **config slots** stay per display: their `promotedBase`
+ * values legitimately differ (a Hi-C color scale is off by default, a variant
+ * genotype key on), and their descriptions describe genuinely different legends.
+ * What they now share is being *promotable* — pass `opts.pin` and the row gains
+ * the pin that makes the current state this display type's session-wide
+ * default. Every display whose legend is backed by a config slot passes one,
+ * and gets it from `LegendMixin`'s `showLegendDisplayTypeDefault` rather than
+ * calling `makePin` itself: the slot is the per-display half, the accessors
+ * over it are not.
+ *
+ * `pin` is optional because two callers have no slot to promote: the Manhattan
+ * plot's LD legend and `LinearBasicDisplay`'s color key are a volatile and a
+ * per-legend `dismissed` flag respectively, neither of which is config at all.
+ * They get the plain row, which is what `checkboxItem` builds either way — the
+ * promotable form is that same row plus the pin, per `promotableToggleItem`.
+ *
+ * Deliberately not used by `synteny-core`'s "Show color legend", which sits
+ * inside a "Color by..." submenu where the bare word would not say which legend.
+ */
+/** #menuBuilder showLegendCheckboxItem | the shared "Show legend" checkbox */
+export function showLegendCheckboxItem(checked, onToggle, opts) {
+    const { pin, ...rest } = opts ?? {};
+    return pin
+        ? promotableToggleItem({
+            label: 'Show legend',
+            checked,
+            onToggle,
+            pin,
+            ...rest,
+        })
+        : checkboxItem('Show legend', checked, onToggle, rest);
+}

package/esm/ui/legendSpec.d.ts

@@ -0,0 +1,62 @@
+import type { ReactNode } from 'react';
+export type LegendMark = 'fill' | 'line' | 'curve';
+export interface LegendSwatch {
+    color: string;
+    mark?: LegendMark;
+}
+export interface ColorLegendEntry {
+    key: string;
+    label: string;
+    color?: string;
+    swatches?: LegendSwatch[];
+    hidden?: boolean;
+    marker?: ReactNode;
+}
+export interface LegendItem {
+    color?: string;
+    mark?: LegendMark;
+    swatches?: LegendSwatch[];
+    label: string;
+    hidden?: boolean;
+}
+export declare function legendSwatches(item: LegendItem): LegendSwatch[];
+export interface LegendSection {
+    id: string;
+    title?: string;
+    items: LegendItem[];
+}
+export interface LegendSpec {
+    title?: string;
+    items?: LegendItem[];
+    sections?: LegendSection[];
+}
+export declare function nonEmptyLegendSections({ items, sections }: LegendSpec): LegendSection[];
+export declare function legendEntries(spec: LegendSpec): ColorLegendEntry[];
+/**
+ * How many rows a color key may have and still be one. Past this it is a list
+ * of every row, which is the thing a key exists instead of.
+ */
+export declare const MAX_LEGEND_ITEMS = 20;
+/**
+ * Whether a key built from these items is worth the rows it costs, for a
+ * display that has to *decide* — one whose key is only sometimes the thing
+ * naming its colors, and which therefore asks before drawing.
+ *
+ * Two questions, and both have drawn a useless key on a real track:
+ *
+ * - **Short enough to read?** A list longer than a reader can scan is worse
+ *   than whatever it was going to explain. Ask this of the collapsed items, not
+ *   of the row count — a cohort track's key is one row per group, so 4,390
+ *   cells in nine cell types is nine rows and passes, while the same cells
+ *   ungrouped are 4,390 and do not.
+ * - **Does it distinguish anything?** A key maps colors to names, so it needs
+ *   more than one color to map. Items that all share one — every swatch having
+ *   resolved to the same fallback, which is what a track carrying no identity
+ *   color produces — spend rows over the plot to say nothing. This is why
+ *   `LegendItem.color` should be resolved before it gets here: an unresolved
+ *   `undefined` compares equal to every other `undefined` only by accident.
+ *
+ * Displays whose key is unconditional (alignments, variants) don't need this;
+ * their vocabulary is always worth naming.
+ */
+export declare function legendIsReadable(items: LegendItem[], maxItems?: number): boolean;

package/esm/ui/legendSpec.js

@@ -0,0 +1,78 @@
+// The marks a row draws: its explicit list, else its single color/mark pair,
+// else nothing at all (a heading).
+export function legendSwatches(item) {
+    return (item.swatches ??
+        (item.color === undefined ? [] : [{ color: item.color, mark: item.mark }]));
+}
+// Drop sections with nothing in them, so a heading can never end up with no
+// swatches under it.
+export function nonEmptyLegendSections({ items, sections }) {
+    return (sections ?? (items ? [{ id: 'items', items }] : [])).filter(s => s.items.length > 0);
+}
+// Flatten a legend spec into `SvgColorLegend` rows: a color-less row reads as a
+// heading rather than a swatch. Section titles appear only when more than one
+// section survives — a lone vocabulary needs no title above it — which is the
+// rule `FloatingLegend` applies on screen, so an export and the live legend
+// agree about when headings show. A box-level `title` is unconditional, like its
+// on-screen counterpart.
+export function legendEntries(spec) {
+    const sections = nonEmptyLegendSections(spec);
+    const titled = sections.length > 1;
+    return [
+        ...(spec.title === undefined
+            ? []
+            : [{ key: 'legend-title', label: spec.title }]),
+        ...sections.flatMap(section => [
+            ...(titled && section.title !== undefined
+                ? [{ key: `${section.id}-title`, label: section.title }]
+                : []),
+            ...section.items.map((item, idx) => ({
+                key: `${section.id}-${idx}`,
+                label: item.label,
+                color: item.color,
+                swatches: exportSwatches(item),
+                hidden: item.hidden,
+            })),
+        ]),
+    ];
+}
+// A single filled swatch is what `color` alone already draws, so only a row
+// that says something more — several marks, or one that isn't a fill — carries
+// the list into the export. Keeps the common entry the three fields it has
+// always been.
+function exportSwatches(item) {
+    const swatches = legendSwatches(item);
+    return swatches.length > 1 || swatches.some(s => s.mark && s.mark !== 'fill')
+        ? swatches
+        : undefined;
+}
+/**
+ * How many rows a color key may have and still be one. Past this it is a list
+ * of every row, which is the thing a key exists instead of.
+ */
+export const MAX_LEGEND_ITEMS = 20;
+/**
+ * Whether a key built from these items is worth the rows it costs, for a
+ * display that has to *decide* — one whose key is only sometimes the thing
+ * naming its colors, and which therefore asks before drawing.
+ *
+ * Two questions, and both have drawn a useless key on a real track:
+ *
+ * - **Short enough to read?** A list longer than a reader can scan is worse
+ *   than whatever it was going to explain. Ask this of the collapsed items, not
+ *   of the row count — a cohort track's key is one row per group, so 4,390
+ *   cells in nine cell types is nine rows and passes, while the same cells
+ *   ungrouped are 4,390 and do not.
+ * - **Does it distinguish anything?** A key maps colors to names, so it needs
+ *   more than one color to map. Items that all share one — every swatch having
+ *   resolved to the same fallback, which is what a track carrying no identity
+ *   color produces — spend rows over the plot to say nothing. This is why
+ *   `LegendItem.color` should be resolved before it gets here: an unresolved
+ *   `undefined` compares equal to every other `undefined` only by accident.
+ *
+ * Displays whose key is unconditional (alignments, variants) don't need this;
+ * their vocabulary is always worth naming.
+ */
+export function legendIsReadable(items, maxItems = MAX_LEGEND_ITEMS) {
+    return items.length <= maxItems && new Set(items.map(i => i.color)).size > 1;
+}

package/esm/ui/loadingDotKeyframes.d.ts

@@ -0,0 +1,18 @@
+export declare const dot1: {
+    name: string;
+    styles: string;
+    anim: 1;
+    toString: () => string;
+} & string;
+export declare const dot2: {
+    name: string;
+    styles: string;
+    anim: 1;
+    toString: () => string;
+} & string;
+export declare const dot3: {
+    name: string;
+    styles: string;
+    anim: 1;
+    toString: () => string;
+} & string;

package/esm/ui/loadingDotKeyframes.js

@@ -0,0 +1,17 @@
+import { keyframes } from '../util/tss-react/index.js';
+// Animate opacity (a compositor-offloaded property) rather than visibility so
+// the animation keeps running on the GPU compositor thread while the main
+// thread is busy. visibility/width/color animations run on the main thread and
+// freeze during jank.
+export const dot1 = keyframes `
+  0%, 25% { opacity: 0; }
+  25.1%, 100% { opacity: 1; }
+`;
+export const dot2 = keyframes `
+  0%, 50% { opacity: 0; }
+  50.1%, 100% { opacity: 1; }
+`;
+export const dot3 = keyframes `
+  0%, 75% { opacity: 0; }
+  75.1%, 100% { opacity: 1; }
+`;

package/esm/ui/makeSizeMenu.d.ts

@@ -0,0 +1,30 @@
+import type { ResolvableDisplay } from '../configuration/promotableResolve.ts';
+import type { AnyConfigurationModel, ConfigurationSchemaForModel, ConfigurationSlotName } from '../configuration/types.ts';
+import type { MenuItem } from './MenuTypes.ts';
+import type { SliderScale } from './sliderScale.ts';
+interface SizeMenuOptions {
+    label: string;
+    title: string;
+    help?: string;
+    getValue: () => number;
+    min?: number;
+    max?: number;
+    step?: number;
+    unit?: string;
+    scale?: SliderScale;
+    format?: (n: number) => string;
+    commitOnRelease?: boolean;
+    onChange: (n: number) => void;
+    onReset: () => void;
+}
+export declare function makeSizeMenu(opts: SizeMenuOptions & {
+    isDefault: boolean;
+}): MenuItem;
+export declare function makeSizeSubMenu(opts: SizeMenuOptions & {
+    isDefault: boolean;
+}): MenuItem;
+export declare function makePromotableSizeMenu<CONFMODEL extends AnyConfigurationModel, SLOT extends ConfigurationSlotName<ConfigurationSchemaForModel<CONFMODEL>>>(opts: SizeMenuOptions & {
+    display: ResolvableDisplay<CONFMODEL>;
+    slot: SLOT;
+}): MenuItem;
+export {};

package/esm/ui/makeSizeMenu.js

@@ -0,0 +1,82 @@
+import { jsx as _jsx } from "react/jsx-runtime";
+import { Suspense, lazy } from 'react';
+import { isSlotCustomized, makePin, } from '../configuration/promotableDefaults.js';
+import { INLINE_MENU_ROW_WIDTH } from './inlineMenuRowWidth.js';
+// The row's drawn half is `lazy()` for the reason the promotable pin is a
+// description rather than an element: this builder is called from state models
+// and menu modules, which are eager, and the row is the only route by which MUI
+// `Slider` — the largest single Material component in the eager graph — reached
+// a host's first paint. `type: 'custom'` already made `render` a thunk, so the
+// laziness is free at call time; it is the module edge that had to go.
+//
+// The fallback holds the row's footprint so the open menu doesn't reflow when
+// the chunk lands. Height is the row's natural one (caption line + slider); it
+// is approximate on purpose, since being a few px out for one frame is
+// invisible where a collapse to zero is not.
+const SizeSliderRow = lazy(() => import('./SizeSliderRow.js').then(m => ({ default: m.SizeSliderRow })));
+const sizeRowFallbackHeight = 46;
+// Shared inline "size" control as a single menu row (was a submenu of
+// slider/reset/default). Callers own their config slot/semantics and wire the
+// accessors + a title (which also derives the slider's test id). Used by wiggle
+// point-size/line-width, GWAS Manhattan point-size, arc width, the alignments
+// modification threshold and GC-content window/step sizes, so the
+// slider/reset/pin behavior can't drift. Pass `scale: 'log'` for values spanning
+// orders of magnitude, and `format` to label non-`px` units.
+//
+// For a row over a promotable slot use `makePromotableSizeMenu`.
+export function makeSizeMenu(opts) {
+    return sizeMenu(opts, opts.isDefault);
+}
+// The same control one hop down: a plain submenu row whose only child is the
+// size row above.
+//
+// For a menu where a slider drawn inline is the odd one out. Every other row
+// there is `label + [?] + (checkbox | chevron)` and a size row is a two-line
+// block with a widget of its own, so a menu holding several reads as a form to
+// fill in rather than a list to pick from — and the comparative views' settings
+// menus hold three each. Behind a chevron the row shape is uniform top to
+// bottom, and the value moves inside next to the slider that sets it, which is
+// where the radio submenus already keep their state.
+//
+// `help` lands on the submenu row, which is the row a reader sees: the size row
+// behind the chevron never reaches the menu's shared trailing column, and a "?"
+// of its own would only be a second one for the same setting, a hover away.
+export function makeSizeSubMenu(opts) {
+    return {
+        label: opts.title,
+        helpText: opts.help,
+        subMenu: [makeSizeMenu(opts)],
+    };
+}
+// The same row over a **promotable** slot, which derives both halves the plain
+// form takes by hand — the reset button's enablement (`isSlotCustomized`) and
+// the "default for all tracks of this type" pin — from the one slot name. A
+// slider has no fixed on-value, so the pin promotes whatever the track is
+// currently showing.
+//
+// Naming the slot once is the point: the call sites used to spell it twice, in
+// `isDefault` and again in the pin, with nothing checking the two agreed.
+export function makePromotableSizeMenu(opts) {
+    const { display, slot } = opts;
+    return sizeMenu(opts, !isSlotCustomized(display, slot), makePin(display, slot));
+}
+function sizeMenu(opts, isDefault, pin) {
+    const { label, title, getValue, min = 0.5, max = 12, step = 0.5, unit = 'px', scale = 'linear', format = (n) => `${n}${unit}`, commitOnRelease, onChange, onReset, } = opts;
+    return {
+        label,
+        type: 'custom',
+        // Declared even though `SizeSliderRow` below is what draws it: a custom row
+        // never reaches the shared trailing column, so without this the pin exists
+        // on screen and is invisible to `pinnedSlots` — which is the difference
+        // between a promotable slot that is genuinely unreachable and one that just
+        // renders its own control. See `hasMenuItemAdornment` for why declaring it
+        // costs no layout.
+        ...(pin && {
+            pin: { control: pin, label: title },
+        }),
+        render: () => (_jsx(Suspense, { fallback: _jsx("div", { style: {
+                    width: INLINE_MENU_ROW_WIDTH,
+                    height: sizeRowFallbackHeight,
+                } }), children: _jsx(SizeSliderRow, { title: title, getValue: getValue, min: min, max: max, step: step, scale: scale, format: format, isDefault: isDefault, commitOnRelease: commitOnRelease, onChange: onChange, onReset: onReset, pin: pin }) })),
+    };
+}

package/esm/ui/mapStackTrace.d.ts

@@ -0,0 +1,8 @@
+export interface StackFrame {
+    name: string;
+    uri: string;
+    line: number;
+    column: number;
+}
+export declare function parseStackLine(line: string): StackFrame | undefined;
+export declare function mapStackTrace(stack: string): Promise<string>;

package/esm/ui/mapStackTrace.js

@@ -0,0 +1,108 @@
+import { SourceMapConsumer } from 'source-map-js';
+const sourceMappingUrlRe = /\/\/# sourceMappingURL=(.*)/g;
+// blob: urls (worker scripts) embed a second scheme, so blob: has to be part of
+// the match: without it the uri truncates to a script that doesn't exist
+const protocolRe = /(?:blob:)?(?:https?|file):\/\//;
+const digitsRe = /^\d+$/;
+async function myfetchtext(uri) {
+    const res = await fetch(uri);
+    if (!res.ok) {
+        throw new Error(`HTTP ${res.status} fetching ${uri}: ${await res.text()}`);
+    }
+    return res.text();
+}
+function sourceMapUrl(script, uri) {
+    // the real annotation is the last one — a bundle can carry the literal
+    // earlier in an inlined dependency
+    const mapUri = [...script.matchAll(sourceMappingUrlRe)].at(-1)?.[1]?.trim();
+    let url;
+    if (mapUri) {
+        url = new URL(mapUri, uri);
+        // vite serves scripts as /foo.js?v=hash and the sibling .map needs the same
+        // query; never touch an inline data: map or a map url with its own query
+        if (!url.search && url.protocol !== 'data:') {
+            url.search = new URL(uri).search;
+        }
+    }
+    return url?.href;
+}
+async function loadSourceMap(uri) {
+    try {
+        const mapUrl = sourceMapUrl(await myfetchtext(uri), uri);
+        return mapUrl
+            ? new SourceMapConsumer(JSON.parse(await myfetchtext(mapUrl)))
+            : undefined;
+    }
+    catch {
+        // a frame can point at a script with no map, an unreachable url, or a
+        // revoked blob: worker url. Those frames stay raw instead of failing the
+        // whole trace
+        return undefined;
+    }
+}
+// one load attempt per script per session; loadSourceMap never rejects, so a
+// miss is cached like a hit rather than refetched for every frame
+const sourceMaps = new Map();
+function getSourceMap(uri) {
+    const existing = sourceMaps.get(uri);
+    if (existing) {
+        return existing;
+    }
+    else {
+        const map = loadSourceMap(uri);
+        sourceMaps.set(uri, map);
+        return map;
+    }
+}
+// parses a frame line like "  at f (file:///foo.js:12:34)", or firefox's
+// "f@file:///foo.js:12:34", into its function name, source uri, line and
+// column. undefined when the line has no uri:line:column reference, e.g. the
+// message line that chrome puts first
+export function parseStackLine(line) {
+    const protocolMatch = protocolRe.exec(line);
+    if (!protocolMatch) {
+        return undefined;
+    }
+    const urlStart = protocolMatch.index;
+    const rest = line.slice(urlStart).replace(/\)$/, '');
+    const lastColon = rest.lastIndexOf(':');
+    const secondLastColon = rest.lastIndexOf(':', lastColon - 1);
+    const lineStr = rest.slice(secondLastColon + 1, lastColon);
+    const columnStr = rest.slice(lastColon + 1);
+    return secondLastColon > 0 &&
+        digitsRe.test(lineStr) &&
+        digitsRe.test(columnStr)
+        ? {
+            name: line
+                .slice(0, urlStart)
+                .trim()
+                .replace(/^at\b\s*/, '')
+                .replace(/\s*\($/, '')
+                .replace(/@$/, ''),
+            uri: rest.slice(0, secondLastColon),
+            line: +lineStr,
+            column: +columnStr,
+        }
+        : undefined;
+}
+async function mapStackLine(line) {
+    const frame = parseStackLine(line);
+    const consumer = frame ? await getSourceMap(frame.uri) : undefined;
+    if (frame && consumer) {
+        const pos = consumer.originalPositionFor({
+            line: frame.line,
+            // stack traces report 1-based columns, source maps are 0-based
+            column: frame.column - 1,
+        });
+        const { source, line: origLine, column } = pos;
+        return source !== null && origLine !== null && column !== null
+            ? `${source}:${origLine}:${column + 1}${frame.name ? ` (${frame.name})` : ''}`
+            : line;
+    }
+    else {
+        return line;
+    }
+}
+export async function mapStackTrace(stack) {
+    return (await Promise.all(stack.split('\n').map(mapStackLine))).join('\n');
+}

package/esm/ui/measureLegendText.d.ts

@@ -0,0 +1 @@
+export declare function measureLegendText(str: string, fontSize: number): number;

package/esm/ui/measureLegendText.js

@@ -0,0 +1,8 @@
+import { measureText } from '../util/index.js';
+// measureText uses a Helvetica width table, but SVG legend <text> nodes have no
+// font-family and render in the wider app font (Roboto), so scale the estimate
+// up before sizing the white paper behind a label or it clips.
+const APP_FONT_WIDTH_RATIO = 1.1;
+export function measureLegendText(str, fontSize) {
+    return measureText(str, fontSize) * APP_FONT_WIDTH_RATIO;
+}

package/esm/ui/menuItemAdornment.d.ts

@@ -0,0 +1,33 @@
+import type { MenuItem } from './MenuTypes.ts';
+/**
+ * The trailing control a menu row draws, resolved at the point of drawing.
+ *
+ * Two fields feed it and they are not equivalent. `endAdornment` is an element
+ * the builder already made — the escape hatch, for content nothing else can
+ * describe. `pin` is a *description* of the "default for all tracks of
+ * this type" pin, and turning it into `PinAdornment` here is the whole
+ * point: the builders that set it (`promotableToggleItem`,
+ * `promotableRadioItem`) are called from state models and menu modules, which
+ * are eager, so a module that constructs the element instead puts MUI's
+ * `ToggleButton`, `Tooltip` and two icons into every host's first paint.
+ *
+ * Live in one place rather than at each of the four render sites, because the
+ * "does any row have one?" predicates and the rendering have to agree — a row
+ * that draws a pin the column-reservation pass didn't count is a misaligned
+ * menu, not a crash.
+ */
+export declare function menuItemAdornment(item: MenuItem): string | number | bigint | true | import("react").JSX.Element | Iterable<import("react").ReactNode> | Promise<string | number | bigint | boolean | Iterable<import("react").ReactNode> | import("react").ReactElement<unknown, string | import("react").JSXElementConstructor<any>> | import("react").ReactPortal | null | undefined> | undefined;
+/**
+ * Whether this row draws something in the shared trailing column — the question
+ * `getMenuColumnFlags` asks to decide whether to reserve that column on every
+ * row of the menu.
+ *
+ * **Not the same question as "does this row offer a pin"** (`pinnedSlots`, which
+ * counts a `pin` wherever it appears). A `type: 'custom'` row renders
+ * its own content edge to edge and never reaches `menuItemAdornment`, so it
+ * cannot draw in that column however it is declared — counting it would reserve
+ * a spacer on its siblings for a control that never appears. It still declares
+ * `pin` when it draws a pin of its own (`makePromotableSizeMenu`),
+ * which is what keeps the pin findable. Don't "fix" the two into agreement.
+ */
+export declare function hasMenuItemAdornment(item: MenuItem): boolean;

package/esm/ui/menuItemAdornment.js

@@ -0,0 +1,50 @@
+import { jsx as _jsx } from "react/jsx-runtime";
+import { PinAdornment } from './PinAdornment.js';
+/**
+ * The trailing control a menu row draws, resolved at the point of drawing.
+ *
+ * Two fields feed it and they are not equivalent. `endAdornment` is an element
+ * the builder already made — the escape hatch, for content nothing else can
+ * describe. `pin` is a *description* of the "default for all tracks of
+ * this type" pin, and turning it into `PinAdornment` here is the whole
+ * point: the builders that set it (`promotableToggleItem`,
+ * `promotableRadioItem`) are called from state models and menu modules, which
+ * are eager, so a module that constructs the element instead puts MUI's
+ * `ToggleButton`, `Tooltip` and two icons into every host's first paint.
+ *
+ * Live in one place rather than at each of the four render sites, because the
+ * "does any row have one?" predicates and the rendering have to agree — a row
+ * that draws a pin the column-reservation pass didn't count is a misaligned
+ * menu, not a crash.
+ */
+export function menuItemAdornment(item) {
+    if ('endAdornment' in item && item.endAdornment) {
+        return item.endAdornment;
+    }
+    // A disabled row is `pointer-events: none` (see `DisabledTooltip`, which
+    // exists because that also swallows a Tooltip's hover), so a pin drawn in one
+    // takes no click while looking exactly like a live one. Greying it is what
+    // the help "?" does on such a row by not rendering at all; the pin stays
+    // drawn so the trailing column keeps its alignment.
+    return 'pin' in item && item.pin ? (_jsx(PinAdornment, { pin: item.pin, disabled: item.disabled })) : undefined;
+}
+/**
+ * Whether this row draws something in the shared trailing column — the question
+ * `getMenuColumnFlags` asks to decide whether to reserve that column on every
+ * row of the menu.
+ *
+ * **Not the same question as "does this row offer a pin"** (`pinnedSlots`, which
+ * counts a `pin` wherever it appears). A `type: 'custom'` row renders
+ * its own content edge to edge and never reaches `menuItemAdornment`, so it
+ * cannot draw in that column however it is declared — counting it would reserve
+ * a spacer on its siblings for a control that never appears. It still declares
+ * `pin` when it draws a pin of its own (`makePromotableSizeMenu`),
+ * which is what keeps the pin findable. Don't "fix" the two into agreement.
+ */
+export function hasMenuItemAdornment(item) {
+    if (item.type === 'custom') {
+        return false;
+    }
+    return (('endAdornment' in item && !!item.endAdornment) ||
+        ('pin' in item && !!item.pin));
+}

package/esm/ui/menuItems.d.ts

@@ -0,0 +1,28 @@
+/**
+ * Menu-item *builders*, and nothing that draws one.
+ *
+ * These builders return plain objects, and their callers are state models
+ * and `menuItems.ts` / `trackMenus.ts` modules across a dozen plugins — code
+ * that is evaluated when a plugin installs, before any session can be read.
+ * Reaching them through `@jbrowse/core/ui` meant reaching them through a barrel
+ * that re-exports ~80 Material UI components, and the union of what those eager
+ * callers happened to name was most of Material UI in every host's first paint
+ * (reference/EAGER_BUNDLE.md).
+ *
+ * So the split is not stylistic: **import menu builders from here, components
+ * from `@jbrowse/core/ui`.** This entry must never reach react, @mui or
+ * @emotion, and `menuItems.purity.test.ts` fails if it starts to — including
+ * transitively, which is the only way the failure would ever show up.
+ *
+ * The other half of keeping that true is `MenuItemPin`: a row's pin is
+ * described here and built by the renderer, because an element in a descriptor
+ * pulls its whole component graph back in.
+ */
+export { checkboxItem, radioItem, radioItems, toggleItem, withSubHeader, } from './toggleMenuItems.ts';
+export { withHint } from './menuLabels.ts';
+export { makeRadioSubMenu } from './radioSubMenu.ts';
+export { showLegendCheckboxItem } from './legendMenuItem.ts';
+export { promotableRadioItem, promotableRadioItems, promotableToggleItem, } from './promotableMenuItems.ts';
+export type { RadioOption, SettingRowOptions } from './toggleMenuItems.ts';
+export { staysOpenOnClick } from './MenuTypes.ts';
+export type { BaseMenuItem, CheckboxMenuItem, ClickableMenuItem, CustomMenuItem, MenuDivider, MenuItem, MenuItemClickHandler, MenuItemPin, MenuItemsGetter, MenuSubHeader, NormalMenuItem, RadioMenuItem, SubMenuItem, } from './MenuTypes.ts';

package/esm/ui/menuItems.js

@@ -0,0 +1,26 @@
+/**
+ * Menu-item *builders*, and nothing that draws one.
+ *
+ * These builders return plain objects, and their callers are state models
+ * and `menuItems.ts` / `trackMenus.ts` modules across a dozen plugins — code
+ * that is evaluated when a plugin installs, before any session can be read.
+ * Reaching them through `@jbrowse/core/ui` meant reaching them through a barrel
+ * that re-exports ~80 Material UI components, and the union of what those eager
+ * callers happened to name was most of Material UI in every host's first paint
+ * (reference/EAGER_BUNDLE.md).
+ *
+ * So the split is not stylistic: **import menu builders from here, components
+ * from `@jbrowse/core/ui`.** This entry must never reach react, @mui or
+ * @emotion, and `menuItems.purity.test.ts` fails if it starts to — including
+ * transitively, which is the only way the failure would ever show up.
+ *
+ * The other half of keeping that true is `MenuItemPin`: a row's pin is
+ * described here and built by the renderer, because an element in a descriptor
+ * pulls its whole component graph back in.
+ */
+export { checkboxItem, radioItem, radioItems, toggleItem, withSubHeader, } from './toggleMenuItems.js';
+export { withHint } from './menuLabels.js';
+export { makeRadioSubMenu } from './radioSubMenu.js';
+export { showLegendCheckboxItem } from './legendMenuItem.js';
+export { promotableRadioItem, promotableRadioItems, promotableToggleItem, } from './promotableMenuItems.js';
+export { staysOpenOnClick } from './MenuTypes.js';