It turns out that the order of these functions matters. So when we created a
function with only one param, it would actually give it the index. Removing
with the index didn't work, so the object would still be there. The Qt objects
would already be deleted which caused segfaults
CURA-9222
This was still being used in the MaterialBrandsMenu and the SimpleButton
Probably why the X es were missing from the info messages. CURA-9110
Contributes to CURA-8640
This looks like it's consistent with the normal menus. And it fixes the issue where multiple menus can be shown at once because it would hide slower than show the next one.
Contributes to issue CURA-8640.
Getting a bit complex with the timers there and which pop-ups need to stay open. But it seems to be working reliably now.
Contributes to issue CURA-8640.
The sub-menus were giving segfaults for some reason. We couldn't figure out how to circumvent that. So now we're at a last resort: Implement the whole thing ourselves, but with Popup instead of Menu.
Contributes to issue CURA-8640.
This causes a binding loop when using layouts like Column.
To resolve this the height/width of the popup in ExpandablePopup can now be set explicitly with contentWidth and contentHeight
For ExpandablePopups with contentItems that are not Layouts the implicitWidth/implicitHeight can be set directly in the contentItem.
CURA-8640
Removed the ContentAlignment enum in ToolTip in favour of using the Text.ContentAlignment enum. For some reason references to this enum fail everywhere when ToolTip is moved into Uranium. There is some evil time-wasting magic cast on this component!
CURA-8943
Conflicts:
plugins/ImageReader/ConfigUI.qml
plugins/PerObjectSettingsTool/PerObjectSettingsPanel.qml
plugins/PerObjectSettingsTool/SettingPickDialog.qml
resources/qml/Dialogs/DiscardOrKeepProfileChangesDialog.qml
resources/qml/Menus/ConfigurationMenu/CustomConfiguration.qml
resources/qml/Preferences/GeneralPage.qml
resources/qml/Preferences/Materials/MaterialsPage.qml
resources/qml/Preferences/Materials/MaterialsView.qml
resources/qml/Preferences/ProfilesPage.qml
These conflicts are all arising from headers/includes being updated at the same time, or from the two branches marking the other one's components as needing OldControls.
This introduced more OldControls markers which don't get marked as merge conflicts by Git. This happens when an element could just be left as the original name but from the new import (e.g. a Button stays a Button in Controls 2, but should be marked as from OldControls on the branch that doesn't update the Button).
