random window position with desktop shell
daniel at fooishbar.org
Mon Sep 28 11:55:24 PDT 2015
On 28 September 2015 at 16:54, Jasper St. Pierre <jstpierre at mecheye.net> wrote:
> To be honest, the more I think about it, the more likely I am to just
> want to add back in a global coordinate system. There's too many
> problems that GNOME is having by omitting it. For starters, menu and
> tooltip positioning that works correctly.
You don't need a global co-ordinate system for that:
> Saving and restarting window
> positions is something that I've desperately missed ever since I
> started using Linux on my multimonitor desktop rig again.
You don't need a global co-ordinate system for that: the consensus for
save/restore has long been for a cookie-based system, which would
allow the compositor to store position, workspace, and any other
> I don't see many of the advantages of omitting a global coordinate
> system anymore, and I don't see many downsides, and a lot of issues
> we're having seem to be predicated by this. I want Wayland to succeed,
> and that might mean that we go back to a simpler idea.
Those are two problems, both of which are well understood and
relatively easily solved.
Omitting a global co-ordinate space does solve a great deal of
problems, particularly in the input space, and opens up a whole array
of possibilities that X's communication of a flat global co-ordinate
space precluded us from ever pursuing. Rowing back on that because of
two problems which can be better solved elsewhere would be a real
waste, and not something I've seen any appetite for amongst the
> On Mon, Sep 28, 2015 at 2:13 AM, Daniel Stone <daniel at fooishbar.org> wrote:
>> 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
>>> 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.
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
More information about the wayland-devel