(fix) apply Library date format, fix 'dateadded' filter by ronso0 · Pull Request #16047 · mixxxdj/mixxx

ronso0 · 2026-02-26T11:14:40Z

Follow-up for #15898

xARSENICx · 2026-02-27T10:03:10Z

I went through the fixups, they look good to me.
I can verify the breakages on my end:

Broken reapplication of custom format upon switching back to custom from a preset.
Missing backend hook (i completely missed it in my PR)

daschuer

I cannot confirm that "Apply" works. My test:

Show tracks view with the "date added" column
Date is shown as 3/1/26
Select ISO in preference
Nothing happens (unlike the text font for example)
Closing the preferences via Cancel
Date format changes to ISO.

My expectation is that it returns to the system default.

Apply does not change the date format.
It looks like that closing the dialog allays applies, regardless which button is used to close the dialog.

ronso0 · 2026-03-01T14:53:49Z

Okay, the wording "apply" was not adequate: previously the format was not saved at all, now it's saved on every change.
Will fix to save on Apply/Okay so it's consistent with the other settings.
First I didn't care because the dir actions are also applied immediately (no reset on Cancel), but date format should indeed be more in line with the font settings (reset on Cancel).

Nothing happens (unlike the text font for example)

That is a repaint issue: on font change a repaint seems to be triggered immediately, for date format change you need to hover the library for that.

daschuer · 2026-03-01T19:03:15Z

Apply/Cancel/OK works now. The mass refresh is missing on Apply. Hovering does the refresh.
How is it solved with the Font format? Can we add the refresh after Apply?

ronso0 · 2026-03-03T09:17:51Z

Well, setting a font on a widget emits a QEvent::FontChange signal which invalidates the layout and triggers repaint.

Here, emit dataChanged() for each date column would be simple -- but the date is set in a static function, so no access to the model instances.
Two ways to refresh come to mind:
1 A minimal singleton relay (learned something about Meyers Singleton) to which all model instances connect their slotDateFormatChanged() to and emit dataChanged() in order to update the views (only the visible one would repaint).
2 A method like WLibraryTableView::setTrackTableFont which does model()->dateFormatChanged() which does then emit dataChanged() for the date columns.

I find 1) more interesting tbh, but I don't know if 1 or 2 are worth the effort.

Btw I think we don't need the instant update on change (without Apply) as well as reset on Cancel like for the font -- the date preview string is sufficient IMO.

ronso0 · 2026-03-03T11:08:15Z

2 A method like WLibraryTableView::setTrackTableFont which does model()->dateFormatChanged() which does then emit dataChanged() for the date columns.

This is cumbersome, too, as it requires including BaseTrackTableModel (huge) in WLibraryTableView.
I'll try the singleton, just because I'm curious.

ronso0 · 2026-03-03T11:53:08Z

This is my test with the broadcaster as proposed above. Works just fine!
(or use Mixxx' Singleton and createInstance() in library.cpp, ifndef QML I guess)
Let me know what you think!

Note: all views receive the dataChanged() signal and while all seem to do some prep work (layout may have changed, doesn't apply here) only the visible view is repainted.

still think it's too much just for the date update but I learned something in this experiment

ronso0 · 2026-03-04T10:46:20Z

I simplified the broadcaster (is now a Mixxx Singleton) and it works well.

Again, if you consider this too much for the update purpose, I'll remove it.
But it has been a nice exercise!

ronso0 · 2026-03-09T15:39:43Z

ping @mixxxdj/developers
Let's merge this fixup, we need it for 2.6

The 'instant update' thingy is debatable of course, am okay to merge without that.

ywwg

code looks fine to me, did not hand-test

ronso0 · 2026-03-14T20:53:08Z

ding dong can we merge the fix? with or without instant update, idc

JoergAtGithub · 2026-03-14T20:58:06Z

CI is failing!

ronso0 · 2026-03-14T21:46:28Z

Ah, the fixup commit. Squashed now.
The failure of ControllerScriptEngineLegacyTimerTest.beginTimer_repeatedTimer on Win 11 arm64 is not related to this patch.

ywwg · 2026-04-07T21:05:27Z

    }

    int dateIndex = comboBox_dateFormat->findData(QVariant::fromValue(preset));
+    qWarning() << "-> idx:" << dateIndex;


these warnings look more like debug comments. The mixxx warning log is already very noisy, try to be efficient and minimal in your logging output, with as few lines as possible and identifying information in the line about what's being logged. Probably these can all be totally removed.

that's from the TRACE commit which is of course removed before merge.

The other commits look good?
Did you test it?

ronso0 · 2026-04-11T15:43:58Z

@daschuer @ywwg please take second look, test or whatever you feel is required to get this merged.
See testing notes above.

ronso0 · 2026-04-23T12:30:59Z

ping
this has also come up in the forum https://mixxx.discourse.group/t/mixxx-finding-new-tracks-not-more-in-library/33476/30

andynahtod · 2026-04-23T16:18:19Z

Here is the output

ronso0 · 2026-04-23T16:39:27Z

Thanks, does everything work as expected?
(need to check the output only if it doesn't)

andynahtod · 2026-04-23T17:14:00Z

The local time format still isn't working; it only displays YYYYY-MM-DD

ronso0 · 2026-04-23T17:37:14Z

I need more details:
which format is selected in Preferences -> Library?
which format is used in the tracks view?
which formats work in the searchbar?

and the what happens when you select another format in the preferences, eg. Regional Long?

andynahtod · 2026-04-23T18:19:29Z

Okay, now I've tested it more extensively.

Regional Short -> searchbar works -> tracks view: d/M/yy
Regional Long -> searchbar works -> tracks view: dd.MM.yyyy
ISO 8601 -> searchbar works -> tracks view: yyyy-MM-dd
Custom with dd.MM.yy -> searchbar works -> tracks view: dd.MM.yy

Native (System Default) -> searchbar doesn't work -> tracks view: dd.MM.yy

Edit: Native (System Default) -> searchbar ISO format works -> tracks view: dd.MM.yy

Is this version 2.7? Will this be fixed in 2.5 or 2.6?

ronso0 · 2026-04-24T03:50:58Z

So all options are working now?

ronso0 · 2026-04-24T03:55:01Z

Is this version 2.7? Will this be fixed in 2.5 or 2.6?

Yea, this is a fix for a 2.7 feature (main = 2.7-alpha)
I'll set up a separate debug branch for 2.5/2.6

andynahtod · 2026-04-25T18:41:07Z

So all options are working now?

I find the different formats of the native (system default) searchbar and library confusing.

I'll set up a separate debug branch for 2.5/2.6

Have you done anything yet? Should I test something?

ronso0 · 2026-04-25T22:50:29Z

I take that as a yes.

What exactly is confusing about the date options?

Have you done anything yet? Should I test something?

Not yet, will let you know.

Native (System Default) -> searchbar doesn't work -> tracks view: dd.MM.yy

oh, that doesn't work.
Can you please share the console output when you search?

andynahtod · 2026-04-26T06:48:51Z

What exactly is confusing about the date options?

Native (System Default) -> In the search bar, the format yyyy-MM-dd works, whereas in the tracks view it is dd.MM.yy

Can you please share the console output when you search?

warning [Main] slotUpdate, dateformat: ""
warning [Main] -> idx: 0
warning [Main] -> setCurrIdx
warning [Main]     slotDateFormatIndexChanged 0
warning [Main]     slotDateFormatChanged, text: ""
warning [Main] Skin parsing failed at skins:Deere/library.xml:45 <Splitter>: Reading .cfg file: '[Skin] coverArt_splitsize 412,0,86' does not match the number of children nodes:2 | /usr/src/debug/mixxx/mixxx-lib-date-format-fixes/src/widget/wsplitter.cpp:67
warning [Main] --> parse date "2026-04-19"
warning [Main] --> valid date: QDate("2026-04-19")
warning [Main] Failed to load pixmap from path: "skin:/buttons/btn_"
warning [Main] --> parse date "2026-04-19"
warning [Main] --> valid date: QDate("2026-04-19")
warning [Main] --> parse date "2026-04-19"
warning [Main] --> valid date: QDate("2026-04-19")
warning [0x7f3a980014c0] Engine thread not scheduled with the real-time policy SCHED_FIFO
warning [Main] --> parse date "01.02.20"
warning [Main] --> invalid, try Lib format ""
warning [Main] --> invalid, try locale format "dd.MM.yy"
warning [Main] --> valid date: QDate("0020-02-01")
warning [Main] --> parse date "01.02.20"
warning [Main] --> invalid, try Lib format ""
warning [Main] --> invalid, try locale format "dd.MM.yy"
warning [Main] --> valid date: QDate("0020-02-01")

I've shortened it a bit; I hope that's enough

ronso0 · 2026-05-04T22:50:27Z

What exactly is confusing about the date options?

Native (System Default) -> In the search bar, the format yyyy-MM-dd works, whereas in the tracks view it is dd.MM.yy

ISO is always working since that is the format used by the "New" filter in the Analyze view.

And here it is, search is run when the Analyze view is created:

--> parse date "2026-04-19"
--> valid date: QDate("2026-04-19")

I assume that is you tying "01.02.20"

--> parse date "01.02.20"
--> invalid, try Lib format ""
--> invalid, try locale format "dd.MM.yy"
--> valid date: QDate("0020-02-01")

Afterwards we assume that any date before 2000 is based on 1900, so we add 100 years.
BUT I misread the Qt docs for QLocale 6.7+, we need to specify the base year, not century 🤦‍♂️

@andynahtod I pushed a fix, please try again.

andynahtod · 2026-05-05T15:38:31Z

@ronso0 I can't build it src/mixxx-lib-date-format-fixes/src/library/tabledelegates/previewbuttondelegate.h:3:10: fatal error: QPushButton: Datei oder Verzeichnis nicht gefunden

ronso0 · 2026-05-05T17:14:05Z

This PR doesn't touch any delegates, I suggest you force-pull again and retry.
FWIW I always use the gh utility to fetch PR branches:
gh pr checkout -f [PR number], eg. gh pr checkout -f 16047
Only thing you need to prepare is setting github.com/mixxxdj/mixxx as your upstream as described here https://github.com/mixxxdj/mixxx/wiki/Testing#build-pr-branches-yourself

Copilot

Pull request overview

Follow-up to the library date-format feature so the configured format is loaded/applied consistently across library models and the dateadded search filter can parse non-ISO dates.

Changes:

Adds a date-format change broadcaster and hooks BaseTrackTableModel up to repaint date-based columns when the format changes.
Refactors Library preferences date-format state handling so the selected format is loaded from config and applied on update/apply.
Extends DateAddedFilterNode to try the configured library format before falling back to locale parsing, and updates test/bootstrap wiring for the new singleton.

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
`src/test/librarytest.cpp`	Creates/destroys the new date-format broadcaster in library-oriented tests.
`src/preferences/dialog/dlgpreflibrary.h`	Adjusts the preview helper signature and stores current date-format state.
`src/preferences/dialog/dlgpreflibrary.cpp`	Reworks date-format loading, preview updates, and apply-time persistence in Library preferences.
`src/library/searchquery.cpp`	Updates `dateadded` parsing to try the configured library date format.
`src/library/library.cpp`	Creates and destroys the broadcaster during Library lifetime.
`src/library/dateformatbroadcaster.h`	Declares the new singleton signal broadcaster for date-format changes.
`src/library/dateformatbroadcaster.cpp`	Defines the broadcaster implementation.
`src/library/basetracktablemodel.h`	Exposes the active date format and declares a repaint slot for date columns.
`src/library/basetracktablemodel.cpp`	Emits date-format change notifications and refreshes date columns when the format changes.
`CMakeLists.txt`	Adds the new broadcaster source file to the build.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

ronso0 · 2026-05-05T22:25:14Z

+        // Try user date format set in library preferences
+        const QString dateFormat = BaseTrackTableModel::dateFormat();
+        qWarning() << "--> invalid, try Lib format" << dateFormat;
+        date = QDate::fromString(dateStr, dateFormat);


ronso0 · 2026-05-05T22:26:50Z

+        // Try user date format set in library preferences
+        const QString dateFormat = BaseTrackTableModel::dateFormat();
+        qWarning() << "--> invalid, try Lib format" << dateFormat;
+        date = QDate::fromString(dateStr, dateFormat);
+    }
+
    if (!date.isValid()) {
+        qWarning() << "--> invalid, try locale format"
+                   << QLocale().dateFormat(QLocale::ShortFormat);
+        // Maybe custom user format is too esoteric, or user picked
+        // their locale's format.
        // Fall back to locale-specific short format
 #if QT_VERSION < QT_VERSION_CHECK(6, 7, 0)
+        // If the year component has only two digits Qt assumes the base year is 1900.
        date = QLocale().toDate(dateStr, QLocale::ShortFormat);
+        // The Mixxx project was started in 2001 :)
+        if (date.year() < 2000) {
+            date = date.addYears(100);
+        }
 #else
-        date = QLocale().toDate(dateStr, QLocale::ShortFormat, 20);
+        // With Qt 6.7+ we need to specify the base year.
+        date = QLocale().toDate(dateStr, QLocale::ShortFormat, 2001);


Indeed, there is NO date filter test. And I'm not motivated to write one atm.
Let's stick to manual testing (and Copilot) whenever the date filter is touched.

And I have no clue how to involve BaseTrackTableModel into the test 🤷‍♂️

…year

andynahtod · 2026-05-07T04:05:17Z

I pushed a fix, please try again.

Everything works fine.
It would be nice if an abbreviated date (day/month or month/year) were also possible.

andynahtod · 2026-05-07T04:10:28Z

ISO is always working since that is the format used by the "New" filter in the Analyze view.

However, this doesn't work in the Stable version; there, all tracks are always displayed—regardless of whether a filter is applied or not.

ronso0 · 2026-05-07T12:45:31Z

Everything works fine.

Great, thanks for testing!

It would be nice if an abbreviated date (day/month or month/year) were also possible.

True, I'd use this too.
I made an attempt to implement this some time ago, but I stopped when we ran into locale/date format issues.
Will take another look at some point. This basically means to implictly create a range filter like date:>=01.mm.yy && date <=31.mm.yy

ronso0 · 2026-07-09T14:31:47Z

@mixxxdj/developers @ywwg already approved this, can we please merge this regression fix?

github-actions Bot added library ui preferences search labels Feb 26, 2026

ronso0 mentioned this pull request Feb 26, 2026

feat(library): Add customizable date format option for Library and History #15898

Merged

ronso0 force-pushed the lib-date-format-fixes branch from 07f7c91 to 28e39ca Compare February 26, 2026 14:37

This was referenced Feb 27, 2026

fix uninitialized variable in DateAddedFilterNode(); #16059

Merged

Library search: document supported dateadded formats mixxxdj/manual#846

Merged

daschuer requested changes Mar 1, 2026

View reviewed changes

ronso0 force-pushed the lib-date-format-fixes branch from 17f4dca to 028c54c Compare March 3, 2026 12:22

ronso0 force-pushed the lib-date-format-fixes branch from 028c54c to 523df6f Compare March 4, 2026 10:46

github-actions Bot added the build label Mar 4, 2026

ronso0 force-pushed the lib-date-format-fixes branch 2 times, most recently from 19cabc0 to 4cd00cd Compare March 4, 2026 11:41

github-actions Bot added the code quality label Mar 4, 2026

JoergAtGithub requested a review from daschuer March 9, 2026 15:50

ywwg approved these changes Mar 9, 2026

View reviewed changes

ronso0 added this to the 2.7-beta milestone Mar 12, 2026

ronso0 force-pushed the lib-date-format-fixes branch from 4cd00cd to 80e05b7 Compare March 14, 2026 21:45

ywwg reviewed Apr 7, 2026

View reviewed changes

Preferences Library: fix applying date format

f7ffc42

ronso0 force-pushed the lib-date-format-fixes branch from eb44d6e to 7362c2c Compare April 22, 2026 15:26

ronso0 force-pushed the lib-date-format-fixes branch from 7362c2c to 1d20895 Compare May 4, 2026 22:50

JoergAtGithub requested a review from Copilot May 5, 2026 17:41

Copilot started reviewing on behalf of JoergAtGithub May 5, 2026 17:42 View session

Copilot AI reviewed May 5, 2026

View reviewed changes

ronso0 added 3 commits May 6, 2026 00:46

Search: fix 'dateadded' filter, also try custom user format, fix base…

17dab10

…year

add DateFormatChangedBroadcaster to force-update track table views

b97f243

TRACE date search filter

d2e570e

ronso0 force-pushed the lib-date-format-fixes branch from 1d20895 to d2e570e Compare May 5, 2026 22:49

Uh oh!

Uh oh!

Conversation

ronso0 commented Feb 26, 2026

Uh oh!

xARSENICx commented Feb 27, 2026

Uh oh!

daschuer left a comment

Choose a reason for hiding this comment

Uh oh!

ronso0 commented Mar 1, 2026

Uh oh!

daschuer commented Mar 1, 2026

Uh oh!

ronso0 commented Mar 3, 2026

Uh oh!

ronso0 commented Mar 3, 2026

Uh oh!

ronso0 commented Mar 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ronso0 commented Mar 4, 2026

Uh oh!

ronso0 commented Mar 9, 2026

Uh oh!

ywwg left a comment

Choose a reason for hiding this comment

Uh oh!

ronso0 commented Mar 14, 2026

Uh oh!

JoergAtGithub commented Mar 14, 2026

Uh oh!

ronso0 commented Mar 14, 2026

Uh oh!

ywwg Apr 7, 2026

Choose a reason for hiding this comment

Uh oh!

ronso0 Apr 8, 2026

Choose a reason for hiding this comment

Uh oh!

ronso0 commented Apr 11, 2026

Uh oh!

ronso0 commented Apr 23, 2026

Uh oh!

andynahtod commented Apr 23, 2026

Uh oh!

ronso0 commented Apr 23, 2026

Uh oh!

andynahtod commented Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ronso0 commented Apr 23, 2026

Uh oh!

andynahtod commented Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ronso0 commented Apr 24, 2026

Uh oh!

ronso0 commented Apr 24, 2026

Uh oh!

andynahtod commented Apr 25, 2026

Uh oh!

ronso0 commented Apr 25, 2026

Uh oh!

andynahtod commented Apr 26, 2026 • edited by ronso0 Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ronso0 commented May 4, 2026

Uh oh!

andynahtod commented May 5, 2026

Uh oh!

ronso0 commented May 5, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

ronso0 May 5, 2026

Choose a reason for hiding this comment

ronso0 commented Mar 3, 2026 •

edited

Loading

andynahtod commented Apr 23, 2026 •

edited

Loading

andynahtod commented Apr 23, 2026 •

edited

Loading

andynahtod commented Apr 26, 2026 •

edited by ronso0

Loading

andynahtod commented May 7, 2026 •

edited

Loading

andynahtod commented May 7, 2026 •

edited by ronso0

Loading