wayland: Add experimental pantheon-desktop-shell protocol

[tintou]

This is quite hacky but this open the way to using the pantheon-desktop-shell protocol.

[tintou]

Opened https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3092 to be able to remove the horrible hack with next Mutter version 🤞

[tintou]

We now require this to be merged https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3298 I'll try to add it in 45.1

[tintou]

With the above MR merged and applied, the protocol should now work 🙂

One should just implement the details where there is a TODO in set_anchor. We have access to the Meta.Window so it shouldn't be that complicated…

[tintou]

Here is a patched mutter for jammy if someone want to experiment https://code.launchpad.net/~elementary-os/+archive/ubuntu/staging/+build/26741251 otherwise we will have it working OOTB in mutter 45.1 (note that it will soft-fail so it doesn't need to be rebuilt against the patched mutter)

[tintou]

I have 3 main interfaces available here:

• io_elementary_pantheon_panel_v1 to signal that the surface is a shell panel (Wingpanel or Plank would qualify)
• io_elementary_pantheon_widget_v1 to signal that the surface is a shell "widget" (to stick on the background or being moved to a widget virtual desktop ?)
• io_elementary_pantheon_extended_behavior_v1 mostly to reimplement the "stick" behavior of the Screenshot utility but might be enhanced when we encounter other needs

[danirabbit]

I'm not sure if it's relevant here but it would be nice to have some kind of shell-modal hint like for example the shut down dialog or Polkit dialogs which would be always on top, "sticky", and ideally we could do something like dim and/or blur the desktop behind them. And I think also these dialogs probably should be always centered and shouldn't be able to be moved maybe

[Marukesu]

Before we set in anything here, i think, we should try to implement the client-side part to known what is possible to do, given limitations in the Gtk side.

I have 3 main interfaces available here:

• io_elementary_pantheon_panel_v1 to signal that the surface is a shell panel (Wingpanel or Plank would qualify)
• io_elementary_pantheon_widget_v1 to signal that the surface is a shell "widget" (to stick on the background or being moved to a widget virtual desktop ?)
• io_elementary_pantheon_extended_behavior_v1 mostly to reimplement the "stick" behavior of the Screenshot utility but might be enhanced when we encounter other needs

is there any other use case than the screenshot app for the extended_behavior surface? when we make the screenshot app a portal, the stick behaviour will be lost anyway.

Also, i think we still need a "bubble" interface for the notifications bubbles.

I'm not sure if it's relevant here but it would be nice to have some kind of shell-modal hint like for example the shut down dialog or Polkit dialogs which would be always on top, "sticky", and ideally we could do something like dim and/or blur the desktop behind them. And I think also these dialogs probably should be always centered and shouldn't be able to be moved maybe

Maybe we could do some fancy interpretation of the proposed xdg_dialog interface upstream? like, a non-parented xdg_toplevel with a xdg_dialog surface represents a system dialog. I don't think there's something in their documentation that won't allow this behaviour.

[leolost2605]

Maybe I understood the set_anchor description wrong but I think we might want to separate the anchor from a kind of exclusive zone. For example for an autohiding dock that wants to overlay instead of push away windows that would be useful ¯\_(ツ)_/¯
AFAIK layer shell does the same

[tintou]

I think that the notification bubbles should be shipped with Gala and should be using Meta.WaylandClient and be placed by Gala.
It should be the same for the Desktop menu.

I can see the allways-on-top behavior be used by the Shutdown menu and the Welcome screen.

[tintou]

Maybe I understood the set_anchor description wrong but I think we might want to separate the anchor from a kind of exclusive zone. For example for an autohiding dock that wants to overlay instead of push away windows that would be useful ¯_(ツ)_/¯ AFAIK layer shell does the same

Yeah I'm open to any other wording, here is how the KDE protocol is doing this https://wayland.app/protocols/kde-plasma-shell#org_kde_plasma_surface:request:set_panel_behavior

[tintou]

Here is the implementation for the stays-on-top behavior in Screenshot elementary/screenshot#275

[leolost2605]

This currently doesn't seem to work on OS 8?

• It doesn't show up in Waycheck
• Using the screenshot PR the registry_handle_global is triggered often but never with our interface

Btw the reason for the build failing is the documentation. It complains about Pantheon and Desktop symbols not being found but adding '--vapidir=' + meson.global_source_root () / 'protocol' doesn't fix it for me. Any ideas here?

[Conan-Kudo]

Why not use layer-shell for this?

[tintou]

Good point for layer-shell, we might still need a custom protocol for the "sticky" behavior

[Conan-Kudo]

In KDE, we moved away from a custom protocol to wlr-layer-shell, and that has been reasonably good to us.

[Marukesu]

Why not use layer-shell for this?

IIRC, we can't use layer-shell because of gtk4 not supporting custom surfaces. So we need protocols that enhances a xdg_toplevel surface instead so we can keep moving alway from gtk3.

[Conan-Kudo]

Isn't that what a GdkSurface is? Or am I missing something?

[Conan-Kudo]

Ah, there's a layer-shell library for GTK 4 written by @wmww: https://github.com/wmww/gtk4-layer-shell

[Marukesu]

Ah, there's a layer-shell library for GTK 4 written by @wmww: https://github.com/wmww/gtk4-layer-shell

Interesting, though requiring LD_PRELOAD doesn't look good.

Isn't that what a GdkSurface is? Or am I missing something?

GdkSurface aren't supposed to be derivable outside of Gtk, GtkRoot and GtkNative also cannot be implemented outside of Gtk.

Think a little more, i also think mutter doesn't expose enough that allow us to implement a layer_surface externally too (I don't think we can emit the configure and closed events when required, neither implement the get_popup and set_keyboard_interactivity requests).

We would need to have a way to integrate the protocol with mutter internal handling of surfaces.

[tintou]

It is possible to use it with GTK4 directly as I did here, we have access to the wl_surface https://github.com/elementary/screenshot/pull/275/files#diff-1379e6216d75e1e621858978bb52674e30fa2d0e9025920154fe5404af973bf9R262

[leolost2605]

It seems it's failing on OS 8, mutter 45.3 with

(gala:12090): libmutter-WARNING **: 20:09:09.921: WL: wl_global_create: failing to create interface '\u0019' with version -1467596736 because it is less than 1

Once again I might be doing something horribly wrong if so just minimize this comment :)

[wmww]

Interesting, though requiring LD_PRELOAD doesn't look good.

gtk4-layer-shell does not require LD_PRELOAD as long as the libraries are linked in the correct order. See https://github.com/wmww/gtk4-layer-shell/blob/main/linking.md for details.

[leolost2605]

I'll do some more testing just writing here if someone has ideas but maybe I'm also completely wrong :)

Looking at the c code this line seems to be the problem:

	_tmp7_ = wl_global_create (NULL, _tmp6_, &io_elementary_pantheon_shell_v1_interface, 1, ___lambda193__wl_global_bind_func_t);

where _tmp6_ is the wl_display

This is the definition of wl_global_create

struct wl_global *
wl_global_create(struct wl_display *display,
		 const struct wl_interface *interface,
		 int version,
		 void *data, wl_global_bind_func_t bind);

IIUC above line should actually be

	_tmp7_ = wl_global_create (_tmp6_, &io_elementary_pantheon_shell_v1_interface, 1, NULL, ___lambda193__wl_global_bind_func_t);

So I guess that might be a VAPI problem?

[leolost2605]

Ok I can confirm that by editing the c file and changing the line to the new line it does actually work. However I tried a few things by editing the VAPI and just couldn't figure out how to prevent vala from passing this first NULL. I guess it tries to do some instance stuff but it's static so..? Also I'm really not to familiar with the insides of vala so I might be missing something obvious 😅

See #1871

[tintou]

@leolost2605 I've updated the .vapi so it should now work 🙂

[leolost2605]

It does indeed show up now (🥳) but it currently doesn't work with the screenshot implementation so I can't really test whether this works :(
In the screenshot PR it seems that the resource creation of the shell interface works well but the surface from self.get_surface () is still null.
I tried to delay it with a few very uneducated guesses but these all ended in WL: error communicating with client in gala and a crash in screenshot 🤷

[tintou]

@leolost2605 based on your findings, I've updated the .vapi as wl_resource_create doesn't in fact return a reference to Wl.Resource as it is owned by the Wl.Client

[leolost2605]

Thank you that's much cleaner and works! Only minor nitpick, apart from that do you want to merge this and then finish API or do you want to get it done here? (Not implementation only specification I mean)

[tintou]

Yes let's merge this and implement it afterwards to unblock this 🙂

[leolost2605]

@tintou could I get your opinion on #1906? If that looks somewhat alright to you we could just merge that since it includes this with the latest fix already and is prepared for a rebase merge. If not I'll happily approve this :)