Repository navigation
LT-22811: Show Avalonia detail data at the Normal style's size - #1236
Merged
Merged
Conversation
The Avalonia detail view drew its data at the fixed 11-unit surface font (about 8 pt), so changing Normal in Format > Styles left it unchanged while the WinForms slices followed. The composer now reads the project's Normal style through the stylesheet and gives each text value Normal's size for its writing system, falling back to Normal's size for all writing systems and then to 10 pt, and the lexeme form's 120% scales that size. The detail model carries Normal's analysis size, and each value editor sizes its TextBlocks and TextBoxes with it in place of the surface font. Only those two types are styled, so the text a box draws inherits the box's own size, as the lexeme form's larger size needs. A styled or multi-run value, shown read-only until it is clicked, keeps its own size and bold there too. RecordEditView now answers RefreshDisplay, so closing the Styles dialog or pressing F5 recomposes the Avalonia view once any open edit is done. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Each compose built a new LcmStyleSheet to read the Normal style. The sizes are now kept per project and rebuilt when Normal's rules change, which saving the Styles dialog does. The Lexicon Edit error fallback built its model without a value size, so it still showed data at the 11-unit surface font. It now uses Normal's sizes too. DataTree.ApplyValueFontSize moves above CreateEditor's comment, which it had separated from its method. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #1236 +/- ##
==========================================
+ Coverage 40.58% 40.60% +0.01%
==========================================
Files 1560 1561 +1
Lines 356396 356495 +99
Branches 41647 41666 +19
==========================================
+ Hits 144645 144745 +100
+ Misses 182439 182435 -4
- Partials 29312 29315 +3
🚀 New features to boost your workflow:
|
The Lexicon Edit error fallback showed the lexeme form at Normal's size but neither scaled by its part's 120% nor bold, because the first-slice nodes it builds dropped both properties. The nodes now carry them, and the fallback applies them as the composed view does. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The comment above the fallback lexeme form's scale named the two inputs the code beside it already reads. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
RecordEditView.RefreshDisplay, which View > Refresh and the Styles dialog reach, had no test. One test now changes Normal's size, checks that the change alone leaves the Avalonia view as it was, then that RefreshDisplay recomposes it at the new size and returns false so the views inside still refresh. Another checks that in the WinForms UI mode it returns false and builds no Avalonia view. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A ghost row's value carried no size, so text typed into it showed at Normal's analysis size whatever writing system it went into. It now shows at Normal's size for the ghost's writing system. The part's fontsize percentage is applied in one place, NormalStyleFontSizes.For(ws, percent), for both the composer and the Lexicon Edit error fallback. A headless test confirms a value's Copy menu keeps its own size when the value size applies. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
mark-sil
reviewed
Nov 10, 2026
| /// of the surface font, for the controls the surface font sizes. A size a control sets | ||
| /// for itself still wins. Does nothing for a null editor or a size that is not positive. | ||
| /// </summary> | ||
| public static void ApplyValueFontSize(Control editor, double fontSize) |
Contributor
There was a problem hiding this comment.
This sizes more than the field values. A TextBlock style in the editor's own Styles applies to every plain TextBlock inside the editor, and to the editor itself. So some interface text in the value column now grows with Normal rather than staying at the 11-unit surface font:
- "lit" message rows and the Unsupported placeholder (
SliceFactory.CreateLiteral/CreateUnsupported), where the editor itself is theTextBlock - button captions inside editors: the reference-vector "+" (
FwFieldControls.cs:1752), the link row's Apply, and Paragraph Style - probably also tooltips opened from value-column controls (the writing-system abbreviation, the read-only reason), since a tooltip takes its styles from the control it belongs to (not yet confirmed by hovering one)
At the default 10 pt the difference is small. With Normal at 16–20 pt, which is common for complex scripts, this text draws at 21–27 units beside 13-unit labels. The WinForms view keeps message rows and tooltips at the interface font.
Could the size be limited to the data controls? For example, a style class on the value boxes and text blocks the composer creates, or a local FontSize on the chrome so the style doesn't win.
Contributor
Author
There was a problem hiding this comment.
Thanks, you're right. Fixed in 19b53ed: the value size now applies only to text the field controls mark as data, through a fwValueText style class (FwSurfaceStyles.MarkValueText) that ApplyValueFontSize requires. Marked: value and reference-item text, chooser and dropdown option names, the option filter, the read-only per-run display, structured-text paragraphs, reversal entries and the dialog launcher's value.
Everything else in the value column keeps the 11-unit surface font: "lit" and Unsupported rows, watermark prompts, button captions, and tooltips, whose text is never marked. I also found the watermarks (ghost-row prompts, the link URL prompt) were growing too.
ValueFontSize_SizesTheData_NotTheInterfaceTextBesideIt checks the message and Unsupported rows, a watermark and the reference list's "+" caption against the same view without a value size, and that a reference item still follows Normal. Tooltips aren't tested directly.
The value size was a style on every TextBlock and TextBox inside a value editor, so interface text beside the data grew with Normal too: "lit" message rows, the Unsupported placeholder, watermark prompts and tooltips. The field controls now mark the text that shows data with the fwValueText style class, and only marked text takes the value size. Everything else keeps the 11-unit surface font. Marked: value and reference-item text, chooser and dropdown option names, the option filter, the read-only per-run display, structured-text paragraphs, reversal entries and the dialog launcher's value. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
DataTree.cs conflicted: main moved the hotlink strip out of DataTree into DetailHotlinkStrip (LT-22693), and this branch had added ApplyValueFontSize beside it. The strip follows main; ApplyValueFontSize stays. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Brings in the PcPatrFLEx debugging change (LT-22889); no conflicts. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2 of 10 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The new (Avalonia) detail view now shows its data at the project's Normal style size, so changing Normal in Format > Styles resizes Lexeme Form, Gloss, choosers and the rest, as it does in the WinForms view. Until now every value drew at a fixed 11-unit surface font (about 8 pt) whatever Normal said, and only the lexeme form was larger, at a hardcoded 12 units times 120%.
Each writing system uses Normal's own size for it when the style sets one, otherwise Normal's size for all writing systems, otherwise 10 pt, and the lexeme form keeps its 120% of that. Closing the Styles dialog or pressing F5 now recomposes the open view in place.
Reviewer notes
Root cause.
FwSurfaceStylesgives the whole DataTree a baseline style that sizes everyTextBlockandTextBoxat the 11-unitFwSurfaceFontSizetoken, and the composer handed values no size of its own except the lexeme form's12.0 * 120%. Nothing read the Normal style. Separately, the Avalonia view was not anIRefreshableRoot, soRefreshAllWindows(Styles OK, F5) never reached it.Deliberate rules.
NormalStyleFontSizesreads Normal through anLcmStyleSheet(BaseStyleInfo.FontInfoForWs), the same per-writing-system lookup the Styles dialog's Font tab uses, and falls back to 10 pt like the native renderer (knDefaultFontSizeinVwPropertyStore.cpp). Points become Avalonia units at 96/72. One instance is kept per project (ConditionalWeakTableon theLcmCache) and rebuilt when the Normal style'sRulesinstance changes, which saving the Styles dialog does.DetailModel.ValueFontSize, Normal's size in the default analysis writing system.FwSurfaceStyles.ApplyValueFontSizeadds, inside each value editor, the same two selectors as the surface baseline (TextBlock,TextBox) at the value size, limited to controls carrying thefwValueTextstyle class (FwSurfaceStyles.MarkValueText). The field controls mark only text that shows data: value and reference-item text, chooser and dropdown option names, the option filter, the read-only per-run display, structured-text paragraphs, reversal entries and the dialog launcher's value. Message ("lit") and Unsupported rows, watermark prompts, button captions and tooltips stay unmarked and keep the 11-unit surface font. Only those two types are styled on purpose: a broaderControlselector also hits theTextPresenterinside eachTextBoxtemplate, which then draws at the view-wide size and loses a box's own size. The first version of this branch did exactly that and dropped the lexeme form's 120% on screen; a test now asserts the size each box draws. Labels, section headers, hotlinks and writing-system abbreviations set their own sizes and are unchanged.CreatePerRunFontDisplay); it now copies the text box's own size and weight, so the lexeme form stays 120% and bold there too.RecordEditView.RefreshDisplayasks the existing refresh controller for a recompose, which holds it while an edit is open, and returns false, soFwXWindowstill refreshes the views inside, as before. In the WinForms UI mode it does nothing.LexiconEditErrorFallback, shown only when composing fails) gets the same sizes through a new optionalvalueFontSizeonDetailModelProjector.FromViewDefinition. Its lexeme form keeps the part's 120% and bold too:LexiconFirstSlice.StampProductLeafdrops neither property any more.Tests.
DetailComposerFontSizeTests(new): Normal at 20 pt sizes the gloss, the model and the lexeme form at 120%; a vernacular-only size saved throughStyleInfo.SaveToDB, as the Styles dialog saves, applies to the vernacular value only; a change to Normal between composes is picked up; no Normal style gives 10 pt; the error fallback uses Normal's size, with the lexeme form at 120% and bold; ghost rows use their writing system's size.DetailViewingParityTests: the value size reaches text boxes and chooser text over the surface font, the size each box draws matches its own size, labels and abbreviations keep theirs, a styled value's display keeps the value's size and bold, and a value's Copy menu keeps its own size (menu items draw throughAccessText, which the exact-typeTextBlockstyle does not match), and message and Unsupported rows, a watermark prompt and the reference list's add-button caption keep the surface font while a reference item follows the value size.RecordEditViewSwitchTests: a change to Normal alone leaves the Avalonia view as it was,RefreshDisplayrecomposes it at the new size and returns false, and in the WinForms UI mode it returns false and builds no Avalonia view. FwAvaloniaTests 955 of 956 passed (1 skipped); xWorksTests 1916 of 1918 passed (2 skipped). One earlier xWorksTests run recovered from three test-host crashes atFilterBar_RealizedWindow_ExposesTargetCombosThroughUIA, a realized-window UI Automation test this branch does not touch; the other full runs were clean.Manual tests (done). On Sena 3 with the new UI, side by side with the WinForms view: labels, glosses and the plural match in size, and the lexeme form shows its 120%. Format > Styles > OK resizes the open view in place.
Out of scope. LT-22692 (refresh and re-compose parity on external changes) continues the refresh work; this branch already makes F5 and Styles OK recompose the Avalonia view. The Morph Type chooser still renders in the theme's blue sans-serif rather than the WinForms bold serif; that is chooser styling, not size. Per-writing-system sizes reach text values and ghost rows only: chooser text and reference items (Components, Cross References) draw at Normal's analysis size because
DetailChoiceOptioncarries no writing system, and a run in another writing system inside a value takes the value's size. That matters only when Normal sizes some writing systems differently, and needs a model change.🤖 Generated with Claude Code
This change is