Brief listing mode: Uneven column widths, unused space

[egmontkob]

Is there an existing issue for this?

• I have searched the existing issues

Midnight Commander version and build configuration

4.8.33, git

Operating system

Linux

Is this issue reproducible using the latest version of Midnight Commander?

• I confirm the issue is still reproducible with the latest version of Midnight Commander

How to reproduce

F9 -> Left/Right -> Listing format -> Brief, the more columns the more prominent this becomes.

Resize the terminal window to find a width where the issue is more obvious.

The filenames are restricted to the same number of cells in every column, leaving potentially a lot of empty screen real estate in the last column.

It also looks silly that the } sign denoting that the filename was chopped is not right next to the chopped filename.

(Interstingly, the selected file's background color is applied to the whole width.)

Expected behavior

Distribute the space as evenly as possible, meaning at most 1 difference between columns.

Use all the available space to show the filename.

Actual behavior

.

Additional context

No response

[zyv]

Relates to #4685 and #2731.

[egmontkob]

It might not be that easy...

Here's my current understanding of the code (it might be wrong):

"Full" and "Brief" listing formats are not implemented "next to each other" or in an "either-or" manner. They are nested: Brief's columns is the outer one, Full's columns is the inner.

As a result, technically it should be very easily possible with this design (although I doubt it's exposed on the UI) to have a panel that looks like e.g. Name Size Type Name Size Type, i.e. inside one panel there'd be 2 columns listing the files, and for each file we'd show 3 properties.

The outer count (2 in this example) is panel->list_cols; I presume in Brief mode it originates from brief_cols, in Full mode it's set to 1 (I haven't found this code yet).

The field widths are computed for the inner format, under panel->format, in its field_len variables, see e.g. in the patch / PR of issue #2109. That is, continuing the above example, we compute once how wide the Name, Size and Type fields will be. These widths are the same as this group of columns (or just one column Name in case of Brief listing) repeats.

[egmontkob]

There's also a rounding error.

In Brief mode, those multiple Name columns are never of the same width. With 2 columns, the right one is 1 or 2 characters wider than the left, meaning 1 or 2 spaces between the truncated filename and the } scrolling sign.

With Brief mode and 3 columns, the rightmost column is 1, 2 or 3 characters wider than the first two. And so on.

This is hopefully just an off-by-one, not requiring heavier changes.

[egmontkob]

mc-4906-brief-columns-width-easy-bits.patch

This fixes the issue of the last comment (which, I've just noticed, is also visible in the initial screenshot: there are 4 Name columns and 4 unused trailing spaces).

The proper logic to evenly distribute the columns: Take the entire width of the panel (including frames), remove 1 frame (let's say the left hand one), now divide into N parts (thereby each part has 1 frame line associated with it: the one on its right), and then subtract that 1 frame for every part.

I guess I should add a brief explanation to the code.

Also: I'm really not satisfied with the presence of the gboolean panel_is_split = panel->list_cols > 1 variable and subsequent branchings on it. The generic formula that divides into N columns should work just fine even if N==1. I'll clean this up tomorrow.

[egmontkob]

mc-4906-brief-columns-width-easy-bits-v2.patch

There's still one branching on panel->list_cols being 1 or bigger, I've inlined the previous panel_is_split here. This branching suggests that the code here is not yet prepared for "nesting" brief-style and full-style formats (a feature we're not planning to have, just some of the code happens to be prepared for). It really doesn't matter, I'm not planning to clean up this bit right now.

[egmontkob]

PR #4910 created for the "easy bits". It improves the situation by fixing the "rounding error" I've noted 3 comments above. It does not fix the main issue originally reported here.