Fixups with Qt6 enums

[YakoYakoYokuYoku]

Because PySide6 treats enums and QFlags as IntEnums and IntFlags respectively I've added converters for Python PySide enums to C++, and due to this I've modified the requirements of task panel's getStandardButtons to return standard buttons without casting them to int. Fixes #13605 and part of #13303. Related to #6992.

[adrianinsaval]

and due to this I've modified the requirements of task panel's getStandardButtons to return standard buttons without casting them to int.

can we avoid this? because this sounds like any addon using this will have to be updated to work which is not good

[YakoYakoYokuYoku]

We can't due to both IntEnum and IntFlag from enum neither inherit int nor implement __int__, that's an issue with the standard Python library itself. But is easy enough to update, simply remove the int conversion, like int(QtWidgets.QDialogButtonBox.Cancel) with QtWidgets.QDialogButtonBox.Cancel. This also retains compatibility with PySide2 because the conversion is done at Gui::PythonWrapper::toEnum.

[adrianinsaval]

alternative solution was proposed in a different PR: #13337 (comment)

try:
    # pyside2
    return int(QtWidgets.QDialogButtonBox.Close)
except TypeError:
    # pyside6
    return QtWidgets.QDialogButtonBox.Close.value

while this still means that addons will need to update for qt6 compatibility I think it might be better as they will have more time for migration as they'll retain compatibility with the qt5 releases of FreeCAD

[YakoYakoYokuYoku]

Let me explain for a bit. Those int conversions aren't really necessary, here's why. The PySide2.QtWidgets.QDialogButtonBox.StandardButton flag supports bitwise operations without casting to an int (you can see examples in WB code prior to my PR).

# This
    return int(QtGui.QDialogButtonBox.Ok) | int(QtGui.QDialogButtonBox.Cancel)
# Would be the same as
    return int(QtGui.QDialogButtonBox.Ok | QtGui.QDialogButtonBox.Cancel)

Before my PR, the return value of getStandardButtons regardless of its type is converted to an int through the Py::Int constructor as you can see at line #737 from src/Gui/TaskView/TaskDialogPython.cpp. I took extra care to make sure that this, the C++-side Py::Int cast, remains being done by PythonWrapper when Shiboken is not linked with FreeCAD.

FreeCAD/src/Gui/TaskView/TaskDialogPython.cpp

Lines 730 to 748 in c016f1c

	QDialogButtonBox::StandardButtons TaskDialogPython::getStandardButtons() const
	{
	Base::PyGILStateLocker lock;
	try {
	if (dlg.hasAttr(std::string("getStandardButtons"))) {
	Py::Callable method(dlg.getAttr(std::string("getStandardButtons")));
	Py::Tuple args;
	Py::Int ret(method.apply(args));
	int value = (int)ret;
	return {value};
	}
	}
	catch (Py::Exception&) {
	Base::PyException e; // extract the Python error text
	e.ReportException();
	}
	return TaskDialog::getStandardButtons();
	}

Therefore the following works too.

# Before
    return int(QtGui.QDialogButtonBox.Ok) | int(QtGui.QDialogButtonBox.Cancel)
# After
    return QtGui.QDialogButtonBox.Ok | QtGui.QDialogButtonBox.Cancel

As you can see int conversions aren't necessary in Python code thus they can be removed even if you're using PySide2. So, you can make code compatible with both versions of PySide by discarding those conversions. I hope I was clear enough.

[adrianinsaval]

my question is rather if old workbenches will remain compatible with freecad after this change

[YakoYakoYokuYoku]

Ahh, gotcha. In that case this change retains compatibility between old workbenches and FreeCAD using PySide2, but it won't be the case if PySide6 is used as those may also have other incompatibilities too (like Maker Workbench for example). Though, getting rid of int casts from getStandardButtons in workbenches will be OK for both PySide2 and PySide6.

[adrianinsaval]

In that case this change retains compatibility between old workbenches and FreeCAD using PySide2, but it won't be the case if PySide6 is used

you mean they'll still work after this PR or with the proposal I posted above? PySide6 incompatibility for addons is ok and expected, nothing we can do there they'll have to port.

[YakoYakoYokuYoku]

They'll work with both my PR and the proposal. In case a regression happens I'll take responsability on it.

[chennes]

Just noting that we provide a basic compatibility layer between PySide2 and PySide6 so that some addons do not have to change anything. It may be worth investigating if this can be expanded. See the code generation here:

FreeCAD/cMake/FreeCAD_Helpers/SetupShibokenAndPyside.cmake

Line 77 in 7cf7922

file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/Ext/PySide)

[YakoYakoYokuYoku]

I've already sent PRs to three workbenches which had been merged (Zolko-123/FreeCAD_Assembly4#489, shaise/FreeCAD_SheetMetal#333, shaise/FreeCAD_FastenersWB#366), so far I haven't seen any regressions provoked by them. Those were very simple changes so adding them to your workbench isn't that hard and remains compatible with PySide2.

[adrianinsaval]

argggh I had tested this on an addon that had already been ported. I tested now on cfdOF and the task dialog was missing the close button. I made a PR that fixes this but not all addons will get these updates in a timely manner

[adrianinsaval]

since the python changes seem to be compatible with both qt5 and qt6 without any more effort, what's the point of the c++ changes here?

[YakoYakoYokuYoku]

We can't cast enums to int (using Py::Int before the PR) in Qt6, so you've to use the proper functions, either Shiboken::Enum::getValue or reading the enum value field, that's why the C++ changes.

[adrianinsaval]

Could we make these changes only apply when compiling with pyside6?

[3x380V]

@YakoYakoYokuYoku, damage follows in #13851

[wwmayer]

This fixes the problem: #13902