random window position with desktop shell

[Bill Spitzak]

On Fri, Sep 25, 2015 at 1:37 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

>
> They cannot. There is no public coordinate space to even describe it
> with. See e.g. https://www.youtube.com/watch?v=_FjuPn7MXMs
>

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.

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.

It is a design decision in Wayland/desktop to not expose absolute
> window positions to clients at all. This means that you simply cannot
> know where a top-level window is precisely, you can only know which
> outputs it overlaps with.
>

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.

Windows that are not top-level can often be placed relative to another
> wl_surface. This is the only form of precise positioning supported on
> desktops.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150925/2e35dc13/attachment.html>