One more down: https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/73

What exactly would be needed as an upstream change in Qt? Note that you can use Drag together with DragHandler, which I think isn't too bad. If you really want a one-stop shop convenience element, providing something like

With the latest iteration of the property system, properties can be changed from "old-style" to "new-style" in an ABI compatible way, as the long as the class is already PIMPLed. The documentation for how all of this works should hopefully appear before 6.0 beta 1.

That won't happen for Qt 6.0, as nobody had the time to do the necessary work in QIcon/QIconEngine, but maybe it can be done before 6.2.

Indeed, that is a strong indicator to use this approach

In D27336#610477, @aacid wrote:

Not really, start freecell game 9998, it counts 5 moves as 4, only the first 2 are "counted together"

So I think this depends in part on whether we want to have an atomic undo/redo for automatic moves. With your change, every single move in the auto move will be put on the undo stack. The behaviour before was that they were all composed into one "big" move.
If we want to keep the existing behaviour, we would need to modify DealerScene::moveCount() to changes.size() of the undo stack elements and m_currentState into account.

Sorry, this fell by the wayside. I've had the results attached in a comment in https://phabricator.kde.org/D23507 for my system. I'll make the benchmark optional real soon™…

Moved function back so that the diff shows the actual change more cleanly

Turns out that QDom actually won't go away, but we still need to check for any usage of deprecated APIs from QDomDocument

While the change should be fine as is, that sounds like a job for std::deque, as we don't need insertions/removals at random positions. Or even for a std::queue, because we only operate on the front.

(include BUG line)

This is hopefully already a minimal fix for the crash issues, and it does not depend on Qt 5.12 features. @wbauer It would be most helpful if you could test whether the original bug is indeed no longer occurring after this patch.

And this might have been the source of all problems (and adding it to the original code is probably sufficient, though I still think that the revamped memory management is a good idea): The FcSolveSolver did not call free, which left the MemoryManager in an unideal state, and would probably lead to (non-graciously handled) out-of-memory situations. This too should be fixed now.

• add missing call to free in FcSolveSolver::patsolve

The issue with the previous version was that the memory accounting code was wrong, and the allocation would fail at some point. The most recent version fixes this, and I could successfully complete a game of Grandfather's Clock again.

• fix memory accounting

Ah, I managed to reproduce the crash, and the interesting line of my backtrace is
#7 0x0000555a64cb306d in MemoryManager<19>::BLOCK<POSITION<19> >::getItem (this=0x0) at /home/fabian/projects/kpat/patsolve/memory.h:90

Thank you very much for testing the patch. Could you maybe compile kpat with
cmake -DCMAKE_BUILD_TYPE=Debug -DECM_ENABLE_SANITIZERS='address,leak,undefined' ..
and report back any backtrace you get from playing Grandfather's Clock? I again cannot reproduce the crash :-(

Using the new benchmark, we can see some improvement, mostly in the single threaded case:

The micro benchmark is rather simplistic, but I hope still better than nothing (and I want it to show that D23507 makes sense)

The reflow in Phabricator's UI breks my ASCII diagrams, the git commit message should hopefully still be readable.

Unfortunately, there are no unit tests at all, as there is a rather tight coupling of UI code and game logic. The RNG could however be tested in isolation. Though I'm not sure how one could test whether it behaves the same as Microsoft ones.

Thanks for the patch. I can't reproduce the crash, but I agree with you that this is UB and should be fixed. I don't think that this changes how the RNG works, but even if it would, not crashing is more important.

Well, considering that it does look better now, and I'm not aware how to derive any better values, I'll say ship it. Do you have commit access?

This does indeed look better, and I didn't saw issues at screen resolutions I could test.

Yikes, your reply went victim of an overzealous spam filter rule, sorry for the late reply. Considering that there are a few outstanding bugs like bko 397817, I think I will delay merging this for a little longer. I think I probably should first attempt to write some integration/unit tests, to ensure that it really works.

@aacid : Ouch, I wasn't aware of that, and hoped that phabricator would do the right thing. I know how to do this correctly using git, but I have no clue how I get arcanist to preserve the author. Could you point me to the appropriate documentation, so that this mistake doesn't happen again?

Thanks for the heads-up Christoph, I'll look into the bug report. For reference, I'm simply “Fabian” on bko.

Well, thanks everyone for adding the required libraries, and sorry @bcooksley for not giving notice in advance.

Oh my, I probably should have closed this. This was more intended to make testing https://phabricator.kde.org/D11844 possible, and the changes from there landed on KLook's qt5 branch. I deem the current Dolphin code not suited for upstream. KLook should probably changed so that it can be DBus activated and QProcess can be avoided, and applying this patch caused a few runtime warnings when using Dolphin if I recall correctly.

I currently don't have any *BSD to test, but it still works on Linux, and the change seems sensible, so +2.

Sigh, could have thought of this. Yeah, I'll open a ticket.

Oh well, time to get this merged. I didn't get *too* strong objection from the mailing list, so I intend to merge this as is. Thank you very much @shlomif for your patience and your code contribution.

Yeah, sure, I'll send the mail.

Sorry, I technically reviewed it already, but forgot to hit submit :-(. I'm happy with the current state of the code (sans that one copyright line), and the solver does a better job than the current one.

Considering that currently no one (including me, the de-facto maintainer) really knows what the solver is doing exactly and how the numbers for the search in it were derived, I appreciate outsourcing the logic to a library. However, like @aacid said, it would be nice to have either some numbers how the solver compares.

Yes, I have commit access. This should (arc) land in master?

I'm to tired to test this myself, but could you please test this with the edge case where some file names are so long that they don't fit in the view? Also, Stretch disables manual resizing, right?' If that is also deemed useful, we could adapt the solution from https://centaurialpha.github.io/resize-qheaderview-to-contents-and-interactive. That's pyqt, but the same idea applies to C++. The resize event handling code is even already there, just needs to be adjusted.