Bug 359531

xdg_shell is not yet a standardized protocol with API compatibility guarantees. This makes it almost impossible to wrap it in an ABI stable library as KWayland is.

Even if we added support for it, it is unlikely that this would solve the problem of gtk applications crashing. Due to the unstable xdg_shell one needs to have exactly the same version of the unstable protocol to have it working. As GTK+, Wayland, Qt and KWin releases are not synced it becomes unlikely that all of them have the same magic version. KWin would probably follow the version used in the QtWayland release of the Qt build dep. That's about 1 year behind what Wayland has and thus most likely also behind what GTK+ has. Given that it would still not work.

Overall that's the reason why I so far refused to spend time on adding support for xdg_shell. I simply don't see how it would fix anything of this compatibility issue. I have it on my todo list, but it will be hidden behind an explicit compile time flag. This is the only way how we can solve the API instability problem in our stable KWayland library.

Obviously the problem here is that gtk hard depends on an unreleased, not standardized interface. It should check whether it exists and if not either exit (heck one could also use X11, no need to crash just because there's a Wayland socket) or fall back to wl_shell as Qt does.

I'm setting to INVALID as the bug in question is in GTK and not in KWin. Support for xdg_shell will be added eventually but I do not see the lack of support for an unstable interface as a bug in KWin.

(In reply to Martin Gräßlin from comment #1)
> xdg_shell is not yet a standardized protocol with API compatibility
> guarantees. This makes it almost impossible to wrap it in an ABI stable
> library as KWayland is.
> 
> Even if we added support for it, it is unlikely that this would solve the
> problem of gtk applications crashing. Due to the unstable xdg_shell one
> needs to have exactly the same version of the unstable protocol to have it
> working. As GTK+, Wayland, Qt and KWin releases are not synced it becomes
> unlikely that all of them have the same magic version. KWin would probably
> follow the version used in the QtWayland release of the Qt build dep. That's
> about 1 year behind what Wayland has and thus most likely also behind what
> GTK+ has. Given that it would still not work.
> 
> Overall that's the reason why I so far refused to spend time on adding
> support for xdg_shell. I simply don't see how it would fix anything of this
> compatibility issue. I have it on my todo list, but it will be hidden behind
> an explicit compile time flag. This is the only way how we can solve the API
> instability problem in our stable KWayland library.
> 
> Obviously the problem here is that gtk hard depends on an unreleased, not
> standardized interface. It should check whether it exists and if not either
> exit (heck one could also use X11, no need to crash just because there's a
> Wayland socket) or fall back to wl_shell as Qt does.
> 
> I'm setting to INVALID as the bug in question is in GTK and not in KWin.
> Support for xdg_shell will be added eventually but I do not see the lack of
> support for an unstable interface as a bug in KWin.

I agree that this bug should be marked as invalid since this is about actually about a gtk+ bug. And FWIW, last time I tested gtk+ would fail gracefully and fallback on X11, so this seems to be a regression.

That being said, it would be appreciated if kwin would support xdg_shell (or at least the next version xdg_shell that is in the making that fixes various issues with the current version) as an experimental feature at least. Not only to make future gtk+ clients testable but also to improve the cross-desktop-ness of xdg_shell, given that we receive feedback. The option we have is to declare some future version stable without there being a kwin implementation, and we would either need to live with that version (as a base) or stay incompatible indefinitely.

If you create a bug tracking that progress, please CC me so I can stay updated.

(In reply to Jonas Ådahl from comment #2)
> That being said, it would be appreciated if kwin would support xdg_shell (or
> at least the next version xdg_shell that is in the making that fixes various
> issues with the current version) as an experimental feature at least.

I hope to find time for it, but I cannot promise anything. The unstable aspect makes it really hard to implement support for it. As soon as we export it, QtWayland would use it and break as we would have a newer version than Qt. This makes it just a terrible hassle to work with it as it means my desktop breaks.

Similar I would not even be able to test GTK applications with it as I use distro packages of GTK.

> Not
> only to make future gtk+ clients testable but also to improve the
> cross-desktop-ness of xdg_shell, given that we receive feedback.

well I can have a look at the latest draft and provide feedback on it. I think I did so in the past already ;-)

> The option
> we have is to declare some future version stable without there being a kwin
> implementation, and we would either need to live with that version (as a
> base) or stay incompatible indefinitely.
> 
> If you create a bug tracking that progress, please CC me so I can stay
> updated.

Sorry we don't use bugs to track progress, but I have a task on todo.kde.org: https://todo.kde.org/?controller=task&action=show&task_id=1612

(In reply to Martin Gräßlin from comment #3)
> (In reply to Jonas Ådahl from comment #2)
> > That being said, it would be appreciated if kwin would support xdg_shell (or
> > at least the next version xdg_shell that is in the making that fixes various
> > issues with the current version) as an experimental feature at least.
> 
> I hope to find time for it, but I cannot promise anything. The unstable
> aspect makes it really hard to implement support for it. As soon as we
> export it, QtWayland would use it and break as we would have a newer version
> than Qt. This makes it just a terrible hassle to work with it as it means my
> desktop breaks.

Yes, this is the reason I would like it to be declared stable not to far into the future. I think v6 might be a candidate for this, but exactly how it'll look is undecided. You should be able to find a couple of patches on the mailing list with that changes the interface object tree structure and adding a non-grabbing popup. One part that is not on the list is a popup positioning system enabling declarative menu positioning, but it'll be sent to the list quite soon.

So far the v6 has only one semantical change merged so far, please see the current wip branch:
https://cgit.freedesktop.org/wayland/wayland-protocols/log/?h=wip%2Fxdg-shell-unstable-v6

> 
> Similar I would not even be able to test GTK applications with it as I use
> distro packages of GTK.
> 
> > Not
> > only to make future gtk+ clients testable but also to improve the
> > cross-desktop-ness of xdg_shell, given that we receive feedback.
> 
> well I can have a look at the latest draft and provide feedback on it. I
> think I did so in the past already ;-)
> 
> > The option
> > we have is to declare some future version stable without there being a kwin
> > implementation, and we would either need to live with that version (as a
> > base) or stay incompatible indefinitely.
> > 
> > If you create a bug tracking that progress, please CC me so I can stay
> > updated.
> 
> Sorry we don't use bugs to track progress, but I have a task on
> todo.kde.org: https://todo.kde.org/?controller=task&action=show&task_id=1612

That link was password protected.

(In reply to Jonas Ådahl from comment #4)
> > Sorry we don't use bugs to track progress, but I have a task on
> > todo.kde.org: https://todo.kde.org/?controller=task&action=show&task_id=1612
> 
> That link was password protected.

meh sorry. It's also available to public under https://todo.kde.org/?controller=board&action=readonly&token=0ef6e11806f1410bf0a3ba50e2bbb22ccfaf2c0f2b52b1c1726f25c2ce3d

> Obviously the problem here is that gtk hard depends on an unreleased, not
> standardized interface. It should check whether it exists and if not either
> exit (heck one could also use X11, no need to crash just because there's a
> Wayland socket) or fall back to wl_shell as Qt does.

That's the core problem and Gtk+ people are fixing it. See https://bugzilla.gnome.org/show_bug.cgi?id=762258

Sorry for the noise.

(In reply to Christian Stadelmann from comment #6)
> > Obviously the problem here is that gtk hard depends on an unreleased, not
> > standardized interface. It should check whether it exists and if not either
> > exit (heck one could also use X11, no need to crash just because there's a
> > Wayland socket) or fall back to wl_shell as Qt does.
> 
> That's the core problem and Gtk+ people are fixing it. See
> https://bugzilla.gnome.org/show_bug.cgi?id=762258
> 
> Sorry for the noise.

Right now if i run something like gnome-calculator, it show me this:

~]$ gnome-calculator

(gnome-calculator:18775): Gdk-WARNING **: Wayland compositor does not support xdg_shell interface, not using Wayland display



so it runs on xwayland instead (this is the workaround done on the bug thread posted on the last reply). If I force wayland, it just doesnt start:

~]$ GDK_BACKEND=wayland gnome-calculator

(gnome-calculator:18792): Gdk-WARNING **: Wayland compositor does not support xdg_shell interface, not using Wayland display

(gnome-calculator:18792): Gtk-WARNING **: cannot open display: :1



So in other words, for what I read here, there is no ETA about when gtk3 programs will work natively on kwin-wayland. Hopefully xdg_shell will become a stable protocol soon, so it can be supported.

Gtk apps used to work. Then gtk switched to a newer version of xdg shell and dropped support for the older version. We haven't added support for the new version yet. Also the problem does not exist on all distributions. E.g. on neon gtk is old enough to still support the old version.

Please complain to gtk for breaking compatibility.