random window position with desktop shell

[Daniel Stone]

On 25 September 2015 at 18:46, Bill Spitzak <spitzak at gmail.com> wrote:
> On Fri, Sep 25, 2015 at 1:37 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>> 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

We have, ever since Wayland's creation. It works.

> but I think the end result is that every single desktop
> environment will add this as an "extension"

None of them have: not GNOME, not KDE, not Enlightenment, not IVI, not
digital signage, not video walls, not set-top boxes, not smart TVs,
not Weston/Maynard on Raspberry Pi, not phones/tablets, not anything.

> because so much software will not work without it.

It does.

> You have to realize that X and Windows and OSX all use
> 2 numbers to describe the location of a window

Yeah, I'm well aware of how the X input stack works.

> and thus getting software to
> stop assuming that is probably a Sisyphean task.

It hasn't been.

>> 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.

Your expectations are wrong. Look at how Qt has worked just fine (and
shipped in many environments) without it for years.

This is another dead end of a thread. It's been this way for years
because of very valid reasons, it works (despite you being convinced
that it could never work) fine, and it's not changing.

If you'd like to productively contribute to this, perhaps you could
pick up the surface position negotiation protocol, which would allow
clients to guarantee that menus would not be positioned off-screen.

Cheers,
Daniel