2025-02-23

Last modified: 2025-02-23 20:23:25

FreeCAD

hyarion put a comment on https://github.com/FreeCAD/FreeCAD/pull/19763 suggesting using a singleton instead of passing it through every function call.

So the new version would be:

• Base::ProgressRange will be a class where the default implementation is total no-op
• Base::ProgressRange::getInstance() will return the currently active instance
• Base::ProgressRange::setInstance() to set it to your custom implementation with gui
• Base::ProgressRange::resetInstance() to turn it back to no-op

And then in the Part module we'll have OCCTProgressRange that takes our Base::ProgressRange as an argument and passes through function calls, and implements Message_ProgressRange.

And the ComputationDialog will be in src/Gui, and will somehow take a closure for a function that it will run in the thread.

Gui::ComputationDialog().run([&]() {
    ...
});

So I'm thinking I copy the FreeCAD directory so that I have a checkout with the current code in, and then reset my branch to current main and start again?

And actually I think we want to be passing ProgressScope rather than ProgressRange?

OK, seems to mostly be working, PR here: https://github.com/FreeCAD/FreeCAD/pull/19796

I don't know why progress reporting is broken.

I made it print a backtrace in the OCCTProgressIndicator constructor, but I only see it happen once, which suggests that the problem is not caused by repeatedly creating new Message_ProgressRanges.

I also see it basically stay on 0% forever, occasionally go up to 1% or 2%, then back down to 0%. Next plan is printing calls to Show().

Oh, I think I see the problem. GetPortion() tells you what percentage of the indicator is covered by the scope - not what percentage of the indicator is filled!

To get the percentage I need to get Value() / MaxValue() I think.

Yeah that was the problem, but Value() / MaxValue() makes it keep flicking between 0% and 100%. I need GetPosition() on the Message_ProgressIndicator, and now it is working well.

We have the behaviour back where it can get stuck at 9% on a PolarPattern and not allow aborting. I feel like this went away before, I guess I put UserBreak() checks in more places?

I'm checking out the old occt-userbreak-2 branch, resetting to before my massive unfinished change, and I'll see if it still gets stuck at 9%. Yes, it was still getting stuck at 9%. Never mind then, no regression. Why did I have trouble reproducing this yesterday then?

Also need to include <windows.h> in ComputationDialog.cpp on Windows to make sure TerminateThread can work. Anything else? ChatGPT says I should call CloseHandle(threadHandle) just after terminating it.

Now re-throws exceptions & progress percentage is fixed, so remaining is:

• use ComputationDialog in more places
• gate "force abort" behind a config parameter, and default to not enabled, since it nearly always segfaults (related is see if we can make it actually work)

I have code that prints a backtrace every time OCCTProgressIndicator() is created, so maybe muck about in FreeCAD, find something that blocks it up, then look at the backtrace and see if the Gui level should be starting a ComputationDialog.

OK, I've made OCCTProgressIndicator store the backtrace in its constructor, and print it out in the destructor if Base::ProgressIndicator::getInstance().isDefaultInstance() and the time since construction was over 1 second. That way I'll get backtraces of code paths that would benefit from having the abort dialog.

I've managed to trigger it from these:

• right click, "Recompute Object"
• right click, "Mark to recompute", then the refresh button in the toolbar
• spreadsheet field
• editing the number in the Properties table

I might be able to find them just by grepping for "recompute" in paths containing "Gui".

In fact in the app document level could I detect if we have Gui and if so use a ComputationDialog there?