Having PlatformScreen emitting signals that ScreenPlatformWindow listens to is not a bad idea. I've tended to avoid that approach as it's not really how the API suggests to be used (instead it expects the Screen to be removed and a new one added with the updated state), but if it works, it works.
You have to take a little care with the signal emission, as I believe PlatformScreen::setMirDisplayConfiguration is called on the Qt thread, so the signals are connected to directly by QML, but the handle*Changed are always handled async. Probably not a big deal.
Having PlatformScreen emitting signals that ScreenPlatformW indow listens to is not a bad idea. I've tended to avoid that approach as it's not really how the API suggests to be used (instead it expects the Screen to be removed and a new one added with the updated state), but if it works, it works.
You have to take a little care with the signal emission, as I believe PlatformScreen: :setMirDisplayC onfiguration is called on the Qt thread, so the signals are connected to directly by QML, but the handle*Changed are always handled async. Probably not a big deal.