Skip to content

0.9.14 — A grey dark mode, and a safer IDE hand-off

Latest
Latest

Choose a tag to compare

View all tags
@nrodear nrodear released this 08 Aug 08:56
· 76 commits to main since this release
v0.9.14
bca1a0d

Release 0.9.14 — A grey dark mode, and a safer IDE hand-off

Released: 2026-08-08
🇩🇪 Deutsche Version

A small follow-up to 0.9.13, entirely driven by what the previous
release got wrong: the dark mode was black rather than grey, and
opening a finding in the Delphi IDE could type the line number into
your source file.

The dark mode is finally grey

0.9.13 introduced the embedded dark style SCA VSDark with the VS Code
Dark Modern palette — and it still looked black. Two reasons, both
fixed here:

  1. The palette was one notch too dark. The literal VS Code chrome
    value #181818 reads as plain black on real monitors. Chrome is now
    #252526, widgets #2D2D30, borders #3C3C3C; the content tone
    stays #1F1F1F.

  2. The background never came from the colour table at all. This
    was the real cause. Under an active VCL style the form background
    is painted from the style's bitmap data, not from a colour
    value — and the stock Windows10 Dark bitmaps carry 109,171 opaque
    #000000 pixels. The chrome panels above it (tile row, toolbar,
    filter row, path row) keep the VCL default ParentBackground, so
    they never fill with their own colour; the assignments in the form
    code were inert and that black showed through no matter which
    palette was configured.

The style generator (tools/make_scadark_style.py) therefore now
patches the bitmaps as well: every opaque black pixel in the
style's three bitmaps is lifted to the chrome tone, verified by a
round-trip that counts the remaining pure-black pixels back to zero.
Bright glyphs are untouched. One colour more changed as well:
cl3DDkShadow, which draws the one-pixel separator under the grid
header, moved from black to the border tone.

The palette lives in one place in that script, so future adjustments
are a constant change plus a regeneration — the format details
(VCL_STYLE 2.0 + zlib, colours as plain-text triples, bitmaps as raw
BGRA) are documented in styles/README.md.

Opening a finding no longer types into your code

The standalone EXE hands a finding to the Delphi IDE through the
Windows shell, then used to press Ctrl+G and type
the line number. If the IDE was still busy — loading the file, indexing
— it swallowed the shortcut, and the digits plus Enter landed as text
in line 1 of the file that had just been opened.

The IDE offers no external switch for a line number, and simulated
keystrokes cannot be made reliable against a busy IDE. So that path is
gone: the IDE route now only opens the file. It is instant (the
~1.6-second UI freeze the keystroke chain needed is gone), and the
status bar says "Opened in Delphi IDE" without claiming a line it
did not jump to.

Jumping to the line still works everywhere it actually can:

  • the external editor — %line% in the [Editor] section of
    analyser.ini (VS Code, Notepad++, Sublime, …),
  • the built-in .dfm viewer,
  • and the IDE plugin, whose navigation goes through the ToolsAPI
    and was never affected.

Smaller change

Apply quick fix left the result grid's right-click menu. The action
itself is unchanged and still available as
Ctrl+Alt+F, matching the plugin, which
never had a menu entry for it.

Full details in the CHANGELOG.

Assets 5
Loading