<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 9, 2015 at 5:58 AM, Jonas Ådahl <span dir="ltr"><<a href="mailto:jadahl@gmail.com" target="_blank">jadahl@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""></span><span class=""><br>
</span>Yea, an inverse of xdg_surface.set_parent on xdg_foreign sounds like the<br>
best option to me too. We can't be too specific though, adding too much<br>
DE design into the protocol (like making it modal or other things that<br>
might not apply to non-GNOME(?)).</blockquote><div><br></div><div>I would think "this is exactly the same as xdg_surface.set_parent" would be sufficient, since any "desktop specificity" is already defined by the existence of the xdg_surface.set_parent api.<br><br></div><div>This "foreign" idea will work. I can't think of any useful objects that are not already globals other than surfaces, xyz_surface (where xyz is each possible shell api), and cursors, therefore my concern that you would be effectively doubling the number of object types in the Wayland api by adding a foreign version of every one of them, might not be true.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Not adding too much new terminology<br>
might be preferable as well. There is no such thing as a "dialog"<br>
anywhere yet for example; is it different from a xdg_surface with a<br>
parent, and if so in what ways?<br></blockquote><div><br></div><div>Agree that the compositor should only be interested in whether a surface has a parent. Whether something is a "dialog" is a nebulous concept that is not part of the compositor api.<br><br></div></div></div></div>