The test case is following:
User tries to cancel old pairing and to pair new smartwatch
click to Pair button
confirm UnPairing
select smart watch type (e.g. PineTime)
select smartwatch according to advertised name or mac address (e.g. InfiniTime CC:88:11:33:FF:88)
after successful pairing should be shown first page, but it isn't
Explanation:
The DialogPL implements onAccepted method. The method it self performs app.pages.pop(), then unpairAccepted() is invoked and calls app.pages.replace(PairSelectDeviceType). The consequence is that the FirstPage is disposed and app.rootPage is set to null.
I am not 100% sure if this behaves same with all UI flavors. My best guess is that is this is that yes. The code shows that kirigami, uuitk, and qtcontrols implementation does .pop() it self.
I have also included some tiny fixes I believe should work the same on all platfroms
The position of BusyIndicator was incorrect. I guess it was caused by my of ui/qml/components/platform.qtcontrols/BusyIndicatorPL.qml, but I believe it is better to set anchors explicitly to allow use of BusyIndicator inline.
The PageMenuItemPL visible, was for me somehow cryptic for me, I believe it works the same.
The test case is following: User tries to cancel old pairing and to pair new smartwatch
Explanation: The DialogPL implements onAccepted method. The method it self performs app.pages.pop(), then unpairAccepted() is invoked and calls app.pages.replace(PairSelectDeviceType). The consequence is that the FirstPage is disposed and app.rootPage is set to null.
I am not 100% sure if this behaves same with all UI flavors. My best guess is that is this is that yes. The code shows that kirigami, uuitk, and qtcontrols implementation does .pop() it self.
I have also included some tiny fixes I believe should work the same on all platfroms