<div dir="ltr">On Fri, Sep 25, 2015 at 1:37 AM, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><br>
</span>They cannot. There is no public coordinate space to even describe it<br>
with. See e.g. <a href="https://www.youtube.com/watch?v=_FjuPn7MXMs" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=_FjuPn7MXMs</a><br></blockquote><div><br></div><div>Interesting demo (looks like Wolfenstein Castle), but it is not uncommon or impossible for finite 3D geometry to have a single global UV space. The Alembic data format used in special effects, for instance, requires that all points on the surface have a unique u,v, value.<br><br>A changing geometry or an infinite geometry would be a problem, though. Perhaps solvable by sending the changed positions as events to clients when the geometry changes.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
It is a design decision in Wayland/desktop to not expose absolute<br>
window positions to clients at all. This means that you simply cannot<br>
know where a top-level window is precisely, you can only know which<br>
outputs it overlaps with.<br></blockquote><div><br></div><div>This is an interesting experiement but I believe it is doomed in the long run. I would try it but I think the end result is that every single desktop environment will add this as an "extension" because so much software will not work without it. You have to realize that X and Windows and OSX all use 2 numbers to describe the location of a window, and thus getting software to stop assuming that is probably a Sisyphean task.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Windows that are not top-level can often be placed relative to another<br>
wl_surface. This is the only form of precise positioning supported on<br>
desktops.<br></blockquote><div><br></div><div>This is correct and could make it work in the vast majority of cases, but supporting portable programs is going to be difficult and hacky. Qt code, for instance, calculate QPoint objects (which contain 2 numbers) and assume the result fully defines where a menu will pop up. Now they usually calculate these by asking for the position of existing widgets and adding offsets, so if the returned coordinates are in a space such that the future parent is at 0,0 then this will work acceptably. But I fully expect Qt to first look for the window-position extension and use that if possible, with this hack as a rarely-used fallback.<br><br></div></div></div></div>