Repository navigation
Size the name and detail columns from what is drawn in them - #38
Merged
Merged
Conversation
The name column measured a group as one string, arrow and name together, but DrawName draws them as two texts, each with its own padding, so the widest group's name was a padding short and drew an ellipsis. Measure them apart, and advance by the same indent whether the group is open or closed.
Reads the name's link, which is as wide as what was drawn of it, against the name's measured width, so it holds whatever fonts the machine has and runs in Release where the pixel baselines do not. Fails against the column sizing before the fix, 159 against 167.
NameCell gives the indent, the mark and the name's width for a row kind. ColumnWidths sums them and DrawName advances by them, where each worked the cell out for itself and the two came apart. No change to what is drawn.
DetailOffset gives how far into its cell a detail has got after some of its text and marks. ColumnWidths sizes the column from where that ends each detail and DrawDetail starts each run at it, both measuring with the flags the runs are drawn with. Two things change. The column loses the padding it was sized with and the runs never drew, so while the chips are giving way everything after the detail sits nine pixels further left, which is the Narrow baseline. And a run is no longer measured with an ampersand read as a mnemonic, which drew the branch of a pipeline named 'Build & Test' over the end of it.
SimonCropp
changed the title
The page gave the names and details as text alone, so the Windows head sized every name as a member's, indented and with a mark, and every detail as carrying the branch's mark. The page now also says which names are a member's, which groups carry a mark and which details carry the branch's, and the columns are sized from each cell as it is drawn. A build's name no longer gets an indent no row drew in, so on a page with a group the second cell starts 26 pixels further left: the Groups, Searched and PrefixGroup baselines. The new lists are additions to BuildsPage; the native heads and the text renderer read what they did.
…rks from every row The text renderer indented every name wherever the page had a group, and added the branch's mark to every detail once a row in view had one. It now sizes each name and detail as the kind of row that shows it, from the lists the page gained for the Windows head, so the name column is four characters narrower on a page with a group. Whether room is kept for the mark before a name, the mark leading the second cell and the provider was read from the rows in view, so the columns moved as a row with one scrolled in or out. The page now says it of every row, and the Windows head and the text renderer read that.
The Linux and macOS heads sized every name as a member's, indented, and every detail as carrying the branch's mark, and read whether to keep room for the marks from the rows in view. BmScreen now carries the member names, the marked group names and the marked details after the lists it had, and whether any row of the page has each mark, and both heads size from those. BM_VERSION 20. The macOS head also measures a group's arrow and name apart and advances past the arrow by the indent, as the Windows head does. Not compiled here: the build-native workflow builds the binaries, and the pixel baselines follow from a Test run.
The column was sized from the one text 'v name', with a letter the row does not draw, and the name started where whichever arrow was drawn ended. The indent is now the open arrow's width, a group's name is measured apart from it, and every group's name is drawn the indent after the arrow, as the other heads do. Not compiled here.
Co-authored-by: SimonCropp <122666+SimonCropp@users.noreply.github.com>
None of the native pixel baselines showed a group, so nothing drew how the Linux and macOS heads size and place one: a closed group with a mark, and an open prefix group with its members indented. The baselines follow from the received artifacts of the Build run.
From the received artifacts of the Build run on 2494dc0.
A table column asked to be no width is still given the minimum, the frame padding. The hidden bar's column and an author column with no one to name were left out of the sums, so they took that much from the detail column, the one that stretches, and the widest detail was cut short. Not compiled here, and the cause is read from the code rather than measured: the Linux baselines will show whether it holds.
From the received artifacts of the Build run on 8c732ec: the widest detail is drawn in full, and the columns after it sit eight pixels further right where the bar is hidden.
Co-authored-by: SimonCropp <122666+SimonCropp@users.noreply.github.com>
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.
Started from one bug: on the Windows head the widest group name was cut short with an ellipsis beside an empty column. The cause was the column being sized by one measure and drawn by another, and the same fault turned up in the detail column, the text renderer and both native heads. Each column is now sized from what is drawn in it.
Name column
Detail column
Each cell sized as its row draws it
Native interface: BmScreen carries the new lists and flags, BM_VERSION 20. The binaries are rebuilt by build-native and merged into this branch (#39, then #40 for the Linux detail fix), so source, binaries and baselines match.
Tests
Baselines changed
Not checked against a live list on any head.