disabling SDL_HINT_VIDEO_WAYLAND_ALLOW_LIBDECOR breaks about sdl HOT 17 CLOSED

On Weston and Gnome based desktops, you need libdecor if you want SDL to provide window decorations. Otherwise, you need to handle the decorations and/or set the drag/resize hotspots yourself.

from sdl.

I guess in this case that hint is not
properly documented. Why does it
exist?

from sdl.

A variable controlling whether the libdecor Wayland backend is allowed to be used.

What exactly is incorrect about the documentaiton? If you set it to zero, SDL won't load or use libdecor, and you won't get default window decorations on platforms that don't support the decoration protocol.

It's useful when working on SDL in order to quickly switch between the libdecor and xdg-shell paths for testing, but otherwise there is little reason for a random app/game to toggle this.

from sdl.

https://wiki.libsdl.org/SDL2/SDL_HINT_VIDEO_WAYLAND_ALLOW_LIBDECOR
It doesn't say "If you set it to zero, SDL won't load or use libdecor, and you won't get default window decorations on platforms that don't support the decoration protocol.".

The problem initially comes from here:
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7246#note_2153375
Instead of fixing the trivial bug, they are
telling me to stop using libdecor.
I suspected this isn't possible, but found
that sdl hint.

from sdl.

It's generally assumed that if someone is changing this, they know what it is and what it does, and have a good reason for doing so.

SDL uses libdecor, but it has no control over the internals or how the GTK plugin works. What you could do is rename the GTK plugin .so file, so it uses the Cairo plugin instead. The decorations won't look native, but it won't use GTK, which may solve your problem.

from sdl.

And it does!
Thank you.

Would it be possible to add some
SDL hint for that then?

from sdl.

SDL uses libdecor, but it has no control over the internals or how the GTK plugin works.

And no any variable in libdecor for that?

from sdl.

There is no hint SDL could add for this as there is no programmatic way to handle this. Libdecor might be open to something like a LIBDECOR_FORCE_PLUGIN envvar to force a specific plugin, though.

from sdl.

Anyway, closing since this is solved.

from sdl.

Well, its "solved" by files renaming in
a system-wide dir... I won't say this is a
solution, its just a demonstration that
the solution is possible.
But its not there,

from sdl.

What you want needs to be implemented in libdecor. SDL can’t do anything to override the plugin it uses.

from sdl.

Actually, maybe its a crazy idea, but
AFAIK most rendering contexts consist
just of a single FD. I.e. the wayland
connection FD, Xorg connection FD
and so on.
Would it be possible for SDL to "reveal"
that FD to the user, so that he can pass
it to another process, and feed it back
to SDL there?
It seems like that could solve my problem.
I have already an RPC server that passes
the FDs to the less-priv'd process, so why
not to treat the wayland fd the same way?
What do you think?

from sdl.

SDL3 already supports importing/exporting a Wayland display with SDL_PROP_GLOBAL_VIDEO_WAYLAND_WL_DISPLAY_POINTER to allow the mixing of toolkits, although that gives the raw wl_display pointer instead of the fd. If the underlying fd is needed to be passed around more easily, it could be easily be changed to accommodate that.

from sdl.

But pointer probably can't cross the
process boundaries? In that case, of
course, I vote for this being an FD. :)
Or whatever else IPC-passable.

from sdl.

Also I wonder how feasible is to get
an API that only opens a wayland/xorg/whatever
FD and passes it to user. Rather than
actually doing any initialization. All
the initialization should later be done
on top of that FD in an another process.

from sdl.

Ah, the fd obtained from wl_display_get_fd() is for the underlying socket connection, and ownership is taken when using it with wl_display_connect_to_fd(), so it can't be used for sharing a wl_display context, even from within the same process.

This won't work.

from sdl.

Ok, no need for an FD then. :)
The doc says:

Once the window has been successfully created, the wl_display and wl_surface objects can then be retrieved from the
SDL_PROP_WINDOW_WAYLAND_DISPLAY_POINTER and SDL_PROP_WINDOW_WAYLAND_SURFACE_POINTER properties
respectively.

Is it possible to use shared memory
to pass all the needed structures to
another process, so that it can deal
with that window (and SDL in general)?

from sdl.