random window position with desktop shell

Tue Sep 29 06:55:52 PDT 2015

Hi,

On 29 September 2015 at 14:05, Benoit Gschwind <gschwind at gnu-log.net> wrote:
> Maybe my thought is insignificant, but I would like to share it anyway,
> as young window manager developer.

It's fair enough, and I see what you have to say. All I really have to
say in return is two things:
  - if we add global co-ordinates back now, we can never remove them:
people will rely on them, and removing them will break peoples' apps.
As the kernel's regression policy has shown, it's better not to break
things that work already.
  - certainly neither of those things have happened yet, but that
doesn't mean they can't ever happen; if we exposed global
co-ordinates, people would just use those and _never_ work on these
sensible replacements, thus removing all incentive to work towards a
better protocol

For those reasons, I'm holding out personally.

(FWIW, the XWayland integration picks one 'master' view of a surface
for positioning purposes, and ensures that XWayland positions its
windows at the same point, to account for X's dependence on a global
co-ordinate system.)

Cheers,
Daniel

> I think all your arguments (both side) are valid. But I will defend the
> point of view of Jasper. While technically I agree there is no need of
> absolute positioning and many solution are available to solve issues of
> no-absolute position. I will submit 3 arguments. The first one is that
> current proposed solution of no-absolute position case are not existing,
> i.e. only marginal, experimental or not at all implemented, but there is
> many running software out there that rely on legacy absolute position.
> Jasper (as I understood) propose to add a layer to make the transition
> smoother and easier. This doesn't hurt too much, imo.
> The second one is that most of main stream software transition follow
> this rules, having a transition period (or "mercy" period), I will take
> three examples. Within gcc architecture that are not maintained fall in
> deprecated state for few release cycle, if no one maintain it during
> this "mercy" period, they get removed. The developers have few release
> cycles to adapt. GTK use a similar policy by deprecating APIs. And the
> last exemple, I still be able to run 32 bits apps on my shiny new
> laptop. I think it's no hurt to give the opportunity to the developer to
> have a "mercy" period, within they can learn Wayland and adapt their
> software.
> The third one is that even if you try you best to have a clean protocol,
> I'm sure developers will find ways to abuse or exploit your protocol in
> a way you never thought. In those case I think the best choice is to
> manage those exploits and not trying to _enforce_ you protocol (I do not
> cover security with this sentence).
>
> All in all, I think that having a dedicated "compatibility to X11
> legacy" extension is useful, this extension can be deprecated and
> removed over time, until solutions proposed are effectively implemented.
> I also agree that this layer should be smallest as possible. With this
> kind of extension, old X11 developers can get used with Wayland
> philosophy and learn. If you put a tall fence between old developers and
> wayland, you will be in lose-lose case, application developers will hate
> you for your unshakable church and you get less people that use your
> work. I also want to recall that old software have also a lot of
> experiments behind them and this is them that will have the most hard
> work: migrating to Wayland. In his side, Wayland is a  small peace of
> code (and the protocol is even smaller).
>
> Best regards.
>
> --
> Blocage
>
> "The most secure network protocol is no-network at all".
>
>
> On 28/09/2015 20:55, Daniel Stone wrote:
>> 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
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>