Make the viewer's queue column draggable and wider - #738
Merged
Conversation
The column holding pending snapshots was a fixed 220 pixels in the WinForms and AppKit heads and 220 points in the ImGui one, which is narrower than most test file names. It is now 34 character cells, counted in cells so a scaled display gets a column that holds the same number of characters rather than a narrower one, and the rule beside it can be dragged. Clamped on every read rather than only when dragged, so shrinking the window narrows the column instead of leaving the panes with nothing, and a chosen width survives the window growing back. Only the queue divider moves. The one between received and expected stays put, which on the ImGui head means NoResize on the received column, since Resizable would otherwise offer both. Also fixes long queue labels painting over the pane beside them on Windows: the shared StringFormat is cloned from GenericTypographic, which arrives with NoClip set, so the clipping the Painter documented never actually happened. LineLimit goes with it, because once clipping is on it turns a rect a pixel short of the measured line height into nothing drawn rather than a line clipped at the bottom. The AppKit head had a smaller version of the same bug, clipping one cell past the column because offsetBy keeps the width. Nothing had covered a label wider than the column, hence LongQueueLabel in both pixel suites. The ABI is unchanged, so DEVIEW_VERSION stays at 2 and the committed native binaries keep working until build-native produces new ones.
ImGuiTableFlags_Resizable would give the drag for free, but it also hands the column width to ImGui's table state, which initialises once and then auto-fits or restores from saved settings. A fixed column that is not resizable takes InitStretchWeightOrWidth on every frame instead (imgui_tables.cpp TableGetColumnWidthAuto), which is what made the old constant 220 reproduce. The pixel captures share one context and one table id and draw a single frame each, so with Resizable the width carried between them: in one CI run the same column came out at 34 cells for InlineSingle and InlineQueue, a content fit for LongQueueLabel, and the old width for InlineAccepted, which is a baseline that depends on the order the tests ran in. So the width lives in State, is handed to the table every frame, and the drag is an InvisibleButton over the border. Submitted after the table so it wins the overlap, and inert during a capture, which never feeds a mouse button. It moves the width by the distance between the cursor and the border rather than setting it from the cursor, because a column width is its inner width and the border sits a padding and a spacing further right. Also applies the cursor ImGui asks for. Nothing here did, so ResizeEW would have been recorded and never shown. The macOS baselines are the ones from the CI run and are final. The Linux ones still have to be regenerated against a binary built from this.
Shift+A has always accepted a queue of one, because the key path never consulted the button. A button that refuses what the key it names does reads as a bug rather than as a nicety, and there is nothing about accepting one snapshot through Accept all that does not work. The WinForms baselines for the two one-item screens needed regenerating by hand rather than re-accepting: enabled versus greyed is a small part of a 1100 by 700 image, so the captures stayed inside the 0.98 SSIM threshold and passed while describing a button state the app no longer has. The macOS pair is deleted for the same reason, so CI regenerates them rather than quietly keeping the old ones.
…itter' into viewer-queue-splitter
The Linux captures for InlineSingle, InlineQueue and InlineAccepted passed against baselines that no longer describe them: the queue column moved by about twenty pixels and Accept all went from greyed to enabled, and neither moved a 1100 by 700 image past the 0.98 SSIM threshold. Deleted rather than re-accepted, because a passing snapshot cannot be re-accepted and one that quietly stops describing the screen is worse than none. FileDiff is left alone. It has no queue and no Accept all, so neither change reaches it. The Linux column is barely wider in pixels while being the same 34 characters as the other two heads, because ImGui renders the embedded font smaller there. Counting cells is the intent: the column holds a file name of the same length everywhere.
All four inline captures now put the divider in the same place, which is what the width living on this side rather than in ImGui's table state was for. Accept all is enabled on the two one-item screens.
deview_init's fontSize was an em size to Core Text and a pixel height to ImGui, whose stb_truetype loader scales with stbtt_ScaleForPixelHeight. JetBrains Mono measures 1020 ascent and 300 descent over a 1000 unit em, so the same 15 produced an em of 11.36 there: measured against the captures, 6.77 pixels per character on Linux against 8.95 on macOS. That is why this head's queue column held 34 characters in noticeably fewer pixels than the others. The column was never the problem; counting cells was doing exactly what it says while the cells themselves were three quarters the size. Corrected with ImFontConfig::ExtraSizeScale rather than by passing a larger number, so the ABI keeps one meaning for fontSize and the correction sits next to the rasteriser that needs it. The constant is the font's own (ascent - descent) / unitsPerEm, and it is a constant because the only font that reaches here is the one the managed side embeds. DEVIEW_VERSION goes to 3 by the rule on it: a field means something different than it did. Both libraries read that from the shared header, so the macOS one moves with it and NativeTests fails until build-native has produced both. Every Linux baseline is deleted rather than re-accepted. All five change, since all of them are text.
Co-authored-by: SimonCropp <122666+SimonCropp@users.noreply.github.com>
Measured against the macOS captures of the same screen, both now render the title at 8.95 pixels per character, where Linux was 6.77 before. The queue column is the same 34 cells it always was and now the same width on screen as the other two heads.
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
1 participant
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 column holding pending snapshots was a fixed 220 pixels, which is narrower than most test file
names, and nothing could be done about it. It is now 34 character cells, counted in cells so a
scaled display gets a column that holds the same number of characters rather than a narrower one,
and the divider beside it can be dragged in all three heads.
Width is clamped on every read rather than only when dragged, so shrinking the window narrows the
column instead of leaving the panes with nothing, and a chosen width survives the window growing
back. Only the queue divider moves; the one between received and expected stays put.
Each head does the drag its own way, because each owns its own input:
also select an entry, and shows a VSplit cursor.
returned, and adds a cursor rect.
ImGuiTableFlags_Resizable would have given that last one for free, but it also hands the width to
ImGui's table state, which initialises once and then auto-fits or restores from saved settings. The
pixel captures share one context and one table id and draw a single frame each, so the width
carried between them: in one CI run the same column came out at 34 cells for InlineSingle and
InlineQueue, a content fit for LongQueueLabel, and the old width for InlineAccepted. A fixed column
that is not resizable takes the width it is given on every frame instead, which is what the old
constant relied on, so the width lives in this side's state and the drag is hand rolled.
Also here:
is cloned from GenericTypographic, which arrives with NoClip set, so the clipping the Painter
documented never happened. LineLimit goes with it, because once clipping is on it turns a rect a
pixel short of the measured line height into nothing drawn. The AppKit head had a smaller version
of the same bug, clipping one cell past the column because offsetBy keeps the width.
consulted the button.
Nothing had covered a label wider than the column, hence LongQueueLabel in both pixel suites. The
two macOS baselines whose button changed are deleted rather than re-accepted: enabled versus greyed
stayed inside the 0.98 SSIM threshold, so they passed while describing a state the app no longer
has, and CI regenerates them.
The ABI is unchanged, so DEVIEW_VERSION stays at 2. The native binaries here were built by the
build-native workflow from this branch.