Grumpy's WYSIWYG Designer for VS Code v0.11.2

Grumpy's WYSIWYG Designer for VS Code v0.11.2

Install from the VSIX attached below:

code --install-extension avalonia-designer-0.11.2.vsix --force

Then reload the window (Ctrl+Shift+P → Developer: Reload Window).

---

Four chart appearance changes, plus a host bug they uncovered.

A gradient background for a chart. The new Background Gradient row offers None / Linear / Radial /
Conic, three colour stops (start, middle, end — the middle one optional) and an angle for the linear
kind, and writes real Avalonia brush XAML (LinearGradientBrush / RadialGradientBrush /
ConicGradientBrush) into the form, so the running app shows exactly the same picture. A linear brush maps
its angle onto StartPoint/EndPoint (corner to corner at 45°); None removes it and gives the plain
backcolour back. Re-opening the editor reads the brush back out of the XAML, hand-written forms included.

Three independent axis colours. The Axis editor's single picker became Line colour, Label colour
and Name colour — the axis line and its ticks, the tick numbers, and the axis name. Leave either text
colour empty and it follows the line colour, which is exactly how every axis behaved before, so no
existing form changes appearance.

A readout you can always read. The cursor value readout now draws its numbers white on a black box
instead of tinting the panel with the plot's backcolour, so a pale chart can never make the values hard to
see. Its border and the series line still take the selected series' colour, so the readout still says
which line it belongs to.

No more "…" button on the chart. The spreadsheet is now chosen from the chart's right-click menu
(Choose spreadsheet…) — in the designer and in the running app — and the Browse Button row is gone from
the Properties list. ShowBrowse is still accepted and simply ignored, so a form saved by an earlier version
keeps compiling and rendering.

The bug found on the way (and it was a real one). The gradient looked perfect in the built app but never
appeared in the designer preview: the preview is drawn by the host's programmatic builder (the XAML loaders
are unavailable for these forms), and that builder had never read a brush property element. Chasing it turned
up an older fault underneath — Brush.Parse returns an immutable brush, a property typed Brush refuses
it, and the builder swallowed that exception per property, so every Brush-typed attribute had silently
kept its default in the preview since long before this version. Both are fixed.

Test suite: 6,437 passed / 0 failed / 0 skipped (6,484 with a forced full control re-audit). Host, C#
probe and VB probe all compile 0 warnings / 0 errors.

---

[0.11.2] - 2026-09-21 · the chart gets its own colours: a gradient background, three axis colours, a reading you can always read

Four appearance requests at the end of the 0.11.1 session: "The cursor value readout display must always
render the X,Y values in White and the readout 'box' backcolor must always be Black. The Border and Series
info adopt the current selected series color (like it is currently).", "Add a color picker to be able to
select the color of the Axis tick labels and axis names as well as the axis lines.", "Add a Gradient
background brush setting to the chart controls. Use the Avalonia gradients system with these brush options:
LinearGradientBrush, RadialGradientBrush, ConicGradientBrush." and "Place the spreadsheet file browse
option in the right-click menu, not a button on the chart surface. Then remove the Browse Button row from
the Properties list."

Added — a Background Gradient for a chart, in all three Avalonia gradient kinds (2026-09-21)

• The new Gradient row in the chart's Appearance group opens a small editor for a background brush:
  a Type of None / Linear / Radial / Conic, three colour stops (start, middle, end — the middle
  one optional), and an angle for the linear kind. None removes the brush, so the chart goes back to
  its plain Back colour / Back opacity.
• The value is a real Avalonia brush on PlotBackBrush, written as a property element:
  <charts:GrumpyXYPlot.PlotBackBrush><LinearGradientBrush StartPoint="0%,0%" EndPoint="100%,100%"> with a
  GradientStop per colour. A linear brush turns its corner-to-corner diagonal (or its compass direction at
  0°, 90°, 180°, 270°) into StartPoint/EndPoint; radial and conic brushes carry the stops only —
  Avalonia's own defaults place them. Re-opening the editor reads the brush back out of the XAML, so a form
  written by hand or by a previous session reopens with the right colours.
• With a brush set, the plot area is not re-filled: the brush is already painted across the whole plate,
  and re-filling the smaller plot rect would map a second, compressed copy of the gradient onto it.

Added — three independent axis colours, so ticks, names and lines can differ (2026-09-21)

• The Axis editor's single Colour picker became Line colour plus Label colour and Name colour
  — the tick labels and the axis name each get their own, and leaving either empty means "follow the line
  colour", which is exactly how every form behaved before.
• On the Axis object this is TickLabelColor and NameColor (both nullable) falling back to AxisColor;
  the ticks and the name are drawn with the fallback applied, while the axis line, its ticks and the
  AxisColor pen are untouched.

Changed — the cursor readout is legible whatever colour the series is (2026-09-21)

• The readout box is now always black with white values, instead of being tinted with the plot's back
  colour at 92% opacity — a light chart could leave the numbers hard to read. The border and the tag
  line (the series name and its value) stay in the selected series' colour, so the readout still says
  which line it belongs to.

Changed — the workbook is chosen from the chart's right-click menu (2026-09-21)

• The little "…" button that sat in the chart's top-right corner is gone from the surface, and so is
  its Browse Button row in the Properties list. Right-clicking the chart now offers
  "Choose spreadsheet…" as the first menu item, next to the series and appearance items it already had,
  so every one-off action lives in one place. An empty chart's hint says so:
  "No data — right-click to choose a spreadsheet, or add a series".
• ShowBrowse is still accepted (it is simply ignored, and documented as such) so a form saved by an earlier
  version keeps compiling and rendering.

Fixed — the preview never showed a brush, and had never shown a Brush-typed attribute at all (2026-09-21)

• The gradient looked perfect in the generated app but did not appear in the designer preview: the host
  renders through its programmatic builder (the reflective and temp-file XAML loaders are both
  unavailable here), and a property element — <charts:GrumpyXYPlot.PlotBackBrush> — never reaches the
  attribute-driven property applier, so the brush was simply dropped. The builder now reads the element and
  builds the brush (solid, linear, radial or conic) with its stops.
• Chasing that turned up a second, older bug: Brush.Parse returns an immutable brush, and a
  property typed Brush (not IBrush) refuses it — SetValue threw, and the preview's per-property
  catch swallowed it, so any Brush-typed attribute (PlotBackBrush="#FF0000" among them) had
  silently kept its default in the preview while the running app honoured it. The converter now returns a
  mutable brush when the parsed one does not fit the property.

Notes

• Suite 6,437 passed / 0 failed / 0 skipped (from 6,306; 6,484 with AVALONIA_COMPLIANCE_RESET=1, a
  full control re-audit): +100 in the new tests/t2-logic/chartAppearance.test.js (both twins, the editor
  seams, and write/read/clear round-trips through the real writers) and +13 in
  tests/t1-preview/chartAppearance.test.js, plus assertions added and reworked in existing files —
  bundledComponents (+2, the staleness marker moved to PlotBackBrush) and the seven that the changes made
  stale, such as the browse button that is no longer drawn or offered. The pixel file proves the two claims
  that no single pixel can: a gradient makes two plate points differ where the plain colour makes them
  identical, and the corner the button used to occupy is empty for both an empty chart and one that still
  says ShowBrowse="True". Pixel measurements on gradients need geometry: a radial brush gives its four
  corners the same colour by construction, and the plate margin above the plot is where a colour can be sampled
  without catching a gridline.

Grumpy's WYSIWYG Designer for VS Code v0.11.1

Install: download avalonia-designer-0.11.1.vsix below, then

code --install-extension avalonia-designer-0.11.1.vsix --force

(Extensions → ⋯ → Install from VSIX… is the no-terminal way. Reload the window afterwards —
an install does not change a window that is already open.)

sha256: 819f0cee3351ce25a4c324c11631ce01379d2d2750e4fc5a97a31707cbc042ec
Test suite: 6,306 passed / 0 failed / 0 skipped.

Two small requests closed the 0.11.0 session out, and both are about space: the room a chart keeps
between its border and its frame, and the width of the Series editor's number fields — where the browser's
own floor, not the stylesheet, was deciding the box.

Added

• Padding on a chart — the room between its border and its frame. A Thickness, so
  Padding="10" and Padding="4,8,4,8" both work, set in the Properties panel (Layout & size, next to
  Border Thickness). It pushes the title, the legend bar and the plot area — with the axis labels and ticks
  around it — inwards from the border. The border itself does not move, and the chart's own backcolour
  still reaches it, so the band it opens up is chart, not form. Negative values are clamped, the little
  "…" open-workbook button stays in the corner, and leaving the row empty keeps the chart's own small gap —
  an unset Padding and Padding="0" render pixel for pixel identically to every version before this one.
• LegendMargin (added in 0.11.0) is its sibling one level in: Padding sits outside the legend frame,
  LegendMargin inside it. A chart can have both.

Fixed

• The Series editor's spinner fields no longer overflow their row. Line Thickness and Marker Size — and
  the same number rows in the Axis and Legend editors (the two tick sizes, the label size, the legend's name
  size, its frame thickness and its margin) — were drawn 204 px wide with their right edge 35 px past every
  other field in the list. The rule asked for a 64 px basis, but a number input's automatic minimum size is
  its intrinsic ~20-character width (the spinner is part of that width), which won over the flex basis and
  stretched the box. They now share the text and select fields' rule, so every row ends on the same right
  edge: 204 px → 169 px.

Notes

• An older project's chart file is refreshed when you save. The bundled-file staleness marker moved to
  Padding: a new attribute is as invisible to an old copy of GrumpyCharts.cs/.vb as a new type is,
  because compiled XAML rejects a property the old copy does not have.
• Docs ride inside this VSIX and are current: CHANGELOG [0.11.1], USER_MANUAL §19.7, CONTROLS.md, and
  the README's version claims — which had been left behind at 0.10.11 by the 0.11.0 pass.
• The suite total reads 6,308 with AVALONIA_COMPLIANCE_RESET=1: the T5 property audit records a control
  it has verified and skips it on later runs, so a steady-state run is two assertions shorter.

Grumpy's WYSIWYG Designer for VS Code v0.11.0

The extension is now called Grumpy's WYSIWYG Designer for VS Code (formerly Avalonia Designer for VS Code) — a display-name change only, so the extension id, your settings, your shortcuts and the models you have already downloaded all keep working.

Install: download avalonia-designer-0.11.0.vsix below, then in VS Code Extensions → ⋯ → Install from VSIX… — or from a terminal:

code --install-extension avalonia-designer-0.11.0.vsix

sha256 3d913e3df7c97fd2970320fbbbab2579865344b44807fb46d139e77f95ab517c

A follow-up to 0.10.11: the charting tool that version shipped is now written down in full — including the cursors chapter the released build was missing — the chart cursors belong to the series they follow, and the README opens with a PayPal donation link. The product itself has one name everywhere now.

Test suite: 6,197 passed / 0 failed / 0 skipped.

Added

• USER_MANUAL §19 has its cursors chapter at last (§19.8): every field of the Cursor editor, what Follow trace does to the crossing, the readout panel and its two placements, Decimals, the runtime keys (←/→ steps a sample, ↑/↓ picks the trace, the drag, the right-click menu) and the ΔX/ΔY row — plus why which cursors are switched on is deliberately not saved. The tips follow it as §19.9.
• CONTROLS.md and README §7 describe the charts where users look for them: the two self-drawing controls, the workbook they read, the four editors and the cursors.
• A donation link at the top of the README — "If you enjoy using this extension, please contribute and consider making a donation." — as a PayPal link, which the Marketplace listing shows too.
• tests/t2-logic/rebrand.test.js (19 assertions) keeps the name honest: the manifest, the strings that must agree with each other, and a scan that fails if any shipped file still calls the product by its old name.

Changed

• A chart cursor that follows a trace is drawn in the colour of the series it follows — its lines, the handle at its crossing and its whole readout panel. The cursor's own Colour row now applies to a free cursor (a threshold line). One function decides it (CursorColor(cursor, trace)), and the readout is drawn from the colour the cursor was actually drawn in, so the panel, the lines and the two-cursor ΔX/ΔY row can never disagree.
• The bundled-file marker moved to DrawnColor. A change in how an existing type draws is as invisible in an old copy as a new type is; saving a form now refreshes the project's GrumpyCharts.cs/.vb, exactly as it does for a new element.
• The extension is renamed — see above. The id (grumpy.avalonia-designer), the settings keys, the keybindings and the storage path are untouched on purpose: that is what makes this a rename and not a migration, and it is why the 4.4 GB of downloaded models stay where they are.
• The name is now the same in the Settings section, the Activity Bar, the output channel, the Problems-panel source, every message that points at them, the code-action label, the marker written into generated files, the host's "could not render this XAML" message and the issue template.

Fixed

• A DataSet written before the rename still counts as generated. The recogniser accepts both wordings, so an older project keeps its DataSet editor — and the protection that keeps the designer out of hand-written code.
• Help text that described retired properties was corrected while the documentation was written: the in-app help, the Cursor modal hints and the field tooltips now say what the code does.

Notes

• 0.10.11's VSIX did not contain the cursor chapter (that documentation was written after it had been packaged). This version carries the complete chapter, which is the main reason to update.
• The documentation rides inside the VSIX — README.md, USER_MANUAL.md, CHANGELOG.md, CONTROLS.md and the generated Events per Control.md.
• Both bundled chart twins are compiled by the test rig against Avalonia 12.1.1 and 11.0.10 (the VB one under Option Strict On), and generated C# and VB projects are built for every Toolbox control.
• Full maintainer notes (CHANGELOG.md, NOTES.md §141/§142, TEST_PLAN.md, PUBLISHING.md) travel with the repository.

Avalonia Designer for VS Code v0.10.11

Install: code --install-extension avalonia-designer-0.10.11.vsix --force,
or Extensions → ⋯ → Install from VSIX… — then reload the window. The file published to the
Marketplace is these same bytes: sha256
20cfa4cedcd0c1e4c33770a0fb11e24c9e2833974a488c1c57e0c1958e64fbb9, 1,035,659 bytes, no
PreRelease attribute.

This is the release that gives the designer a charting tool: two self-drawing chart controls,
each with its own set of editors, that need no package and no chart library — the control draws
itself, so a chart scales to any size and prints like any other control. It also carries the AI
prompt that is typed in the editor at the caret instead of a one-line input box, nine new
toolbox controls, and the fixes from the 0.10.11 line (the "when the code-behind is saved" trigger,
the 30B step-up's two silent failures, and Code Fix declining to ask the model at all for a file that
was not a form). 52 commits since 0.10.10, 66 files, +14,068/−160.

Test suite: 6,153 passed / 0 failed / 0 skipped.

Added

• The charting tools (Charts category: Line Plot, X, Y Plot). Both draw axes with ticks and
  labels, gridlines, a title, a bordered plate and a legend. Data comes from an .xlsx workbook
  (absolute path, column letters, header row, first data row, Live Update re-reading on save) or
  from values typed into the panel, and there is a small code API (SetValues, AddPoint,
  Reload). A chart with no workbook draws a picker button ("…") in its corner so a saved app can
  still be pointed at one.
• A Series editor — one line per series. Each series has its own spreadsheet columns, colour,
  thickness, line style (solid/dash/dot/dash-dot), marker, Join Points, and either shares the
  chart's axes (Common) or is scaled on its own (Per series); every series has a Visible
  switch, added series take the next colour of a palette, and the list order is the drawing order.
  One series per line, read from the sheet's B/C, D/E, F/G … column pairs unless you name them.
• An Axis editor. The two common axes plus an optional X and/or Y axis per per-series line:
  side (left/right, top/bottom), colour, major and minor ticks with their lengths, tick labels with
  their font size, and the axis name. Axes on the same side stack outward from the plot.
• A legend bar and a Legend editor. The bar lists every series by name in its own colour with a
  tick box that switches that trace on and off at runtime; the editor sets its side (bottom, top,
  left or right — it wraps to fit), font size, and a frame with its own backcolour, outline and
  rounded corners.
• Cursors — up to two draggable crosshairs, with a trace readout. Set up in the Cursors editor:
  orientation (both lines, vertical only, horizontal only), dash style, colour, whether its readout
  shows the X value, the trace value or both, its X/Y position, and Follow trace — on by default,
  which makes the crossing point ride the selected series (interpolated between samples) so the
  handle, the horizontal line and the number always agree; off, it is a free crosshair you place
  yourself, i.e. a threshold line. In the running app: drag a line to move the cursor (a following
  cursor slides along its trace), ←/→ step it one sample, ↑/↓ pick the trace the readout
  reports, and right-click the chart for the cursor menu (per-cursor on/off, readout: follow the
  mouse or top-right corner, add/remove cursor, reset to the middle, copy the readout). With two
  cursors switched on, the readout adds the pair's distance — the absolute differences ΔX and ΔY.
• Nine new toolbox controls, with their property rows.
• The AI prompt is typed in the editor, at the caret. AI assist → write a handler asks for a
  description in a multi-line block inside the code file (marked // ✎ AI: begin … end, ' in
  VB) and waits for Ctrl+Alt+Enter to send or Ctrl+Alt+Esc to cancel — so a prompt can be several
  lines, can be edited, and is written where you are already looking. VS Code's own input box has
  neither multi-line nor positioned input, which is why the editor is the input.
• A Background colour picker for NumericUpDown and ToggleSwitch, and a Dock property for the
  charts.

Changed

• A workbook that is open in another program now reads anyway. On Windows a chart bound to a
  sheet being edited in Excel drew nothing: the reader asked for read-only sharing, which Excel
  refuses, and the failure was reported as a raw file error. It now opens with shared read/write
  access, retries briefly while Excel replaces the file as it saves, and says what to do instead —
  "… is open in another program — close the workbook in Excel (or save it again) and this chart
  reloads by itself" — with separate wording for a workbook that is missing.
• A named colour in the designer preview. TitleColor="White", PlotBackColor="Black" and the
  rest were turned into #White by the preview's own value converter and silently drawn transparent,
  so a chart could look right in the app and invisible in the designer. Names are now tried first,
  exactly as Avalonia's runtime does.

Fixed

• The chart's spreadsheet "…" button did nothing. The button was drawn because the property row
  is of kind file, but the click handler only knew four older file properties before it gave up.
• A project's chart file is refreshed again when the designer outgrows it. A copy from before the
  charts gained multiple series cannot compile the XAML the editors write
  (AVLN2000: Unable to resolve type XYSeries…). The staleness test now looks for the newest type the
  designer can write, so saving the form repairs the file — including the form that already had
  series and axes but no cursors.
• "When the code-behind is saved" could never run. The designer shares its tab group with the
  code-behind, so while you are in the file the panel is hidden — and the check began by returning
  early when the panel was hidden. It now analyses wherever the trigger came from, publishes problems
  from the editor, and says so in the status bar.
• The 30B step-up cancelled itself, and a failed run could stay silent. The repair loop treated
  "the designer is not on screen" as a cancel — which is exactly the state you are in when you answer
  the offer from the code — so it threw its own run away before the first build; a throw could also
  escape unlogged and invisible. The step-up now runs regardless of who is looking, every cancel and
  failure is logged and shown, and an escalation that never becomes ready reports it after five
  minutes instead of waiting forever.
• Code Fix never asked the model for a file that was not a form. The analyser declined with
  no-fix when the file was not a form's own code-behind, and the step-up then started a 30B model
  for a fix that had never been attempted. Code Fix works on any C#/VB file (the rules are a bonus,
  not a toll gate), and a form-less file is snapshotted so a bad fix can still be reverted.
• codeCheck.mode and codeCheck.badges were written to the wrong settings scope (the last two
  of the 0.9.33 bug class).
• The "control no longer exists" fix now clears its own finding, and the nine new controls leave
  no code-behind behind when deleted.
• DataSet and TreeView: unbinding a tree removes the code-behind call it generated, the helper
  reaches the project so the template resolves, and roles persist with a flat table.

Notes

• The manual has a charting chapter. USER_MANUAL.md §19 walks through placing a chart, the
  three ways to feed it data, the three editors, the spreadsheet layout, and the limits worth knowing
  — and CONTROLS.md gained a Charts section (it had none: the controls shipped without one).
• The chart controls live in the bundled GrumpyCharts.cs / GrumpyCharts.vb, copied into every new
  project like the other helpers, in both languages — the VB twin is kept line for line with the
  C# one (under Option Strict On) and both build against Avalonia 12.1.1 and 11.0.10.
• The pre-release audit (extract the VSIX and grep it for machine-specific references) found a comment
  naming a local test project inside a compiled file; it was scrubbed and the package rebuilt, which
  is why the bytes differ from any earlier 0.10.11 build. The only remaining reference is the
  verbatim quote in the changelog.
• The Marketplace listing still carries 0.9.4. 0.10.10 was frozen for that upload and is
  untouched (sha256 ec4acc0e…); this release supersedes it, so upload whichever you prefer — the
  portal's Pre-release box must stay unchecked.

Avalonia Designer for VS Code v0.10.10

Install: code --install-extension avalonia-designer-0.10.10.vsix --force, or Extensions → ⋯ → Install
from VSIX… — then reload the window. The Marketplace listing is updated through the publisher portal, so the
file published there is these same bytes: sha256
ec4acc0e376e27b4e18120b8ad3e7bb2ab23befc7b03986efebbf3970bdab9a2, 905,176 bytes, no PreRelease attribute.

Everything here came out of one afternoon of the user testing their own Avalonia app, and each fix was decided
from an artefact — the extension's log file, ps/ss, their generated MyDataSet.cs, their own settings JSON
— rather than from a guess. It supersedes 0.10.9 (released earlier the same evening but never uploaded: a
/home/<user>/… path had reached the package as a compiled comment, so it was rebuilt, audited, and then
superseded by this version) and 0.10.8–0.10.6, and it carries everything from 0.10.0 onwards.

Test suite: 4,868 passed / 0 failed / 0 skipped.

Fixed

• Both 7B picker entries called themselves pinned. They share one .gguf, and the marker compared only the
  file name — "the picker is listing both the vulcan and non-valcon is pinned". The marker and the selection now
  use the configured build, so exactly one entry is pinned and picking CPU only no longer leaves the picker
  pointing at the GPU entry.
• The 30B "would not start" because systemctl start is a no-op on an active unit. The unit had been
  active (running) for two days with its weights swapped out (Memory: 50.4M, peak 17.9G, swap 1.7G), so every
  request hung while systemd reported success. Start server now waits, and when a unit is active but silent it
  restarts it — the command that actually reloads the weights — narrating it while it does.
• The 30B step-up refused itself. It asked whether 16.3 GB would fit in the free memory while the 30B was
  already running (in swap, which depresses what the kernel reports as available). A unit that is up has already
  answered that question, so the offer no longer re-asks it — and the dialog says already running instead of
  promising a minute of loading.
• "AI assist failed: No server answered" — while the runtime was fine. Requests for a repair went to
  assistant.endpoint, a setting that belongs to external servers; on this machine it pointed at a dead port
  from an earlier experiment while the built-in runtime answered elsewhere. The repair guard now uses the
  runtime's own address, and logs it whenever it differs from the setting.
• A failed request left nothing behind. The AI client logged to the Output channel while only the load path
  wrote logs/ai.log — so the file held 766 lines and not one request or failure line, in the file a bug
  report is checked against. Every line reaches the file now, and a failure records the address it used.
• "GPU (Vulkan)" ran on the CPU. The runtime's own command line said --gpu-layers 0 while the picker and
  the status line both said GPU, because only max maps to a layer count. The entry now decides the offload as
  well as the build, and the load in progress uses it.
• The assistant kept writing an API that no longer exists (CS1061: 'MyDataSet' does not contain a definition for 'Customers'). The facts it was given said "the form's data comes from the generated DataSet class" — enough
  to keep writing the nested typed DataSet shape an earlier generator produced. The facts now describe the
  class as it is generated (static helpers, a top-level row class per table), name the members that do not
  exist, and state that a grid's rows are what ItemsSource holds — never .Items, which is WPF's name.
  Proof, from the log twenty minutes later: the Vulkan-built 7B fixed the user's own file on the first run.

Changed

• ⚙ Settings says Loading…, to the left of Cancel and Save, while the AI section is still arriving. The
  report was "it takes several seconds to load fully"; the cause was worse — the state path asked LM Studio's
  lms helper with a 20-second timeout, twice per state, on every open, save and focus. An answer is now
  reused for 15 s and lms is given 3 s in that path, while Refresh list and the load/import flows still ask
  in full. A helper killed at the timeout is logged as an incomplete answer rather than as "no models".
• Vulkan is the default build in the setting as well as in the picker (the manifest and five fallbacks said
  cpu while the picker's first entry was the GPU one — two answers to one question). Asking is still a request:
  a machine with no usable device runs the CPU libraries, the status names what is really running, and a load
  that dies is retried once on the CPU.
• No dev-machine references in the package. The user asked for the check, and it found one: compiled
  comments ship (tsc keeps them, .vscodeignore re-includes out/**/*.js, and the host's .cs sources are in
  the package because the host is built on the user's machine), so an absolute path from a bug-hunt note, a
  template example naming one of their projects, and the captured alias/build id of their own llama-server were
  inside the artefact. All are gone, and the audit — extract the VSIX and grep it — is part of the release now.

Notes

• The docs ride inside the VSIX (README.md, USER_MANUAL.md, CHANGELOG.md, CONTROLS.md), so any later
  edit to those four changes the hash of a future build. NOTES.md §135 has the full engineering write-up.
• Nothing leaves your machine: every request goes to 127.0.0.1, and the AI assist ships off.

Avalonia Designer for VS Code v0.10.9

Install: code --install-extension avalonia-designer-0.10.9.vsix --force, or Extensions → ⋯ → Install from
VSIX… — then reload the window. The Marketplace listing is updated through the publisher portal, so the file
published there is these same bytes: sha256
01ddd09ff8440c1c16c56d69d8fdb60a8cdb2079351bf682e40ac8b8d355d5fc, 905,053 bytes, no PreRelease attribute.

Everything in this release came out of one afternoon of the user testing their own Avalonia app, and each fix
was decided from an artefact — the extension's log file, ps/ss, their generated MyDataSet.cs, their own
settings JSON — rather than from a guess. It supersedes 0.10.6, 0.10.7 and 0.10.8, three builds that were
installed and tested on this machine but never published, and it carries everything from 0.10.0 onwards.

Test suite: 4,868 passed / 0 failed / 0 skipped.

Fixed

• Both 7B picker entries called themselves pinned. They share one .gguf, and the marker compared only the
  file name — "the picker is listing both the vulcan and non-valcon is pinned". The marker and the selection now
  use the configured build, so exactly one entry is pinned and picking CPU only no longer leaves the picker
  pointing at the GPU entry.
• The 30B "would not start" because systemctl start is a no-op on an active unit. The unit had been
  active (running) for two days with its weights swapped out (Memory: 50.4M, peak 17.9G, swap 1.7G), so
  every request hung while systemd reported success. Start server now waits, and when a unit is active but
  silent it restarts it — the command that actually reloads the weights — narrating it while it does.
• The 30B step-up refused itself. It asked whether 16.3 GB would fit in the free memory while the 30B was
  already running (in swap, which depresses what the kernel reports as available). A unit that is up has already
  answered that question, so the offer no longer re-asks it — and the dialog says already running instead of
  promising a minute of loading.
• "AI assist failed: No server answered" — while the runtime was fine. Requests for a repair went to
  assistant.endpoint, a setting that belongs to external servers; on this machine it pointed at a dead port
  from an earlier experiment while the built-in runtime answered elsewhere. The repair guard now uses the
  runtime's own address, and logs it whenever it differs from the setting.
• A failed request left nothing behind. The AI client logged to the Output channel while only the load path
  wrote logs/ai.log — so the file held 766 lines and not one request or failure line, in the file a bug
  report is checked against. Every line reaches the file now, and a failure records the address it used.
• "GPU (Vulkan)" ran on the CPU. The runtime's own command line said --gpu-layers 0 while the picker and
  the status line both said GPU, because only max maps to a layer count. The entry now decides the offload as
  well as the build, and the load in progress uses it.
• The assistant kept writing an API that no longer exists (CS1061: 'MyDataSet' does not contain a definition for 'Customers'). The facts it was given said "the form's data comes from the generated DataSet class" — enough
  to keep writing the nested typed DataSet shape an earlier generator produced. The facts now describe the
  class as it is generated (static helpers, a top-level row class per table), name the members that do not
  exist, and state that a grid's rows are what ItemsSource holds — never .Items, which is WPF's name.
  Proof, from the log twenty minutes later: the Vulkan-built 7B fixed the user's own file on the first run.

Changed

• ⚙ Settings says Loading…, to the left of Cancel and Save, while the AI section is still arriving. The
  report was "it takes several seconds to load fully"; the cause was worse — the state path asked LM Studio's
  lms helper with a 20-second timeout, twice per state, on every open, save and focus. An answer is now
  reused for 15 s and lms is given 3 s in that path, while Refresh list and the load/import flows still ask
  in full. A helper killed at the timeout is logged as an incomplete answer rather than as "no models".
• Vulkan is the default build in the setting as well as in the picker (the manifest and five fallbacks said
  cpu while the picker's first entry was the GPU one — two answers to one question). Asking is still a request:
  a machine with no usable device runs the CPU libraries, the status names what is really running, and a load
  that dies is retried once on the CPU.

Notes

• The docs ride inside the VSIX (README.md, USER_MANUAL.md, CHANGELOG.md, CONTROLS.md), so any later
  edit to those four changes the hash of a future build. NOTES.md §135 has the full engineering write-up.
• Nothing leaves your machine: every request goes to 127.0.0.1, and the AI assist ships off.

Avalonia Designer for VS Code v0.10.5

Install: download avalonia-designer-0.10.5.vsix below, then

code --install-extension avalonia-designer-0.10.5.vsix --force

sha256 f52a4401ef321581f7784245dc58bf29b0ca8306936e5d30169da2435064a39e

Two choices a novice can read, and a step up when they are not enough. The model list is now the same 4.4 GB
download offered twice — Qwen2.5-Coder 7B · GPU (Vulkan), which is the default and the faster one, and
Qwen2.5-Coder 7B · CPU only (no GPU) for a machine whose Vulkan driver will not load it — with everything else
the picker can point at (LM Studio's library, loose .gguf files, your own llama-server, a bare address) folded
under one Advanced… entry. And when a Code Fix… run ends without a clean build, the extension now asks
before it does anything expensive: "Try once more with your 30B model?" — it unloads the 7B, starts your
llama-server unit, loads the big weights and retries the repair once, narrating every step while it happens.

Test suite: 4,829 passed / 0 failed / 0 skipped.

Changed

• One model, two ways to run it. The comparison run on this project decided it: of five models, the 7B was the
  only one whose generated C# compiled, in 9.7 s on the Vulkan build against 13.0 s on the CPU. The 3B was
  quicker and wrong (DataTable.Rows.Find(predicate) does not exist), DeepSeek-Coder-V2-Lite wrote
  DataGrid1.Items — the CS1061 failure 0.10.2 was about — with the facts block in the prompt, and
  Gemma-4-Coder answered nothing at all through the OpenAI path. Those four are no longer offered.
• The entry you pick is the build that runs. Choosing one writes assistant.bundledBackend, the same key the
  status report reads back, so "which build actually loaded" is never a guess. A Vulkan load that dies is still
  retried on the CPU build by itself, with the reason shown.
• Everything else is folded under Advanced…. Nothing was removed — only the reading order changed, so the
  two entries are all a novice has to consider.
• The weights of the four dropped models were deleted from the machine this was written on: 22 GB → 4.4 GB,
  one file left, and it is the one both entries use.

Added

• The 30B step-up. Offered only when a repair run ends without a clean build, and only when the bundled 7B is
  what just failed. Answer Use the 30B and it: unloads the 7B (that is what makes room), starts your
  llama-server unit through the same path the panel's Start server button uses, and retries the repair once.
• You are told at every step — unloading, unloaded and free, starting the unit, waiting for the weights with
  the seconds counting, then "…is answering — asking it to fix the rest…" — on the status bar and in the panel.
• The question states the cost before anything happens (~20 GB, about a minute, and how much memory is free right
  now). It is offered once, never in a loop, and it refuses to offer when the model behind the unit is not
  a real step up (<1.5× the local one) or would not fit — with the reason in the log, because an offer that
  cannot be made is not a failure worth showing.
• Free memory is read as MemAvailable, not MemFree: a machine that has just unloaded a 7B holds that RAM as
  page cache, and MemFree would refuse an offer that actually fits.

Notes

• Suite 4,829 assertions, 0 failed (tests/t2-logic/bigModel.test.js is new with 31, pinned against a
  real unit's nine-line ExecStart and real file sizes).
• 0.10.4, 0.10.3, 0.10.2, 0.10.1 and 0.10.0 are tagged and released on GitHub but were never
  uploaded to the Marketplace, so 0.10.5 is the first version of this line that goes out — and it carries
  everything: the AI assist, the compiler as the second half of the code check, the insert-semicolon rule, the
  build-driven repair loop, the host check, the Start / Stop controls for your own llama-server, the Remove
  Model fix, and now this.

Avalonia Designer for VS Code v0.10.4

Install: download avalonia-designer-0.10.4.vsix below, then

code --install-extension avalonia-designer-0.10.4.vsix --force

sha256 b5f8ab989e2f01b8ae1657eade55964434366d092d04d9eef4ffcfc531caadc5

The button that refused silently now says why. Reported minutes after 0.10.3 went up: "The Remove Model
function is not removing the selected model. check please." Nothing was wrong with the delete — the delete never
ran. Remove Model acts on the selection, and after a Load that selection is a server entry
(My own llama-server, or an address) whose weights are the file the settings pin — very often one this
extension downloaded itself. Everything that was not a plain bundled:<id> entry was refused with one terse
sentence, and a refusal was the one path that logged nothing — so the attempt left no trace anywhere to look
at.

Test suite: 4,810 passed / 0 failed / 0 skipped.

Fixed

• Any selection now resolves to the file behind it. resolveRemoveTarget() maps a downloaded model, a
  .gguf entry, and a server entry (to the file it is serving or the settings pin) onto the same target — and
  deletes it when it is inside the extension's own model folder. A file anywhere else (a Hugging Face cache, LM
  Studio's library, a folder you chose) is refused, with the message naming the folder that is ours, so the
  answer is actionable instead of silent.
• Refusals are logged, so "why did nothing happen?" is answerable from View → Output → Avalonia Designer
  next time.
• The confirmation names the full path, not just the file name — one file name can live in two folders, and
  this is the last moment to notice.
• Removing a model also stops your own llama-server when that is what is serving the file (it used to stop
  only the built-in runtime).
• Models added from the Hugging Face Hub could never be removed either: they are stored in the extension's
  own user-models.json and were looked up in the pinned table alone. The resolution now takes the same list the
  picker shows.

Notes

• The button greys itself out when the selection cannot be deleted, with the reason as its tooltip — so
  "nothing happened" is no longer an outcome. Your 30 B model in a Hugging Face cache, for instance, is still
  correctly not ours to delete, but it now says so.
• Suite 4,810 assertions, 0 failed (removeModel.test.js 40 → 69). Verified against a real machine: a
  server entry pointing at a downloaded 7B resolves and deletes; a file outside the folder, an LM Studio key and
  an address with nothing pinned all refuse with their own reason.
• 0.10.3, 0.10.2, 0.10.1 and 0.10.0 are tagged and released on GitHub but were never uploaded to the
  Marketplace, so 0.10.4 is the first version of this line that goes out — and it carries everything: the AI
  assist, the compiler as the second half of the code check, the insert-semicolon rule, the build-driven repair
  loop, the host check, the Start / Stop controls for your own llama-server, and now this.

Avalonia Designer for VS Code v0.10.3

Install: download avalonia-designer-0.10.3.vsix below, then

code --install-extension avalonia-designer-0.10.3.vsix --force

sha256 cf7a7644f9d0b60ac10a8bc3c644d8e5130d4e5a0995e1f70e29e7fb49530843

The server you already had becomes something you can see and control. Asked while comparing two local
runtimes on this machine: "I don't know who started the llama server (could have been me!). Could you add a
control in the Settings panel to start and stop the llama server?" The extension could already report that
something was answering on port 8080, and it could start a llama-server of its own — but for one it had not
started it could only say "Started outside this window — Stop and Unload leave it alone on purpose." True, and
useless for a process holding 19 GB: the answer to "who started it?" was on the machine all along, in the
process's own cgroup.

Test suite: 4,781 passed / 0 failed / 0 skipped.

Added

• "Who started it?" is read from the kernel and systemd, never guessed. The cgroup of the process holding the
  configured port names its unit, and systemctl --user show adds since when, and whether it comes back at
  login — the difference between "someone started this" and "this starts itself". On the machine this was
  written on the answer was the second one: llama-server.service, a systemd user unit, enabled, up since
  the last login.
• ⤓ Settings → AI assist has a My llama-server row: a dropdown (start as a systemd user unit / start as
  this window's process), Start server, Stop server, and the owner line — unit, scope, uptime, pid, and
  whether it returns by itself. The choice is a setting (assistant.llamaServerStartTarget), written the moment
  the dropdown changes, so the panel and the palette cannot disagree about how it starts.
• Start honours the choice and falls back to the other way when it fails, carrying the failed route's own
  words into the message: a silent fallback leaves you believing the thing you chose is what ran.
• Stop asks first, every time, and names what it is about to stop. A user unit goes through
  systemctl --user stop, so systemd's own state stays true; a system unit is never acted on — the exact
  sudo systemctl stop … line is printed instead, because this extension cannot escalate; and a port held by
  something that is not a llama-server is reported, never signaled.
• Settings assistant.llamaServerService (the unit; empty = find it, from the running server or from the only
  user unit on the machine whose ExecStart runs a llama-server) and assistant.llamaServerStartTarget.
• Status & hardware check prints the same owner line, where it used to say "leave it alone".
• Both palette commands use these paths: AI: Start My llama-server… applies the setting with the fallback (and
  still opens the interactive picker when neither way can work), AI: Stop My llama-server stops whatever holds
  the port, after the dialog.

Fixed

• A first-match regex over the process's cgroup answered user@1000.service — systemd's own user manager —
  so the panel could have offered to stop the wrong thing. The unit is now taken from the last .service
  in the path, and the manager's own unit is refused outright. Caught by this release's own tests before it
  ever ran.

Notes

• Suite 4,781 assertions, 0 failed (was 4,707); PROBLEMS clean; tsc 0 errors.
• The new test file pins the parsers against output captured from a real machine: ss -ltnp, the llama-server
  process's own cgroup, the unit file whose ExecStart is written over nine lines with trailing backslashes, and
  systemctl show. What cannot be proved without touching a service — that every stop is confirmed, that a
  system unit is only ever printed — is asserted against the source.
• The Settings row was measured, not guessed: 68 px added, against the real stylesheet, with the dialog's
  cap, internal scroll and pinned Save row unchanged (tools/measure-settings-panel.py).
• 0.10.2 is tagged and released but was never uploaded to the Marketplace, so 0.10.3 is the first version
  of this line that goes out, and it carries everything: the AI assist, the compiler as the second half of the
  code check, the insert-semicolon rule, the build-driven repair loop, the host check with the experimental
  notice, the ComboBox fixes, and now the server controls.

Avalonia Designer for VS Code v0.10.2

Avalonia Designer 0.10.2

Install: code --install-extension avalonia-designer-0.10.2.vsix --force
(after installing, reload the window — Ctrl+Shift+P → Developer: Reload Window).

sha256  bb77c940000da84c22c1953b258d702981784b4383c4a4286057ac6cfc947a1a

The project's own build is now the referee of the code check, and it can get the repairs done. This release
carries the compiler pass, the semicolon rule, the build-driven repair loop and the host check — and then fixes
the two reasons the loop could not finish its job on a real app.

It started from a plain report: "Code Fix… used to work but now it does not pick up syntax (or any other)
errors" — after removing a ; by hand. It was not a regression: there had never been a semicolon rule, and the
checks that existed are structural (they count braces), so a missing ; was invisible to them while
dotnet build refused the file. The answer is not more rules — the compiler does the finding and the rules do
the fixing, one error at a time, rebuilding after each, undoing a repair that does not help, and listing what
nothing can repair.

Then the same user asked the assistant for code and got something the checker could not fix. Two causes, both
found and fixed here: the loop could only see two of the three model runtimes (so it never asked the
llama-server that had written the code), and the prompts never described what the form's data is (so the model
invented DataGrid.Items for a ComboBox that is bound to a column).

Test suite: 4,707 passed / 0 failed / 0 skipped.

---

Added

• The project's own compiler, as the second half of the code check (avaloniaDesigner.codeCheck.build).
  • dotnet build is run and parsed: errors and warnings land in the Code Fix list and in PROBLEMS, marked
    as coming from the build. MSBuild prints every error twice and both are collapsed to one; only your own
    source is reported (generated obj/ output and other projects are dropped); errors with no file at all
    (CSC : error CS2001: …, error MSB3021: …) are kept rather than silently dropped.
  • A CS1002 in the form's own code-behind gets the same one-click fix the rules use, because the compiler
    knows the line while a rule can only prove the end of a body. Everything else is report-only — no rule can
    repair a type error, and saying so beats pretending.
  • It runs only on a deliberate press (🩺 Code Fix…, or the re-check after a fix), never on the automatic
    checks and never while you type. Incremental: about a second on the test app.
• A statement nothing terminated is now a finding (insert-semicolon): everything after a method body's
  last ; must be a block (}) or nothing at all. C# only — in VB a statement ends at the line.
• The repair loop: build, fix one error, rebuild. A fix that does not help is undone; an error no fixer
  understands is skipped and the loop carries on; the loop is bounded (10 fixes) and stops if you close the
  panel. A designer-made change (a handler it inserted) stays instant, while a hand edit or an AI-assisted
  write is marked and repaired when you come back from the editor to the designer tab.
• A host check, and an honest notice. The extension probes the machine once at start-up and greys the AI
  section out, with the reason, when there is not enough memory for the smallest supported model — judged on
  the memory available right now (free RAM plus a real card's VRAM), with a warning below 20 GB and an
  explicit "Use it anyway" escape. EXPERIMENTAL FEATURE-USE WITH CAUTION opens ⚙ Settings for the AI
  features, with a host-requirements table in the README and the manual.

Fixed

• The repair loop could only see two of the three model runtimes. The built-in runtime (when already
  running) and the configured endpoint were checked; the user's own llama-server — including one kept
  alive by a service between windows — was invisible, so a perfectly good model serving on the machine was never
  asked and the compiler error was only listed. It now checks the built-in runtime, a server this window
  started, anything that answers as llama.cpp, and the configured endpoint — and still never starts a
  runtime just to repair something.
• The AI was never told what the form's data is. Every request now carries the DataSet bindings the rules
  already use: the row type, its columns, and that a control bound to a column holds that column's value, not a
  row — the fact that prevents the invented DataGrid.Items lookup. The panel and the prompts share one
  mapping, so they cannot drift apart.
• A non-display PCI device could be mistaken for the graphics card (lspci lists them all — the USB4 bridge
  was picked as "the GPU"), and Windows AdapterRAM saturates at 4 GB, which would have made every Windows
  card look like a 3 GB card and never be credited.

Notes

• Updating from the published 0.9.4? Install this one. It carries everything that came after 0.9.4
  (0.10.0 and 0.10.1 were prepared but never uploaded).
• Settings worth knowing: codeCheck.build, codeCheck.aiRepair, assistant.ignoreHostCheck, and
  codeCheck.mode (the automatic re-check the build rides on).
• The AI assist is still off until you switch it on, and it sends nothing anywhere — the address is always
  127.0.0.1.