search

wmww / gtk-layer-shell

A library to create panels and other desktop components for Wayland using the Layer Shell protocol
GNU General Public License v3.0
324 stars 16 forks source link

Adaptation for additional Wayland surfaces #176

Closed Cu3PO42 closed 8 months ago

Cu3PO42 commented 8 months ago

Hi! Let me start by thanking you for the wonderful work you've done as part of gtk-layer-shell.

I'm interested in enabling GTK-based session lockers using the ext-session-lock-v1 protocol. I'm not yet too deep into the internals, but it is my understanding that this presents fundamentally the same problem as using wlr-layer-shell. Namely attaching GDK's wl_surface to the lock surface rather than the XDG shell.

It is my understanding that I could create a new subclass of CustomShellSurface in a fashion similar to layer-surface. My understanding of the trickery around popups, but it presumably doesn't apply here since, in the case of ext-session-lock, one surface is all you get per output.

Then the public API could be amended for these new surfaces. Is this something you'd consider out-of-scope for the project or might you consider having that upstream? This seems drastic enough to warrant a fork in my eyes.

While I'm currently more interested in GTK 3, I'd like to eventually do the same work for GTK 4. While having gtk-layer-shell plus gtk-session-lock (or whatever it might end up being called) would not be a problem according to my understanding, the same would not be true in the GTK 4 case. Having two conflicting shims would be problematig. I suppose a hypothetical gtk4-session-lock could dlopen gtk4-layer-shell and forward calls to its shim, but that seems like asking for trouble.

I'd appreciate any input. Thank you for your time!

wmww commented 8 months ago

Because GTK3 (unlike GTK4) has gdk_wayland_window_set_use_custom_surface() and you don't need popups, I think you should be able to do this without too much weirdness. You'd still have to make a registry, find the global you want, make the right wayland calls, etc, but no hacking of GTK required.

On the other hand, gdk_wayland_window_set_use_custom_surface() never worked all that well. You may run into some problem (for example related to the order things are committed inside GTK, or how windows are resized) that is impossible to resolve without GTK fuckery. It's been too long since I worked on this stuff to say, and this protocol is different anyway.

I do consider supporting any other protocols out-of-scope for this library as well as the GTK4 one. this library is in maintenance mode, and almost certainly not going to have any major changes ever.

You're right that using two libraries like gtk4-layer-shell in the same process is problematic. If you need GTK4 support or public GTK APIs aren't good enough, I think the thing to do is abstract the non-layer shell specific parts of gtk4-layer-shell into a library, and make gtk4-layer-shell a user of that library. I considered doing this from the beginning.

Note that the gtk4-layer-shell shim approach can in principle work on GTK3. the only reason this library doesn't use it is because I came up with it long after this one was completed, and I didn't want to make changes that might break existing users. I would advise any new libraries that can't be implemented on public GTK APIs to use the shim approach from the start, because it's simpler and more portable to GTK4.

Cu3PO42 commented 8 months ago

I appreciate your reply. I have the necessary code mostly written and I'm mildly optimistic that a straight-forward approach does work.

For now I'll probably just stick with a fork with my changes, but when (and if) I feel motivated to clean everything up and etxract the shim into its own library, I may submit a PR to gtk4-layer-shell.

Thanks again for your time and work!