View Issue Details

IDProjectCategoryView StatusLast Update
0022109MMW 5Tracklistpublic2026-09-18 14:27
Reporterrusty Assigned To 
PriorityurgentSeveritymajorReproducibilityalways
Status assignedResolutionopen 
OS--OS Version-- 
Product Version2027.0 
Target Version2027.0 
Summary0022109: Auto-column widths: column widths don't adjust as expecetd
DescriptionIf the user enables auto-column widths, the current design doesn't work well whenever the user shrinks the MM tracklist width either by resizing the window or expanding the right/left columns, if the number/size of the columns don't fit into the available space. When this occurs:

1) If the user tries to increase the width of columns so that text is visible
--> The column's width is increased by shrinking the width of the column to the right! This isn't expected.
--> The maximum amount that the width can be increased is limited by the width of the column to the right!

Auto-sizing shouldn't break column editing functionality (it should be a one-time adjustment).

2) Collapsing/Expanding the right/left panels permanently narrows the amount of text displayed, resulting in a bunch of empty space, forcing the the user to manually adjust column settings each time the right panel is expanded/collapsed!

These issues result in a very poor user experience--the utility of the functionality shouldn't be dependent on the number/size of columns vs the size of the tracklist.
TagsNo tags attached.
Fixed in build

Relationships

related to 0022110 resolvedrusty Auto-column widths: Using the horizontal scrollbar triggers mass selection 

Activities

petr

2026-09-17 11:36

developer   ~0082222

Please describe what behavior is expected

rusty

2026-09-18 14:26

administrator   ~0082281

There are two possible approaches:
A) make resizing a one-time operation (like Windows Explorer) rather than a mode
B) make resizing a mode that is triggered at certain times (the current approach)

In my original comments, I was leaning towards A, but now see the benefits of B. However, the current implementation of B is problematic in the sense that:
1) If the user tries to increase the width of a columns so that text is visible
--> The column's width is increased by shrinking the width of the column to the right! This isn't expected.
--> The maximum amount that the width can be increased is limited by the width of the column to the right! It shouldn't be.

2) Although it activates when the window is resized, it doesn't activate when left/right panels are opened or closed. Resizing should be triggered whenever the width of the tracklist changes.

The key changes to making this work better are:
a) Resizing shouldn't be triggered when adding columns, deleting columns, or manually adjusting column widths. And when the user performs such operations it should be possible for the columns to exceed the width of the screen. A good reference implementation of this is in the macOS finder.
b) Auto-resizing should have minimum widths for each column so that they are somewhat useful. e.g. there's no sense in narrowing title to 3 characters. In other words when auto-resizing is triggered it shouldn't _force_ all columns to fit into the width of the visible portion of the tracklist if doing so shrinks columns beyond their minimum widths.
c) Resizing should be triggered when panels are enabled/disabled (as they are on window resizing)

The macOS finder implementation is pretty much as described above, except that it also 'resets to default' each time the window is re-opened. I would suggest that it's preferable to preserve the relative column widths where possible. e.g. if the user increases the width of the Album artist field relative to its minimum width, MM should try to maintain the increase in relative width.