Reported from a real pass through the window.
The theme categories were a static readonly array, so the five names
froze at whatever language the plugin started in and a runtime switch
relabelled the entire window except them. Same shape as the layout
labels earlier in this cycle; this one got missed because replacing the
literals with resource lookups looks finished until you actually switch.
The status bar built its counts from English literals -- tab, tabs, msg,
tell, tells -- and the privacy pill said "Privacy-First" in all 25
files. The thousands separator follows the user's culture now too, so
German reads 1,2k rather than 1.2k.
The live preview claims to show what the window will look like. It was
showing English channel names next to a translated placeholder, which is
worse than either. Channel labels come from ChatType.Name() now and the
status slots share the strings with the real status bar. The four mock
chat lines stay English on the earlier decision.
And the export wrote a byte order mark. Encoding.UTF8 emits one, and a
leading U+FEFF makes the JSON invalid for every strict parser --
confirmed against a real export from the game, where python's json.load
refused the file. CSV keeps its BOM, because without one Excel guesses
the codepage and mangles every non-ASCII name.
The self-test that was supposed to catch that read the file with
File.ReadAllText, which strips a BOM while detecting the encoding. It
reads bytes now.
The status bar tests asserted English literals and started failing on a
German machine -- they pin a fixed culture now instead of inheriting the
locale of whoever runs them.
The cleanup preview marked itself stale before it could be drawn. The
gate bumps a revision on release so a preview cannot survive a wipe; I
then made the preview take the gate, so its own release invalidated it
every single time and the apply button never appeared. The feature has
been shipping non-functional since it was written, with a self-test that
asserted the exact bump that killed it.
Read-only operations no longer move the revision, and preview and
maintenance have their own marks instead of borrowing Cleanup -- which
also stops the five-second metadata refresh from expiring previews, and
stops the UI announcing "another operation is running: cleanup" during a
VACUUM.
The JSON export produced invalid JSON. The chat relation kinds were
interpolated straight into the output, and interpolating an enum writes
its member name, so every message with a recognised relation came out as
"source_kind":LocalPlayer. That is the file a GDPR access request goes
out on. The self-test wrote a JSON file and never parsed it; it does now.
Retention with the limit at zero still deleted. The slider is labelled
"0 = never" and the sweep seeded 31 spec defaults unconditionally before
reading the user's overrides, so zero still lost free company, linkshell
and party history after ninety days -- and the short-circuit written for
exactly this case could never be reached, because the map was never
empty.
A wipe that worked reported that it had failed. VACUUM needs the
database to itself, the refilter walks a lazy reader on the primary
connection outside the lock, and the two collide -- after the DELETE has
committed. The delete paths no longer let that escape: the rows are
gone, an uncompacted file is a housekeeping problem, and telling
somebody their history is still there when it is not is a different kind
of problem.
Also:
- CSV cells starting with =, +, - or @ get a leading apostrophe. The
content is text other people typed into a chat channel and the file
exists to be opened in a spreadsheet.
- An export that matched nothing no longer replaces the previous one. It
used to write its header, move it into place, and then report that
nothing matched. Dalamud's save dialog offers no overwrite
confirmation to fall back on, so this is the part that had to move.
- The retention sweep says so when it loses the race for the gate, and
routes its notifications through the teardown check like everything
else.
The real defect first. RefreshDatabaseMetadata was the one worker of six
that never took the shared lock, and its flag was the one of six missing
from the tab's busy state. It calls MessageCount, which holds the read
lock, so a wipe could start while it was in there -- and the tab would
not have known to grey the button, because it could not see the worker.
Both halves fixed. The pattern is why: seven near-copies of one worker
skeleton, and each copy decided something slightly different.
The clear button failed silently when its thread could not start. The
most destructive control in the plugin, pressed, and nothing happens,
with no way to tell that from a wipe that worked -- while the three
harmless workers beside it do report. Maintenance was the mirror: its
comment promises refusals are said out loud, and then swallowed the
actual failure. Three start-failure paths also bypassed the notify
helper that carries the teardown check, three weeks after it was added
for exactly that.
The database numbers now wait for a real read, like the clear hint
already did. Zero bytes and zero messages read as an empty database, not
as a number nobody has fetched.
SelectionAfterDelete is gone, with its three tests. The accordion has no
selection, so its return value went into a discard -- a function
answering a question the interface does not ask, with green tests
guarding nothing. The project's own self-test README calls that the
anti-pattern of record.
Six new keys replaced by the translated orphans that already said the
same thing. A commit earlier in this cycle is literally called "stop
duplicating a key" and these went past it. The duplicate button also had
the label "Add", which is the one string out of ninety-four that was
never written.
Tests: CleanupDeleteTypes had none, and with the failsafe on -- how a
fresh config ships -- it is the path every cleanup takes. Four now,
including the one that matters: an empty list deletes nothing rather
than everything.
And a self-test for the gate wiring, which is what would have caught the
metadata worker. The unit tests prove the gate works; nothing proved the
workers use it.
Fifty-four keys across 25 files, and a script that can find the rest.
The script reports rather than deletes, because a key with no caller is
a question and not a verdict: this cycle has twice found one that only
described a feature whose button was torn out, and deleting it would
have made the restoration cost 25 files of re-translation. The answer
lives in the git history of the deletion, not in a grep.
So only the ones where that history says the feature went on purpose:
the web interface, the settings card overview the sidebar replaced, the
save-and-discard model this window does not have, the LiteDB migration
dialog, and three one-time announcements for versions long past.
Plus nine this cycle superseded itself, including the three notes
telling the reader to press Save first.
251 keys still have no caller. That is not a to-do list -- it is the
inventory the search pass turned up: timestamp layouts, collapse
duplicate messages, the About tab's prose, the honorific glow, the
novice network button. Every one of them describes something that used
to work. They stay until each has been decided one way or the other,
which is the whole premise of this cycle.
There has been no way to create a tab, delete one, reorder them, or
choose what any of them collects since the settings window was rebuilt
in May. The five tabs a config happened to have were all a user could
ever have. Every label for this was sitting in the resources, translated
into 25 languages, with no caller.
An accordion, not the list-and-detail pane the plan sketched. The
settings column is narrow, every other tab in this window is a stack of
collapsible sections, and a split pane inside one of them would be the
only thing here that reads differently without buying anything.
Channels go through the matrix that already existed, unchanged: it knows
the groups, the sub-matrices and the ExtraChat channels, and it is
localised. What it does not know is copy-on-write -- it mutates the
dictionary it is handed -- so it never gets the tab's own. Edits land in
a working copy and are published as one reference swap when the user
leaves the tab, and only if something actually changed.
Saving is deferred behind a dirty flag with a short idle, not
IsItemDeactivatedAfterEdit. That idiom defers for sliders and text
fields, which stay active across frames; a checkbox activates and
deactivates inside one click, so it would fire exactly as often as the
return value and write the config file once per box.
Deleting closes the pop-out first, or the pool keeps a slot bound to a
tab that no longer exists. The last editable tab cannot be deleted at
all: the message list has no empty state. Temp tabs are not editable
here -- their name is a conversation partner and the auto-tell service
owns their lifetime -- so they are skipped entirely.
Also E2: Tab.AddMessage stamps LastActivity for every message now. The
condition that used to gate it filtered on InactivityHideChannels, a
setting belonging to hide-when-inactive, and that feature lost its
reader in cf4705e. Which tell tab the pool drops first -- the only thing
that reads the stamp -- was hanging on a setting for something that does
not happen. The three channel fields behind it are gone.
Two decisions, both yours.
Where Square Enix ships a client in a language, that client's word wins.
German says Flüstern, French message privé, Japanese テル, Korean
귓속말, Simplified Chinese 密语. Everywhere else there is no official
client and the loanword is what players actually say, so it stays.
That meant rewriting the whole corpus in those languages rather than
just the new keys, which is the reason the split existed in the first
place: forty German values and thirty-seven French ones carried the old
word. /tell is untouched, because that is a command and not a noun.
The mechanical pass left French with three agreement errors -- "des
message privé", "ce onglet", "messages de message privé" -- which is
what happens when you substring-replace a language with gender and
number. Fixed by hand.
Traditional Chinese keeps 悄悄話, which the file already used nineteen
times; it has no official client of its own.
The appearance tab is translated as well. Thirty keys: the colour
editor's groups and buttons, the theme categories, fork and import and
export, the font labels and the preview's input placeholder. Theme token
names stay English -- WindowBg and TextPrimary are JSON keys, not
prose -- and so do the brand strings.
465 keys, 25 files, no gaps, no orphans, no placeholder drift.
Still English and not in this commit: the database viewer behind
/hellionView, which is a documented user command rather than a
developer tool, and the symbol picker. Both are their own block.
A language review over all 24 files found that the translation batch had
been written as if the file were empty. It is not: eleven years of
FFXIV vocabulary and several hundred existing values already decided how
this plugin says things, and the new strings disagreed with them.
Three said something wrong rather than something unusual:
- Norwegian called opacity "tetthet", which is density -- and the same
file uses that exact word for compact density, so one word stood for
two different settings.
- Danish called the brand section "Brand", which in Danish is fire.
- Turkish called a manifest a notification, in a window that already has
a notifications section.
Then the glossary itself. "tab" is zakładka in Polish, tab in Romanian
and Danish; "plugin" stays plugin in five languages that had translated
it; "pop-out" is a loanword in six. The Shift key keeps its name in
Swedish, Finnish and Italian, because that is what is printed on it.
Fixing pop-out also shortened the three longest row labels in the batch
past the point where SettingRow would have clipped them.
Czech was the clearest outright error: the existing file addresses the
reader informally throughout, and five new strings switched to the
formal form.
And a gap in my own previous fix: I had moved four of the five tell
strings to the established loanword and missed the fifth pair, so the
failed-tell warning still said "Flüstern" while its neighbours said
"Tell".
435 keys, 25 files, no gaps, no orphans, no placeholder drift, and every
one of the five tell keys now carries the same word in every language.
Whether German and French should say Flüstern and message privé rather
than tell is a real question -- both game clients do -- but that is a
glossary decision for the whole file, not something to introduce through
four new keys.
A review pass found the translation commit had introduced a split rather
than closed one.
Every existing string in this plugin leaves "tell" untranslated -- it is
what the game calls the thing, in twenty values across the German file
alone. My new keys translated it, so the channels tab showed "Auto-Tell-
Tabs" and, two rows below, "Flüstern automatisch öffnen". Thirteen of
fourteen sampled languages had the same break. The four affected keys
now use the established word, which also fixes a German line that had
tells "aufgehen" like a door.
Turkish said the opposite of what the control does: saydamlık is
transparency, the slider is opacity, and 1.0 means fully opaque. Every
other language uses the opacity word. Corrected, along with the inactive
one beside it.
Compact density had grown a second key for a field that already had one.
Appearance_UseCompactDensity_Name and _Description were sitting there
with no caller -- which is precisely what this cycle exists to fix -- so
the chat tab uses those and my duplicate is gone again. The German
wizard label for the same field said "Kompakter Density-Modus"; it says
the same thing as the other two now.
Also: Hungarian called a pop-out window "kiemelt" (highlighted), the
project's word is "kiugró"; German called it "ausgeklappt", which is
what a menu does; Italian and Polish had a clumsy inactive-opacity
label.
435 keys, all 25 files, no gaps, no orphans in either direction.
One claim in the previous commit was wrong and is worth stating plainly:
it said only log lines, thread names, developer tools and brand strings
remained English. The appearance tab is still English throughout -- the
theme picker, the colour editor, the font section, the live preview --
and so are parts of the database viewer, which is a documented user
command, not a developer tool. That is a separate block, not a footnote.
The settings window was rebuilt in v1.10.0 and v1.11.0 with its labels
written straight into the C#. Every section heading and most row labels
across five tabs read English in all 25 languages, which the memory
notes had accepted as a known backlog.
Forty-nine keys close it: seventeen section headings, the rows under
them, and the two layout choices. All 25 languages, 437 keys each, no
gaps and no placeholder drift in either direction.
The layout labels are a property rather than a static array now. A
static one would hold whichever language the plugin started in, and this
plugin switches language at runtime.
What stays English, deliberately: log lines and thread names, which no
user reads; the two developer tools behind Shift plus Ctrl+Shift, per
the decision that developer surfaces stay English; and the About tab's
brand lines, attributions and licence identifiers, which are names.
The two halves that can be settled without a window, before the window
exists.
Concurrency first, because the editor is the first thing that ever
writes SelectedChannels after load. All three channel-filter fields are
read without a lock from the pending-message thread, the filter worker
and the draw thread, and mutating a live Dictionary while Matches walks
it is the standard way to get a wrong answer on somebody else's stack.
ReplaceChannelFilter builds the replacements and swaps the references,
so a reader sees the old set or the new one and never half of either.
It deliberately stops short of making the three writes one atomic step.
A reader can catch the new dictionary with the old ExtraChat flag for a
single message, which the editor's closing clear-and-refilter
reconsiders anyway. Doing better would mean one reference for all three,
and all three are serialized fields whose shape the config file already
has.
Then the index maths, which is where temp tabs make this more than list
arithmetic. They live in the same collection, they are not editable --
their name is a conversation partner and deleting one would be deleting
a conversation -- and a move has to step over them rather than swap with
them, or moving a tab down and back up would not return it to where it
started. Reversible in the editable order, which is the order the user
sees; the sidebar draws temp tabs under their own headers regardless of
where they sit in the list.
Twelve facts, and one of them started out asserting the wrong property:
that the whole list is restored by a move and its reverse. It is not,
and it does not need to be.
The last editable tab cannot be deleted. The message list has no empty
state, so a window with nothing to draw is not a state to offer.
Block D of v1.12.0. The line between the two is the whole job, and I got
it wrong once on the way: six cache fields on Tab looked dead because
nothing writes them, and nothing writes them because AutoTellTabTint and
TabTintCache went out with the chat window in cf4705e. Deleting the
fields would have cemented a loss instead of recording a decision.
So they are back, and the sidebar uses them again: an auto-tell tab is
tinted and glyphed from its partner, twelve colours against seven icons.
Four open tells are no longer four identical envelopes in one colour.
Their own header promised the same partner keeps its colour "across
sessions" while hashing with string.GetHashCode, which .NET salts per
process -- every game start reshuffled every tab. FNV-1a now, with a
lowbias32 finalizer that is not decoration: without it a probe over 144
similar keys reached six of the twelve colours, because the caller takes
the low bits with a modulo and FNV leaves those correlated. Three pinned
values guard it, which is also the only assertion that can catch a
regression to a salted hash.
The same question, asked of the three hide conditions this block had
quietly orphaned: HideDuringCutscenes, HideInBattle, HideWhenNotLoggedIn
all had readers in v1.5.6 and lost them in the same commit. Two of them
are states rather than conditions -- a cutscene the user dismissed stays
dismissed until it ends, and combat must not seize a chat that is
already hidden for another reason -- so they come back as a small state
machine with eight pinned transitions, and three toggles whose labels
were already translated in all 25 languages.
Actually deleted, with a reader search each time:
- Six per-tab hide fields. Their reader was the pop-out window and it
stopped consulting them in cf4705e. Per-tab was the wrong unit anyway:
"hide during cutscenes" is a statement about the screen.
- Tab.ChatCodes, whose migration the v16 schema gate had already made
unreachable.
- InactivityHideTimeout and InactivityHideActiveDuringBattle, MaxLinesToRender
which had stopped bounding anything, and the 155 lines of
Configuration.UpdateFrom with no caller at all.
Config version 25, at all three places that carry it. No migration step:
the gate only refuses anything under 16 and Json.NET drops keys it does
not know, so the deleted fields simply stop being written.
One thing a review pass caught that matters more than any of the above:
the clone parity guard had gone hollow. It compares collections by
count, ChatCodes was the only collection the probe seeded, and removing
it left the guard comparing zero against zero. Verified by making
Tab.Clone discard both remaining collections and watching every
assertion stay green. The probe seeds them now, and the same sabotage
fails as it should.
The wizard asked for it, coupled it to a neighbour, listed it in the
summary as applied, and wrote it to the config. No code in the plugin
has ever read it. A wizard that collects a decision and reports an
effect that does not happen is worse than one that never asked.
Its partner, FilterIncludePreviousSessions, has a real reader and stays.
The coupling was two-way -- switching this on forced the partner on,
switching the partner off forced this one off -- so removing it leaves a
single checkbox that means what it says, and the summary line now
reports the setting that actually took effect.
The self-test asserted that skipping step 3 does not overwrite either
field. That assertion is rewritten rather than repaired: it was pinning
the null-semantics of the wizard's pending state, which still matters,
just with one field instead of two.
Reported by a tester: the input field in v1.5.6 had right-click actions,
the current one has no right-click at all.
Correct, and the commit before this one put those actions in the wrong
place. The v1.5.6 menu was ImRaii.ContextPopupItem("ChatInputContext")
bound to the input field itself; I hung the two token entries off the
chat-message menu, where the rest of that window's items had landed.
They are on the input field now, which is also where they are useful:
you insert a token while composing, not while reading.
Two details from the original that the misplaced version had lost:
- The agent pointers are null-checked. Both can be null during a zone
transition, which is exactly when somebody is most likely to be typing
a flag into party chat.
- Inserting refocuses the field and puts the caret behind the token.
Picking from a menu and then having to click back into the field is
the kind of friction that makes a feature go unused.
Hiding the chat is not repeated in the menu. It was in the v1.5.6 one,
but it has its own button two widgets to the right now, and one way in
is enough.
The two menu items went out with the v1.5.6 chat window in cf4705e.
Their strings stayed, in the base file only, so the feature was gone and
its labels were untranslated in all 24 other languages.
They live in the chat context menu now, next to hide-chat, which is
where the rest of that window's items ended up. The game expands <flag>
and <item> at send time, so appending the literal token is the whole
implementation; each entry is disabled while its precondition is missing
so a token cannot be sent only to expand into nothing at the other end.
ChatLog_ScrollToBottom_Tooltip is the one that stings: it has had a
caller since v1.9.0 and existed in the base file alone, so every player
outside English read that tooltip in English.
All three are translated now, and with them the resource files are at
full parity for the first time -- 25 files, every key in every one.
Every field here has a reader in the running plugin and had no control
in the window. The config file was the only way to any of them.
HideChat is the one that mattered. It defaults to on, it suppresses the
game's own chat window, and the only other path to it is a right-click
item that sets it to true and can never set it back. Anyone who used
that item once had to edit JSON to get their chat back. The new toggle
reads and writes the same field, so the two agree instead of fighting.
The rest, by tab:
- Window: the three remaining hide conditions, the preview minimum that
belongs to a toggle already on screen, native item tooltips and their
offset.
- Chat: an emotes section holding the BetterTTV switch, the cache state,
and an editor for the blocked-code list that has been in the config
since v1.0 with nowhere to edit it. Blocking one code is a finer
instrument than switching emotes off wholesale. Plus auto-translate
sorting.
- General: the failed-tell warning. The game reports a failed tell in
the log only, where somebody who is typing does not see it.
- Data & Privacy: battle messages. It decides whether battle lines are
persisted at all, which makes it a storage decision rather than a chat
one, and it sits in front of the whitelist rather than inside it.
MaxParallelPopouts stays out. It is read once in the pool's constructor,
the windows are registered once, and registering at runtime is
explicitly forbidden -- a slider would do nothing until a reload, which
is exactly the kind of decoration this cycle exists to remove.
Four new strings in all 25 languages; the other fifteen labels were
already translated and waiting.
Pinning has been complete since v1.4.7: pools, a cap of five,
persistence, logout symmetry, the notification when the cap is hit. The
menu that called it went away, and nothing has called it since.
That is not only a missing feature, it is a dead end in saved data. A
tab pinned in v1.5.6 survives every save and load and permanently
occupies one of the five slots, and there has been no way anywhere to
release it. Unpin is the reason this task exists.
So the context menu grows a pin section for temp tabs, and the sidebar
grows the marker that says which rows are pinned -- a small thumbtack in
the icon's lower left, drawn from the row's own rectangle so it claims
no layout of its own. The unread badge owns the upper right, and badges
in this sidebar are where drawing into unreserved space caught this
project last.
At the cap the item is disabled rather than hidden: that is a state the
user can undo by unpinning something, and the tooltip switches to say
which. Five translated strings that had no caller now have one.
Promote-to-permanent stays out. It was removed on purpose after a tester
kept hitting it by accident. Reconnecting every method that lost its
caller, without asking why it lost it, would rebuild the problem this
cycle is supposed to be cleaning up.
Reported after a translation pass: the channel list in Data & Privacy
reads English in every language. It was not, as assumed, the client's
own naming -- the list called ToString() on the enum member, so it
showed "FreeCompanyLoginLogout" while Language.ChatType_* sat next to it
holding "Freie Gesellschaft (An-/Abmeldung)" in all 25 languages.
Fixing the label exposed how little else the list had. Six translated
strings written for exactly this control had no caller: the explanation
of what it does, the note that it governs the database and not the chat
window, and three presets -- data minimisation, select all, deselect
all. Eighty-nine checkboxes without a "recommended" button is not a
choice anyone makes.
So the list now carries the same eight groups the export uses, with the
individual channels one fold away. It is the one control that decides
what reaches the database; the two screens describing channels the same
way is worth more here than anywhere else.
The unknown-channel switch gets its description back, and the telemetry
section stops being the last English literal in the tab. It stays a
statement rather than a switch: a toggle would imply there is something
to turn off.
Reported from the field: a new tell from someone whose tab is popped out
throws the main window onto the General tab, every time.
The router revealed the tab by activating it in the main window. That
window does not display a popped-out tab -- PickMainActiveTab re-anchors
on the next frame, and it anchors to the FIRST non-popped tab in list
order, not to the one the user was reading. So the reveal did nothing it
intended and threw away the active tab on the way.
Nothing needed revealing in the first place: the tab was already on
screen in its own window. That decision now lives in PlanTellReveal,
next to the pop-out helpers it belongs with, pure and pinned by nine
facts -- the mode, the switch and the popped-out state have eight
combinations between them and only two of them should touch anything.
ActivateTab refuses a popped-out tab outright as well. The router is the
caller that got it wrong, but the invariant belongs to the window: its
active tab is never one that something else is drawing.
The first pass through A6 caught the dead file paths and the two GDPR
sections. A review pass walked every remaining claim and found eight
more that no longer describe the plugin.
The privacy notice carries a "last reviewed" stamp and commits, in its
own text, to keeping it accurate for the version it describes. It still
said v1.1.0 after the block that rewrote two of its sections.
Both documents announced two outbound network calls in their opening
paragraphs. The Lodestone font download went away in v1.0.4 and the
notice explains that further down, so the summary contradicted its own
body. There is one call, and it is BetterTTV.
The emote cache is `EmoteCacheV1/`, which the notice states correctly in
one place and wrongly in two others, two lines above a line this cycle
had already touched.
The list of buttons that open a browser named a Ko-fi page that appears
nowhere in the source, an issue tracker and a website that have no
button, and left out the Discord invite and the two Honorific links that
do. In a section that exists precisely to enumerate where a click sends
you, both halves matter.
The README described the pop-out input bar as an opt-in under a settings
section that does not exist. Neither does the switch: PopOutInputEnabled
has no reader, the input bar is unconditional, and the field belongs on
the deletion list. Said plainly instead.
Also: the export narrows by age, not by a date range, in both documents;
the tab is called About, not Info, and it has no per-translator list;
the sections are Colours and Integrations.
Plus a note the users affected by it deserve: the v24 migration switches
the privacy filter off where it was on with nothing selected, and until
now that was only in the log.
Reported against v1.11.0: type a command, send it, need it again, and
up-arrow does nothing. v1.5.6 recalled it.
Everything needed was already in the tree. InputHistoryService holds the
last thirty entries with move-to-newest dedup, CompactInputHistoryNavigator
owns the cursor maths, and both have their own test mirrors. Neither had
a single caller, and the input field never set CallbackHistory, so ImGui
had no reason to raise the event in the first place.
So: the flag goes on, the callback grows a history branch, and TrySend
pushes the trimmed line before it clears the buffer. Editing ends the
walk, otherwise down-arrow after changing a recalled line would jump to
the next entry and discard the edit.
The cursor is per input bar while the history is global. Which line each
window is looking at is not something the others should inherit.
The worst of them made the block's own privacy promise backwards.
PrivacyPersistChannels was given a non-empty field initializer so a
fresh config would record conversations only. Dalamud deserialises with
Json.NET's defaults, which means ObjectCreationHandling.Auto: a
collection field that already holds items gets *populated*, not
replaced. Verified against Newtonsoft 13.0.3 -- saved [] loads as the
initializer, saved [Say] loads as initializer plus Say. So the change
would have unioned the privacy-first list into every existing config on
load and switched channels back on that the user had unticked, while
also making the v24 migration unreachable and its self-test vacuous. The
field is empty again and the seeding moved to CreateFresh, which only
runs when there is no config file at all.
Cleanup could delete a channel it had promised to keep. The allowlist
could only name channels that were already in the database when the
preview ran, so an unrecognised channel whose first message arrived
afterwards fell outside it. Where the failsafe is on, the deletion now
names what goes -- known channels that are not on the list -- instead of
what stays. The window closes completely, and a listed channel that
happens to be empty right now is safe for the same reason.
The cleanup preview was the one long operation that never took the
shared lock, while holding an open reader across a full-table scan.
That is precisely the case the lock was written for.
Clearing the history reported success when it failed. ClearMessages
purges the full-text index between the delete and the VACUUM; if that
step throws, the plaintext stays on disk and the user was told it was
gone. It has its own error string now, in all 25 languages.
Also:
- One busy state for the whole tab. Cleanup, clear, maintenance and
export reach the same store, and per-section flags left two
destructive buttons live at once. The lock turned that into a refusal
rather than damage, but a refusal you have to trigger to discover is
not an answer.
- The gate carries a revision, bumped by every mutating operation that
finishes. A preview taken before a retention sweep no longer passes as
current afterwards: comparing it against the settings alone cannot see
that the rows it counted are gone.
- Database metadata moved to a worker. Checking "is anything busy" first
is not enough, because an operation can take the lock in the gap
before COUNT(*) runs, and then the game stands still for a whole file
rewrite.
- The clear hint stays hidden until the count has actually been read.
"0 messages are stored" in front of the clear button is a lie told at
the worst possible moment.
- Refusal notices read the operation once. Guard and name were two reads
of the same field, so a run finishing in between printed a sentence
that stopped at the colon.
- The retention sweep cannot start twice. The gate only goes busy once
the worker reaches TryBegin, and the due-check runs every tick.
- Teardown waits up to five seconds for the store to come free rather
than disposing the connection under a running VACUUM.
- Maintenance has its own flag and says so when it is refused; reload
gets the same guard as its neighbour; the breakdown tree keeps its
open state across a language switch.
Every claim in the user-facing docs, checked against what the plugin
actually does after A2 to A5.
The two GDPR sections in PRIVACY.md describe features that only exist
again as of this cycle, so they now name the screens they live on and
say what the cleanup does with a channel this build does not recognise.
The export sentence promised a date range; the form offers an age in
days.
PRIVACY.md also named "Show emotes" in Settings as the way to stop the
one outbound call the plugin makes. That switch has had no control since
May, and a documented opt-out that only exists in the JSON is not an
opt-out, so the toggle is back in the chat tab. Both its strings were
already translated.
Dead paths: the README source tree still listed a file deleted in May,
docs/IPC.md cited a window that no longer exists, the first-run wizard
pointed at the same removed file, and the theme authoring guide sent
readers to a Themes tab that is called Appearance.
The changelog lost two double blank lines that were failing markdownlint
and holding preflight red. Preflight is green again.
Historical documents keep their old paths on purpose: the changelog and
the AI disclosure describe what was true when they were written.
Two sections that had backends and no buttons.
Database: path, size, WAL size, message count, and a clear button. The
numbers refresh at most every five seconds and not at all while a long
operation owns the store -- MessageCount takes the read lock, and asking
for it during a VACUUM means waiting for the whole file to be rewritten,
on the draw thread. The old version called ClearMessages straight from
the draw thread, VACUUM included; it runs on a worker now.
One line beyond the old layout sits above the clear button: how many
messages are stored, and that exporting keeps a copy. Whoever is about
to throw the history away should be told there is a way not to.
The legacy Chat 2 files only get a block when they are actually on disk,
and the advanced tools only appear when the section is expanded with
Shift held. The message injector is not back: it was deleted with the
tab and writing 10,000 fake messages into a user's real database is not
something to rebuild on the way past.
Retention: an "apply now" button, the running hint, and the last-run
line, which v1.11.0 shipped as an English literal while both strings sat
translated in all 25 languages. Plus reset-to-spec next to the existing
clear-overrides, since the two answer different questions and both were
already translated.
Retention_Apply_Tooltip stays unused and gets a replacement. It ends
with "Save your changes first", and the window it was written for had a
Save button.
Also here, found while wiring the manual trigger:
DbOperationGate.End now takes the operation it releases. It used to
reset blindly, on the reasoning that a worker must be able to release
from a finally without knowing whether it acquired. That is backwards: a
worker whose TryBegin was refused also runs its finally, and a blind
reset there hands away the lock of whichever operation actually holds
it. Worse than no gate, because the refused worker walks off believing
it did nothing while a VACUUM starts under somebody's open reader.
The privacy filter only decides what gets written from now on. Whatever
was stored before the user narrowed their channels stays there until
something removes it, and that something has had no button since May.
Two rules shape the section, both because this deletes history and
cannot be undone:
- Without a preview the apply button does not exist. Not greyed out,
absent. A disabled button is something a user waits for; a missing one
is something they have to go and earn.
- A preview that no longer matches the settings counts as no preview.
The old version only recoloured the number and left the button live,
so a changed whitelist could be applied against counts computed for
the previous one.
The mapping from the live rule to CleanupRetainOnly is the part worth
reading twice. CleanupRetainOnly takes one set and deletes everything
else, so it can only stand in for the live rule where that rule narrows
something: filter off means nothing is filtered, and an empty list means
a full wipe, which has its own button and its own confirmation. Both
cases now say so instead of offering a destructive action that does not
mean what it looks like.
Inside that, the allowlist is the whitelist itself plus any stored
channel this build does not recognise while the unknown-channel failsafe
is on. Deriving it from the counts instead would delete messages that
arrive on a whitelisted but currently empty channel between the preview
and the apply, and dropping the unrecognised ones would defeat the
failsafe, which exists to hold on to a new patch's channel until the
user has decided about it.
The preview runs on a worker over its own connection. It is a GROUP BY
across every stored row, the old version ran it inline on the draw
thread, and holding the read lock for it would stall UpsertMessage on
the framework thread for the length of the scan.
Cleanup_Help_SavedNote stays unused: it tells the reader to press Save
first, and the window it was written for had a Save button.
IsAllowedForStorage applied the unknown-channel failsafe to known
channels too. Untick Say in the grid, leave "Save unknown channel types"
on, and Say kept being written -- and that failsafe is on by default.
So a config that never met the wizard ran with the filter enabled, an
empty list and the failsafe on, which stored everything while the
filter's own description promised "only messages from allowed channels
are written to the database". The grid was inert for exactly the users
who had not been walked through the wizard.
The rule now reads: on the list, or unknown and the failsafe allows it.
A known channel the user did not pick stays out.
That correction alone would turn "stores everything" into "stores
nothing" for those same configs, so two things move with it:
- Config v24 switches the filter off where it was on with nothing
picked. Same behaviour as before, stated where the user can see it,
and one line in the log saying so. A config that does have picks keeps
them and starts honouring them, which is the point of the change.
- A fresh config seeds the list from PrivacyFirstWhitelist instead of
starting empty. Privacy by Default was already the documented intent;
it just relied on the hole to stay usable.
The rule lives in its own type now. Configuration implements a Dalamud
interface, and the build suite cannot load Dalamud.dll -- the runtime
resolves the declaring type before reaching the method body, so even a
static call on it fails. Fifteen cases pin the truth table and the
migration condition; the self-test checks the running config is not in
the state the migration exists to undo.
The exporter has worked since v1.4.8. The form that drives it went out
with the old settings window in May, which left PRIVACY.md promising an
access request the plugin had no way to answer.
New section in the data and privacy tab: time range, sender substring,
channel groups, format, and a save dialog. Form state lives in the tab,
not the config -- a filter describes one action, and a stale "last 7
days, sender Mira" reappearing weeks later is a worse start than an
empty form.
StreamForExport now takes a caller-owned connection. The reader stays
open for as long as the file is written, seconds to minutes on a large
history, and chat keeps arriving throughout -- so the primary connection
would be read here and written by UpsertMessage at once, and
SqliteConnection is not thread-safe. Holding the read lock instead would
trade that for freezing the game.
ChannelGroups lifts the eight groups out of the deleted tab and finishes
them: 37 of 89 channels belonged to no group and were therefore
unreachable in the UI. Game Master channels follow ChatTypeExt.Parent(),
so GmTell sits with the other tells rather than under system traffic --
an access request that quietly drops part of what it promises is the
dangerous kind of gap.
Also here:
- OpenSecondaryConnection disposes on a failing pragma. Open can succeed
and journal_mode=WAL still time out, and with Pooling=false the
connection then survives until a finalizer reaches it. Affects the
full-text rebuild worker too.
- StreamForExport builds its logger before the reader, so a throwing
CreateLogger cannot leave a reader nobody owns.
- The export thread takes the gate itself instead of the caller taking
it first. Acquiring before Start would strand the gate for the session
if thread creation failed, and the gate also holds back the sweep.
- Notifications are skipped once teardown has started. The thread has no
cancellation path and finishing the file is right, but reporting it to
a plugin that is gone is not.
- Transient widget rows that return their value instead of saving it.
Writing the config file on every keystroke of a sender filter would be
both pointless and slow.
- Five translated keys for "another database operation is running", in
all 25 languages. Two of the four operation names have no trigger yet;
they arrive with the cleanup and maintenance sections.
Two changes to MessageExporter before it gets a caller.
It read SenderSource and ContentSource, the raw SeStrings. TextValue on one
holding an auto-translate phrase reaches SeStringEvaluator, which asserts it is
on the main thread and throws unconditionally when a macro resolves a global
number. An export belongs on a worker, so that would abort it partway and leave
half a file.
The plan called for resolving text in batches on the framework thread. Not
needed: Message.Sender and Message.Content are already-resolved chunk lists --
ChunkUtil turns auto-translate into text at ingest, and the full-text index reads
them exactly this way. Same strings, no evaluator, no thread affinity, and no
batching machinery.
Second, the file handling. The format was validated after the StreamWriter was
opened, so an unknown format left a zero-byte file where a previous export had
been. It is checked first now, and the write goes to a .part file that is moved
into place at the end. A crash halfway used to leave a file that opens cleanly
and is quietly incomplete -- which on the path a GDPR access request goes out on
is worse than an obvious failure.
Almost none of this is reachable from the build suite: ExportToFile takes
IEnumerable<Message>, Message needs SeString, and xUnit cannot load Dalamud.dll
-- even an empty list fails, because the runtime resolves the parameter type
before the body runs. So the format mapping is pinned there and the rest by a new
self-test, which builds probe messages with deliberately empty SeStrings: if the
exporter ever reads them again, the text comes out blank and it fails.
The comment said PerformMaintenance inherits a five-second timeout before
throwing. It does inherit that timeout, but it is not what happens here: a VACUUM
on a connection with a live reader fails instantly with 'cannot VACUUM - SQL
statements in progress'.
That is SQLITE_ERROR, not SQLITE_BUSY. Busy handling only covers contention
between different connections, so no timeout applies and no retry helps. The
practical difference matters for the error message the UI will show: the DELETE
has already committed when it fires, so the rows are gone and only the compaction
is missing -- 'deleted but not compacted', not 'failed'.
And PerformMaintenance batches VACUUM, REINDEX and ANALYZE in one statement, so
a failing VACUUM takes the other two with it.
The check demanded csproj, repo.json and every DownloadLink carry the same
version. That is right for a published release and impossible for anything else,
so it went red the moment v1.11.0 closed -- and pre-push blocks on it.
The two states were conflated. repo.json is the distribution manifest, so its
version has to describe what the links actually serve. Claiming 1.11.0 while
every link serves v1.5.6 makes Dalamud offer an update, install the old build,
and offer the same update again on the next launch. Satisfying the old rule
meant building exactly that.
Now: the manifest must always agree with itself and with its links, and the
build must never be older than what is published. --release additionally demands
the three match, which is the mode for cutting a tag and still catches the v1.2.2
burn it was written for.
The link check moved from the csproj version to the manifest version, which is
the pairing that protects users. In the old form a manifest could name a version
none of its links served and pass, as long as the csproj agreed -- the exact
mismatch it now rejects.
Generalises the retention-sweep lock, which already solved this for a single
case: it stopped a manual sweep from racing the automatic one, and nothing else.
Export, cleanup and clear need the same protection against each other, and for a
sharper reason. An export leaves a reader open on the primary connection
deliberately outside _readLock, because the enumerator is consumed lazily by its
caller. A VACUUM starting while that reader lives meets an active reader on a
connection Microsoft documents as not thread-safe, and PerformMaintenance sets no
command timeout, so it inherits five seconds before throwing -- after the DELETE
has already committed.
TryBegin refuses rather than queues. Every one of these is user-initiated, and a
wipe that fires minutes after the click is worse than one that declines. End is
idempotent and does not check which operation ends, so a worker that throws
before acquiring can still release from its finally block.
Current is volatile because the draw thread reads it every frame to decide which
buttons are disabled. Blocking on the lock to find that out would freeze the game
for the length of a VACUUM, which is the exact failure this is meant to prevent.
Pure state machine, so the transitions are pinned without a database or an ImGui
frame -- including that exactly one of 64 competing callers wins.
messages_fts stores sender and content as plain text, and no delete path touched
it. ClearMessages, CleanupRetainOnly and the retention sweep all removed rows
from `messages` alone, so the readable text of every "deleted" message stayed on
disk.
It was self-sealing. InitFtsReadyCache treats a non-empty index as ready, so
after a wipe the index stayed full, the flag stayed true, and the rebuild that
would have cleared it never ran again.
This is not hypothetical: the retention sweep runs unattended every 24 hours,
so any user with retention on has been accumulating orphaned plain text since
the index shipped. And the plugin says otherwise in two places -- the clear
button promises "Removes all message history. Cannot be restored", and
PRIVACY.md documents targeted deletion as a feature.
Wiping the index rather than deleting matched rows, because message_guid is a
GUID string while messages.Id is a BLOB and the two cannot be joined in SQL. The
index is derived data; it rebuilds from the surviving rows on the next start,
which is both cheaper and provably complete.
CleanupRetainOnly also skips VACUUM when nothing matched, the way
DeleteByRetentionPolicy already did. Rewriting the whole file for zero deleted
rows costs seconds on a large database and gains nothing.
Six tests drive the real store against a real database, since the defect was in
what the SQL did not touch rather than in any computed value.
Measured across the whole UI rather than estimated from the settings window:
around 270 visible literals without a resource key, not the hundred the changelog
claimed. The settings window is the bulk of it, but the first-run wizard, the
input bar and the about tab carry their share.
Smoke test for the cycle came back green -- everything works and does what it
says. The untranslated strings are the only known issue.
Version to 1.11.0 in the csproj, changelog and roadmap entries for the local
state. Not published: the public release stays at v1.5.6 and the download links
are untouched.
repo.json goes back to 1.5.6.0. It had been carrying the development version
while all three download links pointed at the v1.5.6 archive, which is a trap
waiting for a merge: Dalamud would offer an update to a version the download
does not contain, install v1.5.6 again, and offer the same update on the next
launch. main is unaffected -- it only ever saw 1.5.6.0 -- but the feature
branches have been inheriting the mismatch since v1.6.0.
The manifest version belongs to what the links actually serve. A local state is
tracked by the csproj and the changelog, which is what they are for.
Testing channel deliberately not opened yet. Publishing 1.11.0 as a test build
would ship a modern settings window alongside a first-run wizard and a message
list that are still stock ImGui -- and 1.10.0 would ship the pinned-tell-history
bug that 1.11.0 fixes.
Last commit hid the header row when the title bar was on, to stop the tab name
appearing twice. The close button was in that row, and the title bar carries
none of its own -- ShowCloseButton is off because closing has to go through the
pool to release the slot. So a pop-out with its title bar on could not be closed
at all.
Pop-in moves into the input row, alongside the settings and hide buttons that
are already there. It is red, contrast-checked against the button plate it sits
on, and carries a tooltip, since a bare X next to an emoji picker does not say
where the tab is going.
Wired by setter after construction rather than through the constructor: the
window is what the button has to call, and it does not exist yet while its own
input row is being built. Routing it through the graph would close a
factory-callsite cycle MS.DI cannot detect.
The header row is now just the tab name, drawn only when there is no title bar
to carry it.
InputBar_PopIn_Tooltip ships in all 25 languages, including the Designer entry.
New strings get translated with the change from here on, not batched.
The window came out half German and half English on a German client. Thirteen of
those labels had a translated resource all along, reachable from no line of
code -- the same defect this cycle has now hit four times.
Most visible: all seven tab names in the sidebar. Settings_Tab_General and its
siblings exist in 25 languages and the sidebar drew "General", "Appearance",
"Chat" as literals. That is the first thing anyone sees in this window.
Plus reduce motion, custom sound volume, show hide button, window opacity, the
window style heading, and the themes folder button.
Deliberately left alone where the wording matched but the context did not.
"Never" exists as a world-suffix option, not as "the sweep has never run", and
"Opacity" exists for a tab rather than a window; reusing either would read
wrong in any language that inflects them differently. Those want their own keys,
not a borrowed one.
What stays English is what has no key at all: the section headings, the keybind
labels, and the descriptions written during this cycle. Roughly a hundred
strings, and adding them means 25 files each -- that is the localisation pass,
not this commit.
Three things, all visible in one screenshot.
The tab name was drawn twice. The pop-out has a title bar carrying the tab name
and a header row underneath repeating it -- the same string, one line apart. The
header now only draws when the title bar is off, which is the case it was
written for.
The close button was ImGui.Button, so it took the theme's button colours. On
several themes that is a bright magenta plate sitting next to plain text, making
the way out of the window the loudest thing in it. It uses the plugin's own icon
button now: glyph contrast-checked against the surface, danger colour on hover
only.
And the message area gets the same floor as the main log, with the same
restraint -- no accent wash, motes at a tenth. Pop-outs were the last surface
still sitting on flat background while every other window had depth.
The last six stock collapsing headers are gone, so all seven tabs now read the
same way. Appearance is the one people open most, being where the themes live,
and it was still the odd one out.
Its four components each needed only the heading, so they get a SectionRenderer
rather than the whole widget set -- SettingsWidgets would have handed a colour
editor a Plugin reference it has no use for.
Three of the six could not take a literal key. The colour editor draws its
section seven times with seven titles, so the key becomes a parameter. The theme
picker keys its categories by position, since CategoryMap is a fixed list and
the index survives those names being translated later. And the custom-theme
section takes a fixed key although its label carries a count, or it would reset
every time a theme is imported or removed.
The theme picker's headers also pick up the disabled state properly now. They
sit inside an ImRaii.Disabled while a theme is being edited, and a draw-list
header cannot see that push -- so they had stayed at full contrast while
everything under them dimmed.
The settings window no longer inherits the chat window's transparency.
GlobalStyleScope pushes one opacity for every window in the plugin, so a value
chosen to keep the chat log out of the way was also deciding how readable a
settings dialog is.
The stronger reason is that contrast cannot be computed against a background
that is not there. Behind a translucent window the real background is the game:
a black cave one minute, a snowfield the next. Every foreground measured last
commit was measured against a colour it does not actually land on. Opaque makes
that measurement true.
BgAlpha only reaches the window fill, never the draw list, so the backdrop
cannot observe it -- it takes an explicit override instead of guessing from the
pushed WindowBg.
Contrast now runs through SettingsPalette, so every row and heading gets it
without each call site asking: 4.5:1 for labels and titles, 3:1 for descriptions
and accents. The lower floor on descriptions is deliberate. It preserves the
rank between the two lines of a row, which is why the description is dimmer at
all, while still guaranteeing it stays legible.
The toggle's border is in there too. It is the only thing marking an off switch,
and a border tone that blends into the surface leaves the control invisible.
The gradient was turned down because text on the lit edge became hard to read,
which fixed the symptom and lost the effect. The real problem is that a theme
picks one text colour while the same text lands on a base surface, a lit edge
and an accent fill, and a value that reads on one can vanish on another. White
iconography on a pale violet accent was the reported case.
So contrast is computed rather than assumed. ColourUtil gains WCAG relative
luminance, the contrast ratio, and EnsureContrast, which walks a foreground away
from its background until it clears a threshold -- 4.5:1 for text, 3:1 for
icons -- and stops at the first step that does, so a colour keeps as much of its
hue as the ratio allows.
Luminance is gamma-corrected now. sRGB is gamma-encoded, so averaging raw bytes
overstates dark colours badly, and nearly every surface here is dark. Mid grey
is 0.216 relative luminance, not 0.5.
The tests caught a real error in the first version: direction was chosen by
whether the background measured below 0.5 luminance. Pale violet sits at 0.39,
counts as dark by that rule, and the function tried to make white whiter. It now
picks whichever end reaches further from the background.
With foregrounds that follow, the gradient goes back up past where it was.
Applied to the sidebar icons and labels and to the segmented control's labels.
The remaining call sites are a polish pass of their own -- this is the machinery
plus the two places that were reported.
A pinned tell tab came up empty for the rest of the session, reported by a
tester and reproduced from his config.
RehydratePinnedTabs runs from a hosted service at plugin start. It queries tell
history by character, and CurrentContentId is 0 until a character is logged in
-- LastContentId only gets set from the framework tick. The game loads plugins
at boot, so the normal path queries for character zero, finds nothing, and there
was no second attempt: the service subscribed to Logout but not Login.
It defers now when no character is available and completes on the login that
follows. The pending flag keeps a later character switch from appending a second
copy of the history to tabs that already have it.
Two things hid this. Reloading the plugin in a running session, which is what
development looks like, always has a character available. And it only shows up
if you pin a tell tab at all -- the same path for non-temp tabs already handles
the boot case explicitly, one file over:
if (pluginInterface.Reason is not PluginLoadReason.Boot)
manager.FilterAllTabsAsync();
Also surfaces FilterIncludePreviousSessions in the Chat tab, which decides
whether the log shows anything from before the current session and had no
control at all -- written only by the first-run wizard, and only if the user
reached step 3. Skip the wizard and it stays false forever. It applies
immediately rather than at next launch, since the user is looking at the window
when they ask for it.
Chat, Channels, General and Data & Privacy now draw the same way Window does. A
half-converted window is worse than an unconverted one: before, all seven tabs
were consistently dated; after the pilot, one looked current and six looked
abandoned, and switching between them made the seam obvious.
Descriptions move out of the help markers and onto the rows. Those strings were
written to be read, and a (?) the user has to hover is where an explanation goes
to be ignored. Several were translated into 25 languages and had never appeared
on screen at all.
Two settings that could not use the standard helpers -- the language picker,
which rebuilds the font atlas, and the keybind mode, whose description depends
on the selected value -- go through a plain Row that hands the caller the control
column and leaves the save logic alone.
Privacy filter labels now come from the resources that already existed for them,
same defect as the channels tab last round: strings present, translated, and
reachable from no line of code.
Four more constructors take a TokenResolver, so this wants the DI smoke pass.
Only the appearance tab still draws stock collapsing headers; its four
components are their own block.
The dithering attempt made it worse and the reasoning was backwards. Four layers
at a quarter alpha each carry a quarter of the steps each, so every layer bands
more coarsely than the single ramp did, and blending four coarse ramps adds
interference on top. Reverted.
The real variable is distance, not layer count. A ramp has as many steps as it
has distinct alpha values, so stretching it over the full height of a pane gives
each step a stripe twenty-odd pixels tall, which the eye sharpens into
scanlines. Running the same ramp over 190 pixels puts those steps a few pixels
apart, where they read as a falloff.
So: light fading down from the top edge, shadow gathering at the bottom, and a
flat surface in between. Constant alpha cannot band at all, which leaves most of
the pane immune by construction.
"Horizontal scanlines" names it exactly. An alpha ramp from 0x34 to 0 has 52
distinct values, so across a 600px pane each one owns a stripe about 12 pixels
tall, and the eye reads those stripes as scanlines. Raising the contrast only
buys more of them, thinner.
So it dithers. Four ramps at a quarter alpha each, every one ending slightly
lower than the last, so they share a starting colour but run at different
slopes. Their step boundaries land on different rows, and where one layer has
stepped up its neighbours have not, which puts the blend between two quantised
values. Same total tint, four times the effective resolution, three extra draw
calls.
Layers are staggered by slope rather than offset on purpose: shifting them would
leave a gap at the top where fewer layers overlap, which reads as a bright band.
That trades one artefact for a worse one.
The tint is roughly twice as strong now, which the settings pane wanted anyway,
and strength is a parameter so the chat log can stay at 45% of it.
Both remaining complaints had one cause. The window paints its own background,
and the backdrop was filling the same area a second time. Two stacked layers
turn a translucent window solid, which is the density over the chat log.
And an opaque fill has to carry the entire gradient by itself. That is where the
banding came from: a shallow ramp across an opaque surface crosses so few 8-bit
values that each one covers a visible stripe. Nothing sits underneath to break
them up.
So it tints now. Near-transparent white at the top, near-transparent black at
the bottom, straight over whatever the window already drew. The window colour
stays visible, the ramp only shades it, and the game showing through disperses
what little stepping is left. The sidebar does the same with a flat black wash
rather than a repainted darker surface.
Motes are roughly half as bright everywhere, and the chat log takes 10% of that.
DrawVerticalGradient stays for the segmented control, which paints a surface
that genuinely is its own rather than one already drawn underneath.
Three problems from one screenshot, and the same root cause behind two of them.
The pane painted at full opacity regardless of the window it sat in. BgAlpha
only ever reaches WindowBg, so a draw-list fill ignores it entirely, and a
deliberately translucent settings window came out as a solid block beside a
translucent chat window. The backdrop now reads the alpha out of the resolved
WindowBg colour and carries it through the gradient, the accent wash and the
motes.
The banding is 8-bit quantisation, not a rendering fault: a gentle ramp across a
tall surface crosses so few distinct values that each one covers a visible band.
Halving the range leaves fewer and fainter steps, and the translucency now
underneath them breaks up what remains.
Motes over the chat log drop to 18%. A settings page is read in glances and can
carry motion behind it; a chat log is read line by line, where anything drifting
behind the text competes with it. Intensity is a parameter rather than a second
particle system, so the two surfaces share one implementation.
The motes were too subtle to register, so: seventy instead of twenty-four, wider
radius range, and each one is a soft halo with a brighter core rather than a
flat disc. At this size a single filled circle reads as a speck of dirt on the
screen; the ring around it is what makes it look lit.
The backdrop moves into its own component and the chat log gets it too. Two
windows in one plugin looking like two separate products was half the reason the
settings window read as untouched -- the chat had been reworked in v1.10.0 and
the settings had not, and no amount of work inside one window closes that gap.
No accent wash over the message list. It works on a settings pane, where the top
of the surface is a heading; over a chat log the oldest visible messages would
sit in a tinted band and read as highlighted.
Registered transient rather than singleton, so two surfaces on screen own
separate mote sets instead of sharing one drift pattern -- which would be
visible the moment a popout sits next to the main window.
MainWindow's constructor changed, so this needs the DI smoke pass.
Brief was a mix of Lightless and Character Select+, modern without being
overloaded, and the gradient allowed to show more.
The content pane gets a stronger gradient plus an accent wash falling from the
top edge to about a third of the height. Without it the pane was a neutral box
that happened to sit inside a themed window; now the theme reaches the surface
being read.
Ambient motes drift up behind it. Procedural rather than the image sequence
Character Select+ uses, so there are no assets to ship and they take the theme's
accent instead of whatever was baked into a PNG. Fixed count, fixed arrays,
seeded once, so the layout is identical every session and nothing allocates per
frame. They advance once per frame regardless of how many surfaces call in, and
ReduceMotion skips them entirely -- same contract HoverState already honours.
The tab sidebar was the last stock-ImGui element and had started to look it. Its
entries are drawn now: darker plane than the content pane so the two read as
separate surfaces, a chamfered plate with a solid leading bar for the active
one, hover fading between muted and full text.
Its icons go through the draw list with a font pointer taken outside the scope,
rather than being drawn inside a FontAwesome push. That atlas has no ASCII
glyphs, so any label caught inside such a scope renders blank -- which has
already happened twice in this plugin, once in the tooltips and once in a badge.
Two rounds of screenshots said the same thing twice: the section headings read
against blue themes and vanished against violet ones. The cause was that their
only distinction from a normal row was a fill colour, and no fill works in every
palette.
Headings are typography now. Small caps with wide tracking, no plate, no bar,
followed by a rule that fades out along its length instead of stopping dead. The
weight comes from letterforms and whitespace, which look the same in every
theme. 18px of air above each one does the grouping that the bar used to fake.
ImGui has no letter-spacing, so DrawTrackedText renders one glyph at a time
through a stack buffer. That technique is documented in Character Select+, whose
Boutique style layer solves exactly this problem the same way.
Row separators are off by default. A rule under every row turns a settings page
into a ledger, and the hover fill already marks where a row starts and ends.
Surfaces get vertical gradients, derived from a single theme tone rather than a
hardcoded pair, so they follow whatever the active theme sets. Lerp rather than
a brightness multiplier: these surfaces sit near black, where scaling a channel
of 12 by 1.14 lands back on 13. That is what LerpTowardBlack is for.
The selected segment finally uses DrawSlipPolygon, which has been sitting in the
plugin unused since it was written, and its highlight is a second, shorter
chamfer rather than a clipped gradient -- PushClipRect is rectangular and would
have squared the cut corner straight back off.
Reference note: Lightless and Umbra were read for approach only. Both are
AGPL-3.0 and none of their code is here; a vertical gradient is common
knowledge, their implementation of it is theirs.
The converted tab had the right structure and no legibility. Five separate
causes, all of them contrast rather than colour choice.
The content pane never set ChildBg, so it inherited whatever showed through the
window, and the window is translucent by default. Settings text was sitting on
moving scenery. It gets the surface tone now; the window's own opacity still
applies on top, so the glass look survives.
Section headings had no ground of their own and floated between the rows at
roughly their weight, which meant the tab had lost its grouping entirely. They
get the raised surface, and their accent bar now runs the full height instead of
stopping at the title line.
An off toggle was filled with the same surface tone as the row behind it and
read as empty space. It gets an outline that fades out as it turns on, where the
filled track carries the shape by itself.
Two colours could not be picked statically at all, because themes here range
from near-black to pastel: the label on a selected segment, and the knob on the
track. Both now derive from the luminance of what they sit on, so neither can
end up light-on-light. That is what ColourUtil.OnColour is for.
Descriptions drop from TextMuted to TextFaint. Level with the label they made
each row read as two settings rather than one with an explanation.
The first tab that actually looks different. Everything here was stock ImGui:
framed collapsing bars, checkboxes with the label trailing on the right, and
sliders glued to the left edge with their name behind them.
Now: section headers with an accent bar, rows with the label on the left and the
control right-aligned in its own column, sliding switches instead of checkboxes,
and a segmented control where two radio buttons used to pretend to be two
settings when they are one.
Three of the four widgets built in this cycle had no call site outside the debug
gallery. That is the exact defect that triggered v1.10.0 -- five tools built and
never wired up -- and the spec rule written afterwards says no widget without a
call site in the same cycle. This closes that on the pilot tab; the remaining
five follow one at a time.
The row helpers live in SettingsWidgets so the other tabs get them unchanged,
and the theme lookups go through SettingsPalette, cached per frame: twenty rows
would otherwise resolve the same five tokens twenty times over.
Section keys are u8 literals rather than the visible titles. ImGui's own storage
keys collapsing headers off the label, which would reset every section's open
state on a language change and merge two sections whose titles translate alike.
Note WindowTab's constructor gained a parameter, so this needs the DI smoke pass
before the next tab follows.
/emotes/shared/top now answers 403 with {"message":"unauthorized"}. Nothing
checked the status code, so that object was handed to a List<Top100>
deserializer, which threw on the very first character on every plugin start.
The throw escaped the whole loader, so the 65 global emotes -- fetched
successfully one call earlier -- were discarded along with it, and State went
back to Unloaded, arming the same failure for the next trigger.
A failed page now stops paging and keeps what the global endpoint returned. The
global call itself still throws when it fails, because without it there is
nothing to keep.
Two smaller hazards on the same path: an empty page would have made Last() throw
rather than end the loop, and a null deserialization result was dereferenced
outright. Both end the loop now.
Logged as a warning, not an error. This is a third-party endpoint changing its
access policy, not a fault in the plugin, and it does not need a stack trace in
the log at every launch.
Three of the four first-run profiles switch the retention sweep on and write a
per-channel deletion policy. The window only ever showed the global default, so
whatever the wizard decided about individual channels was invisible from the
moment the wizard closed.
The tab now lists every channel whose retention differs from the global value,
tagged by where the number comes from, plus a button to drop the custom ones. It
also finally uses the strings written for this screen, sweep description and
default help included.
Read-only, deliberately. Zero means "keep forever" as a global default and
"delete this channel's entire history" as a per-channel value, because the
default takes a separate SQL branch while a mapped channel gets cutoff = now. No
shipped profile contains a zero and no UI could set one, so nothing is broken
today -- but an editor cannot be offered until those two meanings agree. Noted
at the branch in DeleteByRetentionPolicy.
The default slider now goes down to 0, which is the value that means "never
delete anything". Its own label has been promising "0 = never" while the slider
started at 1.
Six settings had a control, a saved value, translated labels, and no reader
anywhere in the plugin. Flipping them changed a byte on disk and nothing else.
Three sat next to each other in the Chat tab under timestamps, so the section
read as four related options where only one -- the 24-hour clock -- works.
FormatTimestamp consults nothing else.
The first-run wizard offered one of them too, on its visual step, and listed it
back in the summary as if it had been applied. That is the first screen a new
user sees, so it goes as well.
Their own strings show how long this has been drifting: the wizard called
PrettierTimestamps "relative time", the settings tab called the same field
"modern layout". Two different features, one boolean, neither implemented. That
is also why these are removed rather than wired up -- there is no single
behaviour to restore, and inventing one belongs in a cycle that plans it.
Config fields stay, with a comment. A stored value should survive until the
rendering it describes exists, and dropping them would silently reset anyone who
set them.
Found by an audit that turned up considerably more of this: 433 of 824
translated resource keys reach no code at all, and the export, cleanup, tab
editor and pin paths are complete but unreachable. That is its own cycle; this
commit only clears what actively lies to the user in the window we are working
on.
Three more instances of the pattern the previous fix only half caught.
The section header clipped its description and not its title, so a translated
heading wider than the pane ran out over the scrollbar. Only the window clip
rect stopped it, not the content width.
Row's separator used an unscaled 1px offset with a scaled stroke. ImGui strokes
centred on the path, so at UI scale 2 half the line sits below the rectangle the
row reserved -- and rows stack flush, so it landed in the first pixel row of the
next one. Offset now derives from the thickness.
The segmented control claimed in its own comment to share the setting row's
contract. It did not. It took a position as a parameter and then re-pinned the
layout cursor to it, which moves a caller's layout whenever that position was
not the cursor, and it advanced by the full height where the other two subtract
ItemSpacing.Y. It now reads the cursor like they do, and the comment says why
the advance still differs: those two stack flush because they are list entries,
this is a single control and takes the normal gap.
Also: the label centres against the control band when it has no description
below it, since a slider draws its text at FramePadding.Y and a top-aligned
label sits visibly high next to it. Gallery arrays are held rather than rebuilt
per frame, which its own comment already demanded two sections earlier. And
SectionHeader.Reset is gone -- no caller, and section state keys off ids rather
than labels, so nothing needs to clear it on a language change.
The shared label buffer was handed to ImGui.Combo whole, with the value count as
the fourth argument. That argument is not the item count -- it is
popupMaxHeightInItems. The count comes from the span's own length, which was
always 8.
So every enum combo listed eight rows. A three-value setting showed five blank
ones below its real entries, and the popup was capped at three rows high, so it
scrolled. Clicking a blank row hit the range guard and silently did nothing.
Five combos were affected: world suffix, name form, command help side, preview
position and tell auto-open mode. The per-tab code this replaced sized its array
to the value count, so the count happened to be right; sharing one buffer is
what exposed the misread parameter.
Slicing the buffer fixes both halves at once: the span carries the real count
and popupMaxHeightInItems falls back to its -1 default.
Also moves Lerp below LerpTowardWhite. It was inserted directly under that
method's comment block, TEST-MIRROR line included, so the documentation sat on
the wrong method.
Twenty resource keys existed, were translated into all 25 languages, and were
reachable from no line of code. The tab drew hardcoded English literals instead,
so a German player read "Enable auto-tell tabs" while the German string sat in
the plugin unused. This is the same defect as the three unreachable settings
earlier in this cycle, one level down: the work was done, the wiring was not.
The literals were also worse than the strings they shadowed. "Enable auto-tell
tabs" against "Automatically open a tab per conversation partner for every
/tell", and every setting had a written description that had never been shown at
all, so nothing in the section explained what it did.
Two of those are worth more than the labels. The conflict hint names the one
setting in another plugin that silently stops auto-tell tabs from ever opening,
which is not something a user works out alone; it is on screen now. The sidebar
width description explains what the 44px default actually means.
The keys carry stale prefixes from the old eight-tab layout -- the preload one
still says Privacy_ though the setting lives here. Renaming them would touch 25
files per key, so they keep their names and the strings go on screen now.
Both widgets drew their description with a wrap width and then sized the row as
if it were always one line. Same bug, two different symptoms.
A setting row clips to its label column, so the second line was simply cut off,
directly under a comment claiming the text wraps rather than being cut. A
section header has no clip rect at all, so the overflow was drawn over its own
border line and into whatever the caller rendered next.
Both now measure with CalcTextSize against the same wrap width they draw with.
The section header also gained the clip rect it never had, and its lead offset
is computed once instead of twice, so the measured width and the drawn width
cannot drift apart.
Third fix, same family: the segmented control relied on its last InvisibleButton
to leave the cursor in the right place. It happened to work, because the loop
re-pins the cursor before every segment, but a caller cannot see that from the
outside -- and the gallery duly reserved the row a second time with Dummy,
doubling the gap after every segmented control. The widget now owns its advance
explicitly, like the other two, and CalcSize is gone with its only caller.
Six tabs carried a byte-identical DrawToggle, four a byte-identical slider, and
five hand-rolled the same enum combo loop. 281 lines out, 82 in.
The combos were not only duplicated, they were wasteful: each one called
Enum.GetValues inside Draw, so every open settings window allocated five arrays
per frame for sets that cannot change at runtime. EnumValues<T> reads them once
per closed generic, and the label array is one buffer shared by all of them.
Two behaviours are now uniform rather than accidental. The range check on the
selected index existed in exactly one of the five and is now in all of them,
and the tell auto-open combo lost its inline literal array in favour of a Name
extension like its seven peers -- still English, but at least in the place the
localisation pass will look.
SettingsWidgets is constructed by each tab rather than injected. The tabs are DI
singletons and a seventh constructor signature change buys nothing here.
One visible difference: the tell auto-open combo was 220px wide against 200 for
every other combo in the window. It is 200 now.
Six settings across the window only apply while another one is on. Today they
sit at full contrast and simply do nothing when clicked.
BeginDisabled cannot carry this: it pushes an alpha that ImGui applies inside
its own widgets, and every part of a setting row that a user reads -- label,
description, separator, hover fill -- is draw-list output that never sees it.
So the row fades itself, drops its click, and stops tracking hover.
The flag is passed through to the control callback as well. A draw-list control
handed into the row has exactly the same problem and no other way to learn about
it.
Note the parameter sits before styleOverride, so the one existing positional
call site had to name its argument.
WindowTab picks its layout with two radio buttons that are one setting wearing
two labels. A setting row knows one label and one control, so the choice was
either two rows that misstate the relationship or a control that holds the whole
choice. This is the latter, and it generalises to any small closed set.
Segment bounds come from rounded edges rather than a per-segment width. At 201
pixels over two segments the naive form paints two 100.5px halves that land on
the same physical column, which leaves a seam in the middle and a gap on the
right. Deriving each edge from the run means segment i ends exactly where i+1
starts.
Hover keys are derived per segment for the same reason the toggle derives its
own: the caller has already spent its id on the enclosing row, and sharing it
would tie the row highlight to whichever segment the mouse is over.
Disabled is a parameter rather than a BeginDisabled scope because that alpha
never reaches draw-list output. The invisible buttons are still submitted while
disabled so item count and cursor advance do not change between the two states.
MetricsMath gains Center, which is what CenterY always was underneath. Reusing
CenterY to centre text horizontally would have read as a bug at every call site.
Replaces ImGui.CollapsingHeader, whose framed bar is the single most
ImGui-looking element in the settings window -- 25 of them across nine files.
State lives in the widget, not in ImGui's per-window storage. ImGui keys that
off the label, so once the section titles are localised the open/closed state
would reset on every language switch, and two titles that translate to the same
string would share one state. Callers pass a stable key built from an ASCII
literal instead.
The disabled parameter is not optional decoration. BeginDisabled pushes an
alpha that only reaches ImGui's own widgets, so a draw-list header would sit at
full opacity while everything around it fades -- and ThemePicker wraps two of
its headers in exactly that.
Cursor advance goes through ImGuiP.ItemSize like SettingRow, so the scrollbar
sees the full height.
The gallery shows all three states, including the disabled one inside a real
ImRaii.Disabled scope, which is where the alpha problem would otherwise only
surface in the theme picker.
Review of the two new widgets found four things that would all have landed on
the first real tab.
SettingRow had no hit area and no return value, so "the whole row is clickable,
label included" -- which is the point of pairing it with a switch -- was not
reachable. The label half is now an InvisibleButton and Draw returns whether it
was clicked.
SetNextItemWidth is a silent no-op for Checkbox, RadioButton and
InvisibleButton: they size themselves from GetFrameHeight and never call
CalcItemWidth. So exactly the controls the settings tabs are full of would have
sat at the left edge of the control column, 200px from where the row promised
to put them. The callback now receives a context with AlignRight for widgets
that know their own size.
The switch and the row shared a HoverState key. An enabled switch would have
kept its row permanently highlighted, and hovering a disabled row would have
slid its knob to "on" -- the widget lying about its own value. ToggleSwitch
derives its animation key now, so a caller cannot collide even by passing the
same id to both.
The cursor advance moves from SetCursorScreenPos to ImGuiP.ItemSize. Both
advance the cursor, but only ItemSize is guaranteed to extend CursorMaxPos,
which is what the scrollbar measures. SetCursorScreenPos happens to do it on
ImGui 1.88, which is what Dalamud ships -- upstream removed that in 1.92 and
asserts on the pattern instead. ItemSize does not touch g.LastItemData, so the
save throttles stay intact.
Two smaller ones: the label column no longer collapses to a single pixel on a
narrow row (it stops at 60 and the control shrinks instead), and the toggle
geometry clamps its radius once rather than deriving travel from an unclamped
value. Descriptions wrap now instead of being cut at the column edge.
The gallery gained the pairing both widgets exist for, plus a style-override
variant -- the combination that would have exposed all of this.
Two composites for the settings window, both built on the primitives from
v1.10.0 rather than beside them.
SettingRow puts the label left and the control right-aligned. ImGui does it the
other way round, control first and label trailing, which is a large part of why
the settings window reads as a form dump rather than a settings page. The
control arrives as a callback so one row covers toggles, sliders, combos and
buttons.
The cursor advance in SettingRow is the part that needed care. It has to happen
after the callback, because ItemSize overwrites CursorPos outright when the
control is submitted -- advancing first would simply be undone. But it must not
be an ImGui.Dummy: that submits an item and would replace the control as
g.LastItemData, silently disabling every IsItemDeactivatedAfterEdit save
throttle in the window. SetCursorScreenPos moves the cursor without touching
last-item state.
ToggleSwitch is a capsule with a gliding knob, driven by HoverState so it
animates instead of snapping. Unlike a slider there is no throttle to preserve:
a checkbox commits on the click itself. The caller owns the hit area, so a
settings row can make the whole row clickable, label included.
Named ToggleSwitch, not Toggle: Dalamud's Window base class already has a
Toggle() method, and the plain name collides in every window that uses the
widget.
Geometry lives in WidgetGeometry as usual, with nine new cases pinning the
right-alignment split, the narrow-row fallback (the label yields before the
control does), and that the knob stays inside its capsule at both ends.
ColourUtil gains a two-colour Lerp for the track crossfade.
Review of block A found three things a German user sees straight away.
Two of the three new controls hard-coded English labels although translated
resources already existed for exactly them: Options_PlaySounds_Name and
Options_KeybindMode_Name are in all 25 files. So "Sprache" sat directly above
"Play sounds". The help marker now uses Options_PlaySounds_Description too.
The settings window title was baked in at construction, so it kept whatever
language the plugin started in. Every other string re-reads per draw; this was
the one frozen one. A PreDraw override refreshes it.
Three smaller items from the same review:
The comment on the language order was wrong in both halves. None never reaches
the sort -- it is filtered out and pinned to the front -- so the "list would
jump" hazard it described cannot happen, and the count was 25 endonyms, not 24.
Left as-is it invited someone to swap Where and OrderBy, which would make the
order depend on the culture the game started in.
The rebuild comment claimed thread affinity made it safe. It does not: the
rebuild disposes the very font handle that Plugin.Draw has pushed for the
frame. It works because Dalamud holds the ImFont under a per-frame lock, and
that is now what the comment says. The help marker also warns that switching
rebuilds the atlas and where to clear accumulated glyph ranges.
ApplyLanguage gets an equality guard. Combo only reports real changes, but a
font atlas rebuild is expensive enough that no future caller should be able to
trigger a no-op one.
ChatTab lost its last ChatType reference with the deleted grid, so the using
went too.
All three drive real behaviour and have translated labels in all 25 language
files. None of them had a control anywhere in the UI -- they were lost in the
v1.6.0 window rewrite and nobody noticed, because the config kept working with
whatever value happened to be stored.
Language picker. This is the one that needed care: a combo alone would have
been wrong twice over. LanguageChanged is an instance method, not static, and
its parameter only matters when the override is None -- it reads the config
itself otherwise. Passing picked.Code() there yields "", so "follow Dalamud"
would have silently meant English. Startup gets this right and is copied.
More importantly the glyph ranges. Their activation used to live in
Settings.Apply, a class that has not existed since v1.6.0; the comment at
Plugin.cs:290 still points at it. Without OR-ing the required range in and
rebuilding the font atlas, switching to Korean renders empty boxes until the
plugin reloads. Four steps, in this order, and the order is forced: the culture
switch reads the config, the atlas rebuild reads the glyph ranges.
Sound toggle. Gates both the per-tab notification sounds and the UI click
sound. It even has a self-test, just no switch.
Keybind mode. Strict versus flexible modifier matching. It has Name() and
Tooltip() per value, so it was demonstrably a control in v1.5.6.
The language order is sorted once into a static: 24 of the 25 endonyms are
fixed literals, so the order does not depend on the current culture, and
recomputing it per frame would make the list jump the moment None's own label
changes.
"Show novice network" moves to Behaviour on the way past. It is a display
filter, and it was the only entry under "Notifications" -- which now holds the
sound toggle it was named for.
Three settings were rendered in two places at once, and the third is the one
that matters: the entire 89-entry channel grid existed twice. ChatTab's
"Channel filter" section and DataPrivacyTab's "Privacy filter" section wrote
the same HashSet through near-identical code, differing only in the ImGui id
suffix. Whichever one the user found first, the other silently showed the same
state.
ChatTab's section is gone entirely. DataPrivacyTab is a proper superset of it
-- it additionally carries PrivacyPersistUnknownChannels -- so nothing is lost.
PrintChangelog keeps only its General entry, where it belongs: it is start-up
behaviour, not privacy.
The lock-ordering comment moved before the deletion. DataPrivacyTab's version
was "see ChatTab for the ordering", a cross-reference to the file being
removed; the actual reasoning only existed in ChatTab.
Style foundation cycle closed. Smoke tests green across the sidebar, the tab
strip, the status bar, the theme preview and both message densities.
Download links stay on v1.5.6 deliberately: v1.6.0 through v1.10.0 are local
development states and nobody should update into one. The README badge stays
there too, since it points at the published release.
The roadmap now reflects the actual sequence -- the old "next cycle" entry
still named v1.5.7 ad-block, which has been behind the v2.x UI rebuild since
May.
Verified file by file: csproj, repo.json (both assembly versions, links
untouched), CHANGELOG, ROADMAP. Four TODOs remain in the tree, all pre-existing
and none from this cycle.
The three quick-button tooltips were hard-coded English while the rest of the
UI goes through HellionStrings. All 25 resource files now carry them, machine
translated on Flo's go-ahead.
Verified: every file still parses as XML, and the base file stays English so a
missing language falls back to what was there before.
Two things Flo hit on the first run.
The context menu threw on EndPopup. The spacing guard added in 929188e was a
`using var`, which disposes at the end of the method -- after EndPopup. ImGui
asserts when a popup closes with a style var still on its stack. The body moved
into a scoped block so the pop happens inside the popup.
The quick-button tooltips were empty boxes. SetTooltip ran inside the
FontAwesome push, and that atlas has no ASCII glyphs, so the text had nothing to
render with. ImRaii.DefaultFont did not save it. The hovered label is collected
now and drawn after the font is popped. Same trap as the unread badge in C5,
different place.
Those three tooltip strings are still hard-coded English while the rest of the
UI is localised. Pre-existing, and adding resources means touching 24 language
files, so it is noted rather than fixed here.
The preview still picked its colours by hand: SurfaceHover for the active row
where the sidebar uses SurfaceActive, and a plain surface for the pills where
the status bar uses SurfaceRaised. Since SurfaceActive was just raised from
0.1 to 0.25, the preview showed a noticeably different active row than the one
next to it.
It resolves through TokenResolver now. Copying the lerp formulas is how it
drifted out of sync to begin with.
Review of block E found the pill height locked to its design value.
WidgetGeometry.Pill discarded the measured text height, so a pill was always
22px times display scale -- and Config.FontSizeV2 does not feed into display
scale. At 18pt the 24px line no longer fit its 22px pill, at 20pt the text left
the reserved strip entirely. Both sizes are in the plugin's own font list.
Height is a floor now, and the text plus vertical padding wins when it is
taller. At the default 12.75pt the floor still applies, so nothing moves.
Only the right-hand version slot checked whether it had room. At 150% scaling
with the window at its 480px minimum -- which stays reachable, because the size
constraint is not scaled -- the counts and tells pills simply ran off the edge.
Every slot checks now.
Pill.Draw returns the size it drew, so the status bar no longer measures each
slot twice. That also removes the risk of the drawn and returned widths
drifting apart if a style override ever reaches only one of the two calls, and
it cuts the lock glyph from three font pushes per frame to one. A font push is
not free: it allocates a lock object and queues a deferred dispose.
Smaller items: the version string is built once instead of per frame, the glyph
cache from IconButton is now in Pill as well, and five metrics constants plus
two usings that lost their consumers in E1 and E2 are gone.
Reviews of blocks C and D found five things a user would see immediately.
Row fills ignored the window's own opacity. Theme surfaces are fully opaque,
and GlobalStyleScope zeroes ChildBg below full opacity so WindowBg alone
carries the coverage -- with the default of 0.85 that made the sidebar a solid
block inside a translucent window. Idle rows now draw no fill at all, and the
active and hover fills are scaled by the current window opacity.
The unread badge landed on the tab icon at the default sidebar width of 44px.
Right-aligning it needs roughly 70px for one digit and 90px for three, and the
old placement also subtracted the popout column even when there was no popout
button. It is only drawn where it clears the icon; below that a plain dot takes
over, which is what the sidebar did before this cycle anyway.
The same collision existed in the top-tab strip, worse: the badge sat in the
trailing padding, which is 10px against a badge at least 14px wide, so it
covered the label on every tab that had one. The badge is part of the tab width
now, and vertically centred rather than top-aligned.
The context menu's spacing guard read the pushed zero back out of GetStyle, so
the max never did anything and X stayed at zero -- which is what HelpMarker's
SameLine uses, so the "(?)" clung to its label. It sets both axes outright now.
Section captions had all their padding above them and one pixel below, so with
zero item spacing the next row started immediately under the text.
Three smaller items: the tab icon was centred against the text font's line
height although FontAwesome is a fixed-width handle that ignores
Config.FontSizeV2; IconButton interpolated a label string per button per frame,
now a PushID over a u8 literal; and the alpha scaling that had grown four
copies now goes through ColourUtil.ApplyAlpha everywhere.
SurfaceActive was Lerp(Surface, Primary, 0.1f), picked when no production code
drew the token. Against the real sidebar it is barely distinguishable from
SurfaceBase, so the active row was identifiable only by its 2px accent bar --
which is not what "the active tab is unmistakable" was supposed to mean.
0.25 keeps it clearly a surface rather than a coloured block, and stays
distinct from SurfaceHover, which is its own theme slot rather than a
derivation.
Worth a look across all themes during the smoke test: the lerp target is
Primary, so themes with a very light primary will move further than the dark
ones.
What blocks A to E did not already touch: the honorific header height and its
two offsets, the message list dummy widths, and the quick-button reserve in the
input bar.
The reserve is the one with visible consequences. At 150% the buttons grow with
the font while a fixed 130px column does not, so they stopped fitting.
The honorific offsets are centred rather than scaled. The 8f there was
(30 - 14) / 2 for the old font, structurally the same case as the sidebar: a
scaled constant keeps its mis-centering, a computed one does not.
The preview had been showing surfaces, an accent bar and an unread marker for
months while the real sidebar drew none of them. Now that the sidebar has
caught up, the preview is the one that is wrong -- in two specific ways.
It put the accent bar on row 0 and the raised surface on row 1, so it showed
two half-active rows instead of one active row. Both now sit on row 0, and the
rows get the separator the real ones have.
The unread marker was a 4x4 square. It is a rounded count badge now.
The status bar preview was a separate 20px reimplementation with three coloured
squares and a hard-coded label. It mirrors the pill layout instead, with the
status colours riding along as slot dots so a theme still shows what it does to
them.
Five slots drawn as flowing text with a TextDisabled interpunct between them.
They are pills now: channel with its status dot, privacy with its lock glyph,
counts, tells, and version right-aligned.
The composite texts stay composite. FormatCounts produces "5 tabs · 1.2k msg"
and the version slot "v1.10.0 · Hellion" as single strings, and splitting them
would have gained nothing while breaking their pinned format.
Height derives from the pill rather than sitting beside it as a second
constant. MainWindow reserves the body against this property, so the two
drifting apart is the entire failure mode here, and a pill is taller than a
bare text line.
The right-hand slot's fit check actually measures now. The old one compared the
region against a flat 200px and never looked at the left-hand slots at all, so
at the 480px minimum width it kept drawing the version while the left run
needed more room than was left -- the overlap predates this change.
Pill grew optional icon support for the privacy lock. Without it that glyph
would have been silently dropped in the move.
StatusBarCacheTests is re-enabled. It sat in the csproj Compile Remove block,
so the format contract this commit reshapes around had no live net at all. Two
of its cases construct StatusBar with null services, which is safe because
SnapshotForTest touches neither.
The pill was already hand-drawn here -- filled rect, rounding 6, a frozen 3px
text offset and an InvisibleButton over the top. That is the Pill widget, built
before the widget existed, so it becomes the widget's first consumer. Its text
now centres against the measured line height instead of the frozen offset.
InputBar.Height moves to Metrics as well. MainWindow and ChannelPopoutWindow
both reserve their body height against it, so both follow without changes. It
had to happen in the same commit: the pill inside the bar now scales, and a bar
that did not would have clipped it at 150%.
Review of block B found Query allocating an entry for every element it was
asked about, hovered or not. The cycle: Query creates the entry, the next
BeginFrame steps it to zero, evicts it, and the next Query creates it again.
With fifteen tabs that is fifteen allocations plus fifteen dictionary inserts
and removes per frame, permanently, with the mouse nowhere near the window.
That is exactly the property master spec 7.5 asks for and the one this block
claimed to improve, so it ate the two string allocations 31fa410 had just
saved. An unhovered element with no entry now returns zero without creating
one.
The footprint self-test only ever queried with hovered: true, which is why it
could not see this. It now runs an idle phase as well.
Four smaller items from the same review:
Advance skipped clearing the hover flags when deltaTime was zero, so such a
frame carried the previous frame's state forward.
Metrics reads GlobalScaleSafe now. The unsafe variant throws while the
interface manager is still coming up, and block F pulls Metrics into more call
sites.
Badge.CalcSize returned a full-size box for a count of zero while Draw drew
nothing, so a caller that reserves and then draws left a badge-shaped hole on
every tab without unread messages -- the normal case.
IconButton caches its glyph strings; ToIconString allocates on every call and
keeps no cache of its own. And the widget gallery clamps its own row width,
since asserting on a zero-width button in the window that demonstrates the
clamp would be a poor look.
TopTabBar had no observability at all -- no counter, no self-test reaching it.
It now exposes LastRenderedUnderlineCount and MainWindow hands the component
out the same way it already does for the sidebar.
Three cases: one of two tabs active draws exactly one underline, a null active
tab draws zero, and an active tab that is not in the list also draws zero. The
last one matters because the strip skips popped-out tabs, so the active tab
legitimately need not be among the drawn ones.
The strip was ImGui.Selectable sized to the bare text width, with a red dot
hanging off the item rect. Six things had to be rebuilt by hand, and the first
is the one that mattered most.
Selectable did have an active fill (ImGuiCol.Header, fed from the theme), so
this replaces a fill rather than adding a marker to something bare. The fill
stays and the accent underline comes on top -- swapping one for the other would
have made the active tab harder to spot.
Tabs now have their own height derived from the measured line height plus
padding, so the strip no longer collapses onto the text. Hover runs through
HoverState like the sidebar, and the label has three states: active and hovered
in Text, idle in TextMuted.
The unread marker is a count badge in AccentEmber, and its position had to be
recomputed: Selectable inflated its bounding box by half the item spacing on
every side, so reusing the old GetItemRectMin/Max maths against an
InvisibleButton would have made the marker jump.
Click semantics follow InvisibleButton's return value, which fires on release
like Selectable did. IsItemClicked would have fired on press, a silent
behaviour change.
The trailing Separator becomes a LineDivider, so both layout modes draw the
same rule.
Drives the real Sidebar.Draw and reads the render counter, so a regression in
the draw path fails instead of a parallel calculation passing.
Three cases: one of two tabs active draws exactly one surface, a null active
tab draws zero, and icon-only mode still marks the active row.
Zero is a legitimate state, not a failure -- PickMainActiveTab returns null
when every tab is popped out, so the invariant is "at most one", not "exactly
one".
The unread marker was a 4px dot in StatusDanger. Red reads as an error, and an
unread message is not one. It is now a count badge in AccentEmber, which is
what the theme preview in settings has always shown.
It has to be drawn outside the FontAwesome scope: that atlas carries no ASCII
digits, so the number would have come out blank inside it. The icon width is
still measured inside the scope and handed out.
Placement follows the mode. Expanded puts the badge right-aligned ahead of the
popout slot, where a three-digit count still fits; icon-only keeps it over the
icon like the old dot.
The frozen vertical offsets go at the same time. The 8f was (32 - 16) / 2 for a
16px font and stayed wrong at every other Config.FontSizeV2, which display
scaling does not feed into. Both the icon and the label now centre against the
measured line height, and the label starts after the measured icon width
instead of a hard 32f.
Both were hand-rolled: an InvisibleButton, then a glyph pushed through the
FontAwesome handle onto the draw list, with a frozen 8px vertical offset and a
4px inset. IconButton does the hit area, the hover fill and the centred glyph,
and centres against the measured line height instead of the frozen offset.
Their order is unchanged. Both still sit after TabContextMenu.Draw, which is
the ordering the popup trigger depends on, and the caller keeps what actually
differs between them: cursor placement (SameLine vs. absolute), the visibility
rule, the glyph choice and the greeted glyph counter that
SidebarGreetedGlyphStep pins.
The popout glyph now follows the row surface rather than rowHovered ||
popHovered. That pair needed the button's own hover state one line before it
existed, and the button sits inside the row anyway, so the row's hover covers
both cases.
The sidebar drew a hover sweep, an icon and a label per row and nothing else.
No hover fill, no active fill, no accent bar, no separator -- the active tab
was visually indistinguishable from the rest. The theme preview in settings has
been showing all of it for months without the real sidebar delivering any.
Rows now go through the Row widget: base surface, active surface, hover
interpolated between them, a 2px accent bar on the active row and a bottom
separator.
Hover is detected with IsMouseHoveringRect, not IsItemHovered. The row button
is up to two hit widths narrower than the row itself (popout slot, greeted
slot), so a full-width surface driven by the item would flicker at the edges.
AllowWhenBlockedByActiveItem is required on the window check, otherwise the
fill disappears the moment the button is pressed, because InvisibleButton owns
the active id by then.
ItemSpacing is pushed to zero around the row loop so surfaces sit flush instead
of leaving a stripe of window background between them. Style vars are a global
stack and the context menu inherits them, so TabContextMenu now restores a
normal spacing inside its popup -- without that its entries would touch.
The row surface is drawn strictly with draw-list calls between the row button
and TabContextMenu.Draw, which is the ordering the popup trigger depends on.
Separator plus TextDisabled took all of their vertical breathing room from
ItemSpacing. The next task pushes ItemSpacing to zero so rows sit flush, which
would have collapsed the header onto its neighbours.
LineDivider carries its own padding and submits its own layout item, so it no
longer depends on the surrounding spacing at all. The compact branch keeps
suppressing only the caption, and LastDrawnSectionHeaderCount still increments
exactly where the caption is drawn -- SidebarSectionHeaderStep pins it at 2
with compact off and 0 with compact on.
The sidebar constants were raw pixels. At 150% display scaling the text grows,
the column does not, and the row contents stop fitting.
GetWidth and IsExpanded stay unscaled on purpose. The stored width and the
switch threshold are user settings in design pixels, and
SidebarModeAutoSwitchStep compares GetWidth's return value against the raw
bounds with exact equality -- scaling there would fail the step at anything
other than 100%. Scaling happens once, at the single draw call site.
RowHeight and the two hit widths now come from Metrics. The row internals read
GetContentRegionAvail, so they follow automatically and the hit-area split
thresholds stay proportional.
The not-ready branch is scaled too: a scale change triggers a font rebuild, so
that branch really is hit while GlobalScale is moving, and an unscaled width
there makes the sidebar jump.
The width slider referenced the bounds as literals. It now uses the constants,
so it cannot drift away from the clamp.
Known remainder, deliberate: SidebarAutoSwitchThresholdPx is compared against
real screen pixels while the columns now scale, so the switch point drifts at
high scaling. Scaling it would fail the same SelfTest. Noted for v1.11.0.
Review of block A found two regressions the settle gate introduced.
Density and the two name modes are switches, not sliders. They land on a new
value in one frame and stay there, but the gate made them wait 200ms like a
drag. Meanwhile the row painter switched instantly, so for about twelve frames
the planner ran compact rows against card heights: wrong slice, wrong offset,
and the visible rows got overwritten with the new density while everything
else kept the old one. Before the gate this was correct, so it was a
regression, not a pre-existing bug. The fingerprint now separates a discrete
axis that applies at once from the continuous one that waits.
Second, the cache did not actually stand still during the wait. Measurements
were written back unconditionally, so a resize drag mixed heights from many
different widths and the lead dummy drifted for the whole drag. The gate now
exposes IsPending and the planned path skips the write while it is set. The
linear path still measures, because without a filled cache there is nothing to
plan against.
Three smaller items from the same review:
An oscillation slower than the settle window used to bypass the wait entirely,
because the pending clock was never reset on the way back to the applied value.
A value that changes on every frame could hold the gate shut forever while the
applied fingerprint stayed wrong. MaxWaitMs is the deadline, checked before the
still-moving branch so a permanently moving value actually reaches it.
The row painter was passed as `compact ? DrawCompactRow : DrawCardRow`. Both
are instance methods, so the method group captures `this` and Roslyn does not
cache it: 64 bytes per frame per window. Bound once in the constructor now. The
per-frame height array is also reused rather than reallocated, which at the
default MaxLinesToRender was 10 KB per frame on what A2 had just made the
default path.
Every widget in its states, reachable via /hellion widgets. The point is to
check them one at a time before they land in real components: the v2.x style
engine grew three primitives that were never wired to a call site
(DrawGlowBorder, DrawSlipPolygon, DrawHonorificHeader), and this is the cheap
way to notice that before a cycle closes.
DEBUG-only, like SeStringDebugger. It is a verification aid, not a feature, so
it never reaches a release build -- verified against a Release compile.
The header line also shows the live GlobalScale and the hover registry size,
which makes both the scaling work and the eviction contract observable while
dragging the Dalamud scale slider.
Five widgets, each with a real consumer inside this cycle: Row for sidebar
rows, Badge for unread counts, IconButton for the popout and greeted toggles,
LineDivider for section headers, Pill for the channel pill and the status bar.
Row carries no Tab on purpose. v1.11.0 moves the sidebar from tab rows to
channel rows, and if the chrome sits in a Tab-free widget that cycle only has
to change the caller.
IconButton is deliberately small. Its two sidebar call sites differ in
placement, visibility rule, glyph choice, and one of them bumps a SelfTest
counter. Taking all of that as parameters would produce a widget that is five
switches and no behaviour, so the caller keeps them.
LineDivider brings its own vertical padding and submits its own layout item.
The sidebar is about to push ItemSpacing to zero so rows sit flush, and a
divider relying on spacing would collapse onto its neighbours there.
Colours go through WidgetPalette. TokenResolver returns RGBA and ImDrawList
expects ABGR; with five widgets that is the same swap-red-and-blue trap five
times over.
Sizes go through WidgetGeometry, which is pure so the build suite can pin it,
and clamps every result to a positive extent -- ImGui asserts on a zero-sized
InvisibleButton and takes the window with it.
The sheen kept its own Dictionary<string, DateTime> of start timestamps and
only cleared an entry in the un-hover branch. A row that disappeared while the
pointer was on it left its entry behind until the plugin reloaded, which is
exactly what happens to temp tabs under the LRU limit.
It now takes the held intensity from HoverState and draws on the rising edge
only. The alpha falls off as the value climbs, so the sweep has faded out by
the time the surface underneath is fully in. On the way out it simply does not
run, which is what stops it from travelling backwards -- the old
SheenStarts.Remove prevented that by resetting, and dropping the map without
this guard would have reintroduced it.
The sidebar call site built "sidebar.tab.{guid}" per row per frame, two
allocations each. Master spec 5.3 asks for constant keys, and 7.5 for a stable
allocation count. It now uses ImGui.GetID("row"u8), which is allocation-free
and seeded from the window's ID stack, so the same literal stays distinct per
window and per PushID'd tab.
HoverSheenAllocStep pinned the old dictionary contract and is replaced by
HoverStateFootprintStep, which pins the same property against the registry:
repeated queries add no entries, and an element that stops being queried leaves
the map instead of leaking.
DrawHoverSheen measured its own elapsed time against DateTime.UtcNow and gave
up after 0.65s, so a row stopped reacting while the pointer was still on it.
There was no held value to interpolate colours against.
HoverState keeps one 0..1 intensity per element, rising at 14/s and falling at
8/s. Slower out than in is what makes the fade read as deliberate.
Query and advance are separate on purpose. Several SelfTest steps call
Sidebar.Draw against the live tab list, so the same element gets submitted up
to three times in one frame, twice from a window the mouse is not over. If the
query advanced the value, the last caller would win and the fade would run
backwards. Query only ORs the hover flag; BeginFrame does all the moving and
the eviction.
BeginFrame sits above the HideInLoadingScreens and New Game+ early returns, so
a hidden main window still lets pop-out hovers fade out instead of freezing
mid-blend.
FrameLerp gains Ramp: Smooth approaches asymptotically and never arrives, so a
value driven by it would never reach zero and never become evictable.
ReduceMotion short-circuits before the map is touched, returning a hard 0 or 1.
An infinite rate would produce NaN and poison the entry for the session.
Layout constants lived as bare floats in the components: row heights, hit
widths, insets, reserve widths. None of them multiplied by GlobalScale, so at
125% or 150% display scaling the text grows and the boxes do not. The quick
buttons stop fitting into their 130px column.
Metrics holds the design values and exposes scaled properties. The Raw
constants stay reachable for the few places that must store or compare an
unscaled value: Sidebar.GetWidth (a SelfTest pins it against raw numbers) and
the width slider bounds.
Scale is pinned once per frame against ImGui.GetFrameCount(). GlobalScale is a
live value the Dalamud slider moves on every dragged frame, so reading it per
access can shift a CalcSize away from its matching Draw inside one frame, and
costs three native calls each time.
Not in ThemeLayout: that record is serialised into theme JSON, and layout
customisation is out of scope per the master spec.
MetricsMath is the pure half so the build suite can pin the arithmetic. Text
heights are measured rather than scaled -- the font is built from
Config.FontSizeV2, which GlobalScale does not feed into.
Compact mode ran an ImGuiListClipper with CompactRowHeight = 18f. Two things
were wrong with that.
The number: at the default 12.75pt the font is 17px, and ChunkRenderer pushes
ItemSpacing to zero for the whole chunk loop, so a single-line compact row
advances the cursor by 17, not 18. The clipper seeded the cursor one pixel too
low per row, which accumulates into a visible drift against the scrollbar.
The assumption: compact rows are not constant height at all. DrawCompactRow
renders content with wrap: true, and WrapEncodedLine submits one text item per
wrapped line. At 620px and 17px type that kicks in around 70 characters, so
most chat lines are multi-line.
Both densities now share DrawRows/DrawLinearAndMeasure over the existing
CardClipPlanner, with the row painter passed in. The fixed height and the
clipper are gone.
Also corrects the CompensatedDummy comment: the cached heights carry no
trailing ItemSpacing (every row ends inside DrawChunks, where spacing is
zero, and ImGui writes the advance at submission). The compensation is
correct because it cancels the spacing the dummy itself appends.
CardClipPlanStep drives the invalidation hook directly, which now sits behind
the settle gate, so it walks a synthetic clock past the window.
The layout fingerprint tracked font size, density, both name modes and
content width, but not ImGuiHelpers.GlobalScale. Scale feeds
CalcWordWrapPositionA, so changing it rewraps every row while the cached
heights stay put and the clipper dummies drift against the scrollbar.
Two further problems came out of the same code:
The fingerprint lived in a single field on MessageList while the cache it
guards is per tab. Resizing in tab A marked the new value applied, so tab B
kept measuring against the old width. It is now a gate per tab identifier.
Acting on every fingerprint change is too eager. A window resize or a drag on
the Dalamud UI-scale slider moves the value on every frame, and each change
drops the cache and forces the linear measure path over the whole tab (up to
Config.MaxLinesToRender rows). The gate now waits for the value to settle for
200ms, which turns a drag into one rebuild instead of one per frame.
The settle logic sits in Util/LayoutFingerprint.cs as a plain value type so
the build suite can pin it without standing up an ImGui frame.
HandleTell was one atomic block, and PreloadHistory sat inside it -- so every
new tell partner held TabsListLock across a store query that sorted the whole
receiver history before returning a row. That is the lock the draw thread and
the message worker both wait on.
Now three steps: look for an existing tab under the lock, build the new one
(including history) without it, then commit under the lock again. Splitting it
opens a window where the world can change, so the second block re-checks:
- FindTempTab again, in case something else created the tab meanwhile. The
message goes to that one instead. Not in the first block's early return --
HandleTell runs after the delivery loop, so an existing tab already has it and
adding again would duplicate the line.
- A generation counter, bumped by OnLogout under the same lock. A logout in
between wipes the unpinned pool, and without this the freshly built tab would
outlive it and show up for a character we already left. Not via
CurrentContentId: its getter falls back to a cached value, so the comparison
can silently pass.
- The pool cap moves into CommitTempTab and stays there exactly once. Evaluating
it twice would evict a tab on every spawn.
Pin, unpin and promote take the lock around the flag change now -- they decide
pool membership and whether a save strips the tab. SaveConfig stays outside, so
no fsync lands on the click path.
DropOldestTempTab removes by reference: the index came from an earlier Select in
the same block and would point at the wrong tab if anything shifted the list.
The whole v1.9.0 cycle ran without a version bump, so the plugin still reported
1.8.8 in-game. For a tester beta that is untenable: bug reports would name a
version that does not identify the code they ran.
Download links stay pinned to v1.5.6 on purpose. There is no v1.9.0 release, and
pointing at an artifact that does not exist is worse than the visible mismatch
between assembly version and download target. Public stays on v1.5.6 until
v2.0.0.
TabsListLock never covered ChatColours, PrivacyPersistChannels or
RetentionPerChannelDays, yet the settings UI mutates them from the draw thread
while the retention thread can be serializing the same config. Adding a new key
to a dictionary or a new element to a set invalidates a running enumeration, so
this could throw from inside JsonConvert.SerializeObject.
Not a corner case: the colour picker lists 66 channels but only 25 ship with a
default, so the first edit of any of the remaining ones inserts a new key -- and
the reset button removes a key, which makes the next edit a fresh insert again.
The readers matter as much as the writers. IsAllowedForStorage runs per message
on the worker thread and asks PrivacyPersistChannels whether a channel may be
stored; a Contains racing an Add that resizes buckets can answer wrong, and that
answer decides whether a message is written to disk. The retention sweep
enumerates RetentionPerChannelDays on the framework thread while the wizard can
clear it -- Clear does not throw there, it just cuts the enumeration short, so
the sweep would run on half a policy.
New ConfigMapsLock covers all of it. It sits inside TabsListLock (that edge is
real, AutoTellTabsService calls SaveConfig while holding the tabs lock), never
the other way round -- so every call site closes the lock before saving.
Tab.Clone silently dropped Icon and ChatCodes, both serialized. A reflection
test now walks the serialized fields so a future one cannot slip past.
Also: CurrentTab read Count and [0] as two separate accesses.
Sidebar, top tabs and status bar each read Config.Tabs on their own, unlocked,
while the worker added or evicted tabs. That gave three independent views of a
moving list: an index built in one place could resolve to a different tab a few
lines later, which showed up either as an out-of-range crash on the draw thread
or -- worse, because it is silent -- as a click landing in someone else's tell.
MainWindow now takes one snapshot under the lock and passes it through the whole
frame. Deliberately a shallow copy: tab identity is compared by reference all
over the draw path, so cloning would break every ReferenceEquals and Contains.
ChangeTabDelta and ResetActiveTabIfRemoved run on the framework thread and keep
their own locked reads instead; ThemeQuickPicker locks its own copy, since
reaching it would mean threading a parameter through InputBar, which popouts
share and which has no tab list.
Widget IDs move from list position to tab.Identifier. ImGui carries popup and
widget state across frames under that ID, so a position-based one re-binds an
open context menu to a different tab as soon as the list shifts -- a snapshot
cannot fix that, it spans frames. This also resolves top tabs visually merging
into each other when the list changed.
The sidebar section headers counted over the live list while the rows came from
BuildRenderOrder, which skips popped-out tabs. Both sides take the same
predicate now, so the count matches what is drawn.
ProcessMessage walked Config.Tabs live on the worker thread while SaveConfig's
strip and the auto-tell spawn mutated the same list under TabsListLock. The
resulting "collection was modified" was caught by the pending-message handler
and only logged -- so the message was dropped entirely: no tab entry, no sound,
and MessageProcessed never fired, which also meant no tell tab and no routing.
Silent message loss, exactly under the load where it hurts.
The loop now runs over a snapshot taken under the lock. AddMessage stays
outside it, so the lock order (list outer, MessageList inner) is unchanged.
SelectNotificationSound reports which tab it picked, so playback can skip a tab
that disappeared between snapshot and sound -- otherwise the snapshot would let
an evicted tab still make noise.
While here: the current tab was read twice despite the comment claiming it was
snapshotted once.
GetTellHistoryWithSender filters on Receiver and orders by Date DESC. Without a
matching index SQLite sorted the whole receiver history into a temp b-tree
before yielding row one -- measured 10 ms to first row against 9621 tells, all
of it under TabsListLock, which defeats the early break in the caller.
(Receiver, ChatType, Date) does not help: the ChatType IN filter sits between
the equality prefix and the sort column, so the temp b-tree stays. Verified on
a real database: plan now reads SEARCH ... USING INDEX idx_messages_receiver_date
with no sort step.
No SQL LIMIT -- an earlier 500-row cap was removed in v1.4.10 because it cut
less-frequent partners off the back of the window, and 83% of partners have
fewer than 21 tells in total.
The migration dispatcher is cumulative, so Migrate5 is appended to every
existing case, not just the new one.
JonKazama-Hellion