> I would prefer if shell could give miral enough context information (eg, the
> available desktop area) so that it could make correct decision on its own. But
> maybe that doesn't match miral's API style.
>
> But confirm_inherited_move() works as well and is probably safer in case
> something other than the available desktop area happens to affect this
> decision.
Exactly, my concern is that the "available desktop area" isn't a simple concept that MirAL can handle.
In the "tiling" case it is the tile associated with the window.
In Unity8 it is the available region(s) on any outputs (but not associated with any specific windows).
In a lot of window managers there's no constraint - windows can be moved offscreen.
> What I wonder is how much value miral is adding in this specific case (moving
> child windows) with this API. What's more work for shell: validating every
> single child movement or implementing inherited child movement on its own?
I'm imagining that qtmir can implement the "available desktop area" concept as needed by Unity8 and that there's no other work needed further up the stack.
I'd like Gerry's take on this too (see below).
> I would prefer if shell could give miral enough context information (eg, the inherited_ move() works as well and is probably safer in case
> available desktop area) so that it could make correct decision on its own. But
> maybe that doesn't match miral's API style.
>
> But confirm_
> something other than the available desktop area happens to affect this
> decision.
Exactly, my concern is that the "available desktop area" isn't a simple concept that MirAL can handle.
In the "tiling" case it is the tile associated with the window.
In Unity8 it is the available region(s) on any outputs (but not associated with any specific windows).
In a lot of window managers there's no constraint - windows can be moved offscreen.
> What I wonder is how much value miral is adding in this specific case (moving
> child windows) with this API. What's more work for shell: validating every
> single child movement or implementing inherited child movement on its own?
I'm imagining that qtmir can implement the "available desktop area" concept as needed by Unity8 and that there's no other work needed further up the stack.