Add gtk_layer_set_exclusive_edge

[darkwater]

Fixes #183. I'm not a C++ programmer by any means, but this seemed simple enough, so I took a stab at it. This works for my application, at least.

By opening this pull request, I agree for my modifications to be licensed under whatever licenses are indicated at the start of the files I modified

[wmww]

Sorry this took some time for me to notice. I'll take a look at it when I get a chance. Thanks!

[alebastr]

Here and in layer_surface_set_exclusive_edge you should check if the compositor supports the necessary protocol version. Something like

uint32_t version = zwlr_layer_surface_v1_get_version (self->layer_surface);
if (version >= ZWLR_LAYER_SURFACE_V1_SET_EXCLUSIVE_EDGE_SINCE_VERSION) {
    zwlr_layer_surface_v1_set_exclusive_edge (self->layer_surface, self->exclusive_edge);
}

similar to the layer_surface_set_layer.

Now, I'm not sure what's the right fallback behavior for layer_surface_set_exclusive_edge. Probably anchoring to 3 edges and tweaking GTK surface size/alignment to start drawing from the requested edge.
Returning an error and leaving fallback behavior to the user could work as well.

[darkwater]

The library seems to be quite close to how the Wayland protocol looks, so returning an error sounds more consistent with the feel of the library.

That said, there is gtk_layer_auto_exclusive_zone_enable which is not present in the protocol and is handled by the library.

An automatic fallback would mean:

• For 4 edges, fall back to 3 edges and set the window size to make it appear fullscreen
• For 2 edges, like you said, 3 edges and manipulate the drawing area
• There are probably some edge cases like 0 edges and 2 opposing edges
• Exclusive edge set to one that isn't anchored to? Is that allowed?

[darkwater]

I just added a warning to layer_surface_set_exclusive_edge.

[wmww]

Is this an important feature for a particular existing app or usecase? I've decided to put this project in maintenance mode now (see top of readme), as I don't have much time to work on it. I'd be more inclined to accept such a patch into the GTK4 version.

[darkwater]

I'm using this for Flutter, which is still using GTK3. I've seen some prep work for a GTK4 transition, but it doesn't look like it's happening anytime soon. This update to v5 of the protocol would be great as it's otherwise impossible to have an exclusive zone with two or four anchors. (Since Flutter lacks multiwindow support, the only way to have popups for a bar is to make the bar fullscreen and use input regions)

[wmww]

Good lord that's awful.

Maybe make a 2nd GTK layer window to provide the exclusive zone? It can have zero width-height and so doesn't need to be rendered to by flutter.

[darkwater]

That could work, but would be messy eg. when a user is configuring rules for layers, and a bar shows up twice.

Is there anything in particular preventing merging? Looks ilke the tests have been fixed since so I can try adding a test for this.

Edit: I see I also didn't add a get_exclusive_edge

[wmww]

There's a number of issues, most notably that the API takes an int and doesn't seem to handle conversions to zwlr_layer_surface_v1_anchor anchor at all. This is irrelevant however, as this PR is unfortunately not going to be merged.

This protocol version doesn't have great compositor support yet (see https://wayland.app/protocols/wlr-layer-shell-unstable-v1#compositor-support), so apps that use it will break on different desktops. Creating a 2nd window, while a little clunky, is a reasonably simple workaround for this edge case that will work across compositors.

When there's better compositor support it might make sense to add this to the GTK4 library, but probably not here. Sorry.