Library column configuration always breaks when available columns change

[mixxxbot]

Reported by: ywwg
Date: 2014-11-06T15:43:37Z
Status: Fix Released
Importance: Medium
Launchpad Issue: lp1390130
Tags: library, polish
Attachments: before_cover_art.png, after_cover_art.png

---

Whenever a new column is added to Mixxx (most recently, cover art), the saved library configuration gets broken. I think this is because the column layout is saved by raw column index number, and if the new column is inserted into the enum, all the index numbers are wrong. I end up with a bpm column where I had an Artist column, etc. I have to painstakingly delete the incorrect columns and reinsert the columns I wanted.

possible solutions:

• save config by using names, not indexes
• have two column enums -- one for a config number that is only ever appended, and one for the default ordering of the columns which can safely change.

This bites me on every upgrade so I am marking this as important for the next version.

[mixxxbot]

Commented by: ywwg
Date: 2014-11-06T15:48:37Z
Attachments: before_cover_art.png

---

Examples of before and after upgrade to cover art. Total change in libary column layout.

[mixxxbot]

Commented by: ywwg
Date: 2014-11-06T15:48:48Z
Attachments: after_cover_art.png

---

after

[mixxxbot]

Commented by: ywwg
Date: 2014-11-07T20:10:37Z

---

So this is Hard.

We save and restore the column layout using the built-in .saveState and .restoreState functions, which return opaque binary blobs and breaks if the number of columns changes. So just getting the column ordering isn't enough -- no matter what, if we restoreState with an upgraded version of mixxx, the columns will be all messed up because we added a new column. For the 1.11->1.12 upgrade, the best we can probably do is reset the header_state value and restore the default column layout.

See:
http://stackoverflow.com/questions/1163030/qt-qtableview-and-horizontalheader-restorestate

We should probably write our own column-saving serialization, like the one mentioned in that discussion (http://codepad.org/2gPIMPYU). This is annoying, but straightforward enough. When 1.12 starts up, it could ignore the old header_state value and load the default, and then from then on save using the new code. It would be nice if we could migrate from the old code, but this isn't possible without figuring out the binary blob's internals.

[mixxxbot]

Commented by: rryan
Date: 2014-11-24T19:03:15Z

---

Not High priority as per the guidelines:
http://mixxx.org/wiki/doku.php/launchpad_bugs

[mixxxbot]

Commented by: ywwg
Date: 2014-12-06T19:56:00Z

---

Things learned:

• The blob just can't work across changes in the number of visible library columns.
• If we try to write our own header config solution it won't be perfect.

Here's my proposed solution:

• We develop a best-effort header config solution, and usually we only write the value.
• We continue to use the binary blob
• Whenever the database schema affects the number of possible visible library columns, we delete the header_state values and load from the best-effort config

That will preserve the perfect header saving for current versions of mixxx, and will allow some amount of user configuration across upgrades.

[mixxxbot]

Issue closed with status Fix Released.

[naught101]

My library columns still seem to randomly reset sometimes (to all enabled), which can be pretty annoying. I haven't figured out the trigger for it yet though.

Mixxx 2.4-beta on kubuntu

[daschuer]

This is a very old closed bug. Can you file a new one. Is the issue related to an upgrade form 2.3.6?