Call for Discussion : New Project to support the Wayland display server on Linux

[Robert Marcano]

On 7/16/21 3:49 PM, Philip Race wrote:
> I have heard this but we'll see how it plays out in practice.
> X11 already allows a window manager to not place the window exactly 
> where you asked for it, or
> ignore other requests to do with window geometry.
> 
> However in practice you usually get something very close to what you 
> requested.
> It can be written like that to provide for some situations in which the 
> desktop has no way to exactly honour the client's request
> without it being a complete unpredictable mess.
> I'm sceptical that anyone will be happy with a desktop that when you ask 
> it to show that file manager dialog
> in the middle of the screen instead decides the bottom right hand corner 
> of your screen is where it will show it today
> and tomorrow top-left .. so a spec. allowing something isn't the same as 
> it always happening.
> 
> 
> And the AWT spec. already allows for this :
> ========
> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/Window.html 
> 
> 
> Note: the location and size of top-level windows (including Windows, 
> Frames, and Dialogs) are
> under the control of the desktop's window management system. Calls to 
> setLocation, setSize, and setBounds
> are requests (not directives) which are forwarded to the window 
> management system.
> Every effort will be made to honor such requests. However, in some cases 
> the window management
> system may ignore such requests, or modify the requested geometry in 
> order to place and size the
> Window in a way that more closely matches the desktop settings
> 
> =======
> 
> If anything about wayland *requires* a spec. update that would be a 
> problem as it would make it more
> onerous to backport to older JDKs if it is needed.
> 
> -phil.

True, the Java API spec. allow for the Windows manager for not being 
able to set exact positions, but Wayland doesn't even have a way to get 
the current position and I am not sure about how 
ComponentListener.componentMoved() will behave in that situation.

IIRC XWayland was initialy unable to set windows position so a private 
"protocol" between Wayland and XWayland was estabilished because it was 
noticed too many legacy applications were having problems. In real world 
so many people coded their applications expecting setting windows 
positions request were respected even if the spec. say it wasn't guaranteed.

> 
> On 7/16/21 6:18 AM, Robert Marcano wrote:
>> On 7/7/21 9:24 AM, Philip Race wrote:
>>>
>>>>
>>> There are some unknowns and questions, such as what are the options 
>>> for supporting Robot ?
>>> What other support is missing ? What platform APIs should the 
>>> implementation  use ?
>>> How does a native Wayland solution interoperate with OpenJFX ?
>>
>> Among the APIs in consideration are all related to window positioning. 
>> Wayland doesn't allow clients to tell the window position, the reason 
>> is that Wayland compositors aren't expected to be always traditional 
>> desktops, for example a tiling window manager.
>>
>> There were a proposal to add a cookie like extension to allow 
>> applications to say Wayland to store the current position and the then 
>> be able to restore it later, but I don't think that progressed too much.
>>
>>>
>>>
>>> Comments, expressions of interest etc are welcome.
>>>
>>>
>>> -Phil Race, for the Java client groups.
>>>
>>>
>>> [1] : https://wayland.freedesktop.org/
>>> [2] : 
>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/Robot.html 
>>>
>>
>