improve alignment of strings in library fields

[mixxxbot]

Reported by: ronso0
Date: 2018-07-02T22:40:04Z
Status: Confirmed
Importance: Wishlist
Launchpad Issue: lp1779775
Tags: library, usability

---

edit: I extended the list of possible improvements, mostly taken from Uwe's comment below:

• Duration: omit leading zeros
• right-align numbers so big/small values can be spotted easily:
  • BPM (align decimal points) fixed by library: right align BPM, duration & bitrate values #11634
  • duration fixed by library: right align BPM, duration & bitrate values #11634
  • bitrate fixed by library: right align BPM, duration & bitrate values #11634
  • Track # (also omit leading zeros?)
• center fixed-width values (Date added, Last played etc.) to adjust 'margin' to adjacent column values
• ReplayGain: align decimal separator

This would ease finding long tracks and tracks with high/low BPM tracks in large track tables.
Also this could clean up the deck view.

[mixxxbot]

Commented by: uklotzde
Date: 2018-07-08T19:22:32Z

---

This does not only affect the track duration but also various other columns that might be aligned right within their column:

• Date Added
• Year
• ReplayGain
• Key
• BPM
• Bitrate
• Track #

I'm still unsure though, because for the BPM column I prefer to cut off the less significant fractional digits to the right.

[mixxxbot]

Commented by: ronso0
Date: 2018-07-08T20:34:04Z

---

for the BPM column I prefer to cut off the less significant fractional
digits to the right.

I do this, too. So you're saying the columns can't have individual alignments?

[mixxxbot]

Commented by: uklotzde
Date: 2018-07-08T21:09:28Z

---

I just tried to expand the scope of your valid request and didn't metion any technical preconditions or requirements ;) Generalizing also helps to think about the consequences and implications.

[mixxxbot]

Commented by: ronso0
Date: 2018-07-11T15:27:56Z

---

okay, so let's push this a bit further:
BPM: align left, but reserve space for 3 digits before the decimal point

this allows to align the decimal points and resize the column to hide the decimal places

[mixxxbot]

Commented by: beenisss
Date: 2019-02-25T20:57:52Z

---

There has been some progress on this, eg
#2001
#2002

I'm working on some further tweaks for the bpm column also.

Any other particular fields to nominate for alignment changes etc?

[veeroohre]

I'd prefer to have an alignment of the "filepath" field to the left because I'm more interested in the beginning of the path rather than the filename (e. g. for searching the file in the file system).

[daschuer]

In the right side is elided this allows to see the file name. The tooltip reveals the entire path. The best way to open the track in the file browser is using the right click menu.
Does this work for you? If not, please explain why.

[ronso0]

I assume this is about spotting tracks from certain directories, not about opening containing directories.

[ronso0]

Fix for the BPM and duration column #11634

[veeroohre]

You're right. Opening the correct directory is easy manageable via the context menu. My use case was more about cleaning my music library in the file system. So checking if a file is not in the correct directory would be much easier if I could see the beginning of the path in the track list. Maybe the alignment coud be made changeable for the user (left/right)?

[daschuer]

@veeroohre Please file a new bug for your issue.
For me it is still unclear which folder level you like to see and how the user may want to adjust the view.
Please describe your idea. Do we need a new "Folder" column or such?

[ronso0]

Reopening, because after #11634 adjacent left-aligned columns are to close.

Maybe this can be fixed by adding some horizontal padding to all cells.
For my personal branch I tried AlignHCenter for the date columns (date added [to library | to playlist], last played).

What do you think?

[daschuer]

A unconditionally padding is not desired in case of small screens where users wants to make the best of their vertical space.

A easy fix is to reorder the columns. Can we make use of a different styling?

But I am afraid the DecimalDelegate #11634 (comment) is back on the cutting table. ??

[ronso0]

A unconditionally padding is not desired in case of small screens where users wants to make the best of their vertical space.

true.

A easy fix is to reorder the columns.

I don't understand how this would fix anything when users rearrange columns?

Can we make use of a different styling?

What do you have in mind? I think of horizontal gradients for the background, but that can easily become too noisy and also conflict with the track color bg, so no option.

But I am afraid the DecimalDelegate #11634 (comment) is back on the cutting table. ??

I experimented with that, it's a nice idea but it doesn't solve the issue right away.
However I figured we can achieve right-align and right-elide if we clear the text before style->drawControl() and do drawItemText() separately with a rect limited to 999.9 (considering the selected BPM precision).
That way the column can expand, the BPM would stick to the checkbox and create a margin at the right.
limit the font rect t

[daschuer]

A easy fix is to reorder the columns.

I don't understand how this would fix anything when users rearrange columns?

I meant easy to fix for the user.

I share the concerns with to much visual noise in a styling solution.

Your idea sounds interesting. I am just concerned if this will draw extra CPU.

A solution that will require no extra CPU is a delegate that uses in the first iteration the original QT code from QItemDelegate::drawDisplay() without calling it itself.

From there we have all options to put the pixels where we want.

[mxmilkiib]

Why not just let the user choose the text alignment of each column?

I want my column order like this:

but the "Duration" (such a Length-y title word makes the column wider than it needs to be!) text could be centre aligned to make it slightly easier to read at a glance.

[ronso0]

Even though I partly agree with you, sentences starting with "Why not just ..." make me laugh sometimes (no offence) because most of the time it's not done by flipping a switch, instead serious reworks are required and some developer(s) spend days or weeks to make it "just work". Like in this case. Unfortunately it's not trivial (or at least quite some manual refactoring) to implement adjustable alignment for columns.

An alternative coming to mind:
detect when a right-aligned and left-aligned column are neighbours and add some horizontal margin to one of them.
Fixed margins would affect compact skins like Shade where it's crucial being able to save as much space as possible.

"Duration" (such a Length-y title word makes the column wider than it needs to be!)

You're aware that you can resize columns? Duration spans only that wide when you doubleclick on the right-hand separator to auto-ajust the width (min size).
Btw Duration being right-aligned has the advantage that you can spot long titles like mixes (two digits or more).

[mxmilkiib]

Haha, fair :) though I was coming from a simple-to-make-it-work-for-the-user UX angle not a dev-complexity angle.

Having a small few developers (arguably) bikeshed the text alignment was kinda amusing given the colums can be rearranged in ways that make said arguments null.

To me at least, it looks silly/is frustrating having title text for a column that's always going to be truncated when the column width is at a natural width for its contents. My suggestion (too subtly made above) would be to change "Duration" to "Length" which is ~25% shorter.

But ultimatly I understand I don't know the complex ins-and-outs of the library columns enough so, indeed, take my thoughts with a pinch of salt!

[ronso0]

My suggestion (too subtly made above) would be to change "Duration" to "Length" which is ~25% shorter.

Well, depends on the translation (fr: longueur, es: longitud, etc.), whereas Duration is "Dauer" in german.
Hence I think changing the column name won't help us much. IMHO, once the columns are set up, the headers are relevant only to distinguish some less used columns.

[mxmilkiib]

Fair point. I would modify my proposal to be; use the shortest appropriate word in each translation language.

[ywwg]

Does someone want to work actively on this? If not, this issue is one of polish and imho should not block the 2.4 release. I am open to other suggestions but I'd prefer to triage this list to a set of essential items

[ronso0]

No need for the 2.4.0 milestone here.
IMO this is a meta issue, and I expect it to be fixed incrementally.

I have some fixes stashed (BPM column for example) and will open PRs after 2.4 has been released.

[ronso0]

Moved it to 2.4.1 to have a reminder.

[daschuer]

@ronso0 how is the situation here now?

[ronso0]

I think it's okay-ish now, except for the date columns, ReplayGain and Track #.
I've just updated the desdription #9369 (comment)

As I wrote above I'm totally fine with removing the milestone.

[ronso0]

Re

center fixed-width values (Date added, Last played etc.) to adjust 'margin' to adjacent column values

I have opened #13674 to make some small steps forward.

[ronso0]

ReplayGain: align decimal separator

This one is tricky (like it would be with BPM if we wouldn't have a fixed number of decimals).
Either clamp the number of decimals there, too (fill with 0 if it's less?) or do some magic with QFontMetrics (done on every paint() call ... :\ )
I think this is low prio. Maybe right-align that, too?

[Swiftb0y]

is it feasible to make a best effort guess on how many digits we usually need to show and then just compute the required width once?

[ronso0]

Sure. Though, when computing the length we need to consider that the library font/size can be changed and reset/recompute.

I see 4-6 decimals for my tracks, so 4 would be okay (I don't see the value of more than 2 decimals anyway)
The full value is displayed as tooltip if someone is interested in more precision.

[Swiftb0y]

Though, when computing the length we need to consider that the library font/size can be changed and reset/recompute.

yeah, not sure how much effort it would be to recompute that.