> This would leave the code in a inconsistent state. We update
> MirSurface::visible when state changes but MirSurface::visible itself is
> defined by an opaque function from an external controller. So no guarantees
> that controller::isVisible indeed changes when surface state changes and, most
> importantly, *only* when surface state changes.
This MP does not effect any of that.
> If controller::isVisible changes due to thins other than surface state
> changes, this MirSurface::visible won't get update and will, therefore, be
> broken.
>
> I think this change should be accompanied by a notification
> miral::WindowInfo::visible changes from miral.
>
> Which makes me think that, while the miral notification doesn't come up in the
> API, we either drop the "&& m_surface->visible()" from updateVisible or also
> track changes to it if possible (which I think it's not)
That would change the meaning of MirSurface::visible - I don't know enough of the purpose of this property to know if that's a good idea.
> This would leave the code in a inconsistent state. We update :isVisible indeed changes when surface state changes and, most
> MirSurface::visible when state changes but MirSurface::visible itself is
> defined by an opaque function from an external controller. So no guarantees
> that controller:
> importantly, *only* when surface state changes.
This MP does not effect any of that.
> If controller: :isVisible changes due to thins other than surface state WindowInfo: :visible changes from miral. >visible( )" from updateVisible or also
> changes, this MirSurface::visible won't get update and will, therefore, be
> broken.
>
> I think this change should be accompanied by a notification
> miral::
>
> Which makes me think that, while the miral notification doesn't come up in the
> API, we either drop the "&& m_surface-
> track changes to it if possible (which I think it's not)
That would change the meaning of MirSurface::visible - I don't know enough of the purpose of this property to know if that's a good idea.