Here you switch from Type *var to Type* var

same

same

same

Should we truncate the current list if the new max items is smaller?

Missing reference

manimum url → maximum URL

Weren't there ABI issues with std::list?

Also, missing reference on url.

Why not int since it's what we expose in the API anyway?

QStringLiteral("...").arg() would be more readable imho.

This is a porting guide, not sure it belongs in the main apidox of the class. (users of this new API may not know/care about KRecentFilesAction).

I'm getting a warning about signed/unsigned compare otherwise

We use std::list in other frameworks and IIRC no one complained

If we're rewriting this thing anyway, can we please make sure it does not block application startup checking if those files exist, as can happen if you had opened files on an NFS mount before.

Either do it only when the menu is opened (aboutToShow) and/or asynchronously.

New entries are pushed to the front, which works in constant time for std::list and linear time for std::vector
When the maximum is reached the last element is removed which works in constant time for both.

We could turn it around and add new items to the back and iterate reverse, but then removing the front item would take linear time for std::vector

Given that n is small (<10 by default) it shouldn't matter much anyway

I'm wondering how to best make this async without selling my soul to the mulitthreading devil. QtConcurrent::filtered looks interesting, but depending on QtConcurrent wouldn't be feasible, would it?

Depending on QtConcurrent is just fine. However QtConcurrent::filtered is for CPU-intensive operations, not for I/O operations. 1) you don't want to put blocking runnables in the global thread pool [can be solved by assigning to a different threadpool], 2) I don't think you really want to parallelize 16 calls to QFile::exists, for the case of a local physical harddisk? Not sure it would really harm (we're not reading 16 files, at least), but for sure the overhead of dispatching runnables to 16 threads would make it slower... One solution here might be just a dedicated thread iterating over the list.

However: note that the usual KIO way to do file operations async isn't multithreading, it's rather KIO jobs.
This would move the "5 minutes waiting for an NFS server" horror case into a kioslave rather than a thread, both achieve the desired outcome which is to not block the GUI thread.

Keeping the order of the entries is going to be interesting. I guess we need a temporary data structure which stores "exists | does not exist" for each entry, and once all jobs are done, we go through that and fill the menu. Note that remote URLs should just be assumed to exist, we don't want to actually check (slow; might prompt for password; might error on different networks; etc.).

Unlike Kai-Uwe, I think this should be a separate merge request though, it's all quite orthogonal to your work. As long as you confirm that filling the menu "later" has no negative impact on the API (i.e. the user of the class cannot assume that the menu is filled in immediately).

As long as you confirm that filling the menu "later" has no negative impact on the API (i.e. the user of the class cannot assume that the menu is filled in immediately).

Should be fine

QMenu is a QWidget. Why not just pass menu as argument?
It would use the menu's font which is more correct than the parent widget's font (the menu font could be set by a stylesheet or by QApplication::setFont(font, "QMenu").

Also menu is never null, which simplifies the code in the method being called.