random window position with desktop shell

[Derek Foreman]

On 29/09/15 08:05 AM, Benoit Gschwind wrote:
> Hello,
> 
> Maybe my thought is insignificant, but I would like to share it anyway,
> as young window manager developer.

No opinion is insignificant. :)

Mine is different than yours, however.

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

Why do we need a global co-ordinate space?  The problems it "solves" are
only partially solved be introducing such a thing, and those problems
can be fully solved properly in different ways.

If we take this half step now we may never get the full solution,
instead we'll go down a path we know is inconvenient from our experience
with X.

Knowing your window's absolute co-ordinates doesn't actually help you
find the edge of the screen if, for example, your application is
rotated.  Or if the screen is round.  Or if your compositor isn't just
laying out a 2D rectangle of windows (see
https://mohskitchen.wordpress.com/2012/09/19/wolfenstein-3d-compositor-for-wayland/)

The need for this feature seems somewhat overstated to me - a lot of
things already work just fine, nobody has presented an unfixable case,
or even a case for which the fix is a terrible hack.

FWIW, EFL doesn't need global positioning at all - applications don't
render pop-ups outside their canvas...

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

This isn't fair - are we also expected to implement the whole X API as
part of wayland?

Wayland's never had this feature, so it's not reasonable to expect it to
"continue" to exist for a grace period.

We've disregarded a lot of X precedent intentionally.  Adding any of it
back when it's against stated design goals will simply give developers
reason to expect it to remain there.

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

Developers abusing and exploiting protocol is really just going to
increase the throughput on their bug trackers when the bad things they
did break.

"Someone is going to do something bad" should never be an argument for
not trying to do something right.

> All in all, I think that having a dedicated "compatibility to X11
> legacy" extension is useful, this extension can be deprecated and

XWayland is exactly this.  People can continue to run X11 applications
under wayland compositors with it, and this lets us avoid trying to
recreate all the idiosyncrasies of X11 in Wayland.

> 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

The vast majority of application developers will be using toolkits that
hide all of this from them.

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

This part we agree on ;)

Derek

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