[thisisgm]

The details pane looks at the selected item in a box of four by three, whatever the item is. A PDF's page is taller than that and a text has more lines than fit, so both were shown small above a pane that was mostly empty. With the first of these two commits a text gets the height its opening lines need and a PDF its page across the pane, up to what the window leaves under them; every other item keeps the box it had. The second keeps the pane's contents inside it when the app a file opens with has a long name, which until now pushed them past the right edge. The suite goes from 194 to 196 tests. No library, depends or optdepends entry is added.

What you'd notice

• A PDF's first page is drawn across the pane. It was fitted into the four by three box, which left it 139 by 196 on a mini PC. It is now as wide as the names under it and as tall as its own shape asks: 244 by 345 for an A4 page.
• A text shows the lines that were read. The pane already reads a text's first 41 lines and showed about a dozen of them. The box now takes the height those lines need, so all of them show when the window has the room.
• Nothing under the look gives way. The names, the facts and the Open button keep their heights and their places at the bottom. In a short window the look gets the room that is left and no more, and a text that is cut ends in an ellipsis as before.
• A long app name stays inside the pane. The button that names the app a file opens with was as wide as its text, and the details are as wide as their widest row: with "Document Viewer" everything in the pane ended 11 from its edge where the margin is 28, and a longer name pushed the date and the page out of the window. The button now takes the room beside its label and no more. A name too long for that is cut in the middle, so the arrow that says it opens a menu stays.
• The pane settles once. While a PDF's page is being drawn the box already holds the shape of an A4 sheet, so a page that is one doesn't move anything when it arrives. While the next text is being read the box keeps the height of the one before. A folder that is read again leaves the box as it is.

Pictures

A mini PC, one window, the same folder, main on the left and this branch on the right.

The same PDF when the app it opens with has a long name.

What stays the same

• A picture, a video, a folder, an archive and every other kind of item keep the four by three box, a tall picture too: stepping through a folder of photos doesn't move the facts under them.
• A text of a few lines keeps the box, and so does a PDF whose page can't be drawn.
• The pane's width and its margins are untouched, and so are the names and the facts. A button whose text fits looks as it did, in the pane and in every dialog: PlainButton.qml gains only what a button narrower than its text does, which is to cut the text in the middle and keep 8 pixels of itself on each side of it.
• Nothing more is read: the same 41 lines of a text and the same thumbnail of a PDF, asked for at the size it was.
• No animation is added. The box takes its height in the frame the content arrives.

Tests

Two new cases, both of which fail on the sources of main.

detailsGiveATextOrAPageTheRoomTheyCanUse shows a real PreviewPane a picture, a short and a long text, a PDF and a PDF that can't be drawn, in a tall window and a short one, and reads the laid out heights: the picture and the short text keep four by three; the long text grows to its last line with room to spare, and in the short window takes exactly the room there is with nothing under it squeezed; the next text keeps the box while a held thread pool delays its reading; an item that a re-read leaves on the row for a moment doesn't drop the height, and a picture looked at in between does; a PDF holds an A4 sheet's shape while a stand-in image provider holds its page back, then takes the page's own shape; a pane made narrower gives a text that wraps into more lines the height they need.

detailsKeepALongAppNameInsideThePane gives a real PreviewPane stand-in apps and reads where the button is laid out, plain and mirrored: with a short name it is as wide as its text asks for, against the far edge, as before; with a long one it starts right after its label and ends at the edge of the facts, its text cut in the middle with room kept on both sides; in a pane with room for the text but not for all of the button around it the whole name is shown.

Sixteen single changes to PreviewPane.qml (each arm of the height, each term of the room, each of the two signals the kept height listens to) each fail the first case, and eight to the button and its place in the pane (the button not filling the room, no upper width, neither, no cut, a cut at the end, no room around a cut text, that room always, that room in a button that still fits its text) each fail the second. Each commit builds without warnings and passes the suite on its own, also with TMPDIR set to a folder whose name has a space, where only extractRefusesWhatWouldLandOutside fails, as it does on main.

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no actionable new defects were found.

Summary

The PR gives text and PDF previews more height and keeps long app names inside the details pane.

• Text and PDF previews grow into the room the details pane has.
• Long app names stay inside the space beside their label.

No actionable new issues were found. No previous review threads were supplied. Tests were not run during this review.

_{Reviews (2) · Last reviewed commit: "Keep a long app name inside the details" · Reviewed by Greptile}