Gtk4 and Wayland

[Kevin Rushforth]

I don't want to give up on the functionality of being able to move a 
window or control the stacking order for those platforms that can 
support it. So when running on an X11 server, which a gtk4 pipeline 
ought to be able to do, I think we need to continue to allow 
applications to move windows or change the stacking order. On a pure 
Wayland server, this might not be possible.

One thing I will note is that the setting of a window's position (or 
size or stacking order) isn't just under the control of the application. 
The window system can move windows around (e.g., in response to a user 
dragging the window or as an operation of a tiled window manager), or it 
can override or ignore the attempt to set the position.

This isn't described very well in the spec, so I will file a bug to 
clarify the spec to match this intention.

On a related topic, the window decoration has moved into the client 
code, so we may need to give some thought to that as well in order to 
implement decorated windows on Wayland.

-- Kevin


On 9/14/2021 8:18 AM, Thiago Milczarek Sayão wrote:
> Hi,
>
> It seems it would be very hard to have gtk4 and/or Wayland on JavaFX,
> unless we stop doing window manager related things.
> Resizing the window would be possible, but not stacking or moving it around.
>
> Wayland simply does not have this functionality and gtk4 removed it as
> well, as pointed out here
>
> https://gnome.pages.gitlab.gnome.org/gtk/gtk4/migrating-3to4.html#adapt-to-gdkwindow-api-changes
>
> and here:
>
> https://discourse.gnome.org/t/gtk4-migration-window-management-functions-gone/7542/4
>
> Even on gtk3 it's a hard thing to do (deal with stacking and positioning).
>
> So I agree with the Gtk developers position to simply not deal with window
> management at this level, but it's somehow unfortunate.
>
> On the "experimenting with gtk4" side, it seems like I hit a dead end
> because gtk4 does not provide the needed functionality nor Wayland (to deal
> with it directly).
>
> Sticking with X11 also seems like not optimal for the long term, it will be
> replaced eventually.
>
> Maybe JavaFX should move away from window management as well?
>
> -- Thiago.
>
>
>
> Em qua., 1 de set. de 2021 às 08:42, Kevin Rushforth <
> kevin.rushforth at oracle.com> escreveu:
>
>> This seems reasonable to me as well, at least for JavaFX since we
>> already rely on Gtk for most of the windowing toolkit on Linux.
>>
>> -- Kevin
>>
>> On 9/1/2021 4:26 AM, Mario Torre wrote:
>>> On Wed, Sep 1, 2021 at 1:18 PM Johan Vos <johan.vos at gluonhq.com> wrote:
>>>> Hi Thiago,
>>>>
>>>> I was thinking (and experimenting) in the same direction, and so far
>> that
>>>> is working good. I don't see disadvantages, but it would be good to find
>>>> out about it before we move forward.
>>>> Maybe the main issue to me is that GTK comes with lots of dependencies.
>> We
>>>> already have that situation today, so it is not going to be worse. But
>> if
>>>> we would use the Wayland protocol on a lower level (with a
>> Wayland-specific
>>>> glass platform, instead of GTK), we could probably reduce the
>> dependencies.
>>>> However, this comes at the price of creating *and maintaining* more
>>>> low-level code.
>>>>
>>>> I've been running GTK3 on Wayland and that works fine too. However, it
>>>> might be better to focus Wayland support for GTK4. I think there won't
>> be
>>>> many installs that have no X11, but only Wayland, and that have GTK3
>> and no
>>>> GTK4.
>>> I tend to agree with you, I think we should consider this for Wakefield
>> too.
>>> Cheers,
>>> Mario
>>>
>>>> - Johan
>>>> - Johan
>>>>
>>>> On Tue, Aug 31, 2021 at 11:03 PM Thiago Milczarek Sayão <
>>>> thiago.sayao at gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I did some investigation on gtk4 and wayland.
>>>>>
>>>>> After some research I ended up with the conclusion that the best way
>> is to
>>>>> do a separate gtk4 backend, that would support X11 and Wayland.
>>>>>
>>>>> This would be a good start:
>>>>> https://github.com/openjdk/jfx/pull/77/files
>>>>>
>>>>> Why?
>>>>>
>>>>> Gtk4 moves the decoration to the client side, which is GREAT since
>> knowing
>>>>> the window size with decoration was a real pain.
>>>>>
>>>>> We probably won't want to do all the decoration work, Gtk does that,
>> but on
>>>>> GtkWindow level, not GdkSurface (which replaces GdkWindow).
>>>>>
>>>>> Thus the move to use "more Gtk" (hence "less Gdk") which is exactly
>> what
>>>>> the PR does. It also removes Applet code
>>>>>
>>>>> This is also a good starting point:
>>>>> https://gnome.pages.gitlab.gnome.org/gtk/gtk4/migrating-3to4.html
>>>>>
>>>>> --Thiago.
>>>>>
>>