random window position with desktop shell

[Daniel Stone]

Hi,

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:
http://lists.freedesktop.org/archives/wayland-devel/2013-April/008665.html

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

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

Cheers,
Daniel

> 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
>>>> 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
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
>
> --
>   Jasper