libsdl-org
DISCUSSION: how should "toolkit" functionality be handled from now on?
Basically, I have some questions that I would like to discuss with the rest of the SDL developers about X11TK and its sister for Wayland.
- Should we keep the "toolkits" coupled to the windowing system? Or should there be one "toolkit" as a subsystem that has its own video and font backends? This idea came to me when someone suggested making the Wayland version (which relies on SDL_Surfaces and either libfcft or built in bitmap fonts for text) into a generic one that can be used on many other drivers like the KMSDRM one. We cannot use the existing video subsystem because some features, like message boxes, don't require the video subsystem and can be used even when the video subsystem can not be initialized.
- Should all of this be separated into its own library that SDL will use? This will make menu bars more challenging, but this allows other libraries and projects to make use of our code cleanly.
Also, how should we handle more advanced scripts that require shaping like Devanagari for core fonts? They currently dont work properly, We could implement our own shaper for Devanagari, possibly using the code from HarfBuzz or old versions of Pango (https://gitlab.gnome.org/jralls/pango/-/blob/PANGO_1_1_0/modules/indic/devanagari-x.c?ref_type=tags) as a reference.
Also, some users are displeased (https://github.com/libsdl-org/SDL/issues/5330#issuecomment-3539194049) with core fonts being used on X11, we could implement support for SDL_ttf or libfcft and leave the core fonts as a fallback, this issue will be more easily solved once the backend seperation issue is solved.
@slouken, @Kontrabant @icculus
Can someone run down the use cases for this "toolkit"?
Right now we use zenity if available for X11 and Wayland, and I think this is reasonable at this point, since there isn't another way to get native feeling dialogs on the desktop.
Currently if zenity isn't available, we have an X11 fallback for message boxes, since those are critical, and we fail the other dialogs.
I don't think we want to implement a fully featured X11 toolkit, since we'll run into lots of code bloat and have to import text shapers, and won't match the style of KDE or GNOME, etc. I think the current approach of using zenity and falling back for message boxes is fine.
What am I missing?
Can someone run down the use cases for this "toolkit"?
Right now we use zenity if available for X11 and Wayland, and I think this is reasonable at this point, since there isn't another way to get native feeling dialogs on the desktop.
Currently if zenity isn't available, we have an X11 fallback for message boxes, since those are critical, and we fail the other dialogs.
I don't think we want to implement a fully featured X11 toolkit, since we'll run into lots of code bloat and have to import text shapers, and won't match the style of KDE or GNOME, etc. I think the current approach of using zenity and falling back for message boxes is fine.
What am I missing?
Basically we can use it in the following places: -Message boxes -File dialogs -Menu bars and right click menus for SDL_Windows -Tray fallback for desktops that dont use the Ayantana protocols (only applicable when the current libappindicator based implementation gets replaced with a pure DBus one, since libappindicator handles the fallbacks for us. This is heavily tied to the aforementioned menu functionality.) -A overlay keyboard implementation that does not rely on Steam.
As for the code bloat problem, I am in favor of splitting the code into its own library and linking to it, this will make functions that tie deeper into SDL like menus more challenging, but this will reduce bloat.
I think integration with GNOME/MATE/XFCE is a tricky problem, since GTK has multiple flaws that prevent it from being used in SDL directly, one possible solution is to use fork() and run all of the GTK code out of process, avoiding the symbol conflicts and GLib state corruption issues, this would allow us to use multiple GTK versions too. How would menu bars and such be handled in GTK though? GtkPlug/GtkSocket for X11 and XDG foreign for Wayland? Not all compositors support XDG foreign though...
I cant say much about integration with KDE/Qt because I have not used it for years.
Just some random thoughts from me:
- Having to dip down into X11 for any functionality beyond basic window management sucks, so anything that makes this suck less is likely worthwhile.
- We absolutely don't want to build a toolkit to compete with GTK+, etc...I understand that's not the goal here, but it can very very quickly start getting out of control.
Finding the sweet spot between these two points is the entire challenge here.
It's not only "let's not recreate GTK+" but also "let's not recreate all of GTK+'s dependencies," which we're at risk of doing when we hit issues like #14400. For something like message boxes, launching a separate process that has all that stuff is super-attractive because it will look like the user's native desktop UI, it'll handle things like shapers and right-to-left languages, and it will all vaporize out of memory when the user clicks a button.
Also, if we aren't already there yet, it isn't going to be long before someone realizes that macOS is popping up file picker dialogs in a separate process now for sandboxing purposes, and future Linux systems could expect us to make a D-Bus call to do the same...and when that happens, we're going to get native UI with all the Gnome/KDE features in a separate process by default.
As for splitting this out into a separate library: we don't want to do that, in any circumstance, I think.
Just some random thoughts from me:
- Having to dip down into X11 for any functionality beyond basic window management sucks, so anything that makes this suck less is likely worthwhile.
- We absolutely don't want to build a toolkit to compete with GTK+, etc...I understand that's not the goal here, but it can very very quickly start getting out of control.
Finding the sweet spot between these two points is the entire challenge here.
It's not only "let's not recreate GTK+" but also "let's not recreate all of GTK+'s dependencies," which we're at risk of doing when we hit issues like #14400. For something like message boxes, launching a separate process that has all that stuff is super-attractive because it will look like the user's native desktop UI, it'll handle things like shapers and right-to-left languages, and it will all vaporize out of memory when the user clicks a button.
Also, if we aren't already there yet, it isn't going to be long before someone realizes that macOS is popping up file picker dialogs in a separate process now for sandboxing purposes, and future Linux systems could expect us to make a D-Bus call to do the same...and when that happens, we're going to get native UI with all the Gnome/KDE features in a separate process by default.
As for splitting this out into a separate library: we don't want to do that, in any circumstance, I think.
What do you think about menu bars, "native" menu bars (using XEmbed or XDG foreign to embed GTK/Qt menu bars, with the GTK code running out of process with fork() due to the mentioned issues), global menu bars (basically support for the GIO menu/Canonical's DBusMenu protocols, this is heavily tied in to the "tray menus without libayantana" issue, since the SNI protocol relies on those) and the whole "multiple toolkits tied to video drivers or one generic toolkit with mini-drivers?" debacles?
macOS is popping up file picker dialogs in a separate process now for sandboxing purposes, and future Linux systems could expect us to make a D-Bus call to do the same
For apps running in a Flatpak sandbox (probably Snap sandboxes as well), that future is already here: the file chooser portal is exactly this.
Does that only work in sandboxes, or can normal apps use that? It would be nice to have a good guarantee of looking like the rest of the user's desktop UI and having whatever features Gnome/KDE offer in these interfaces (thumbnails, file completion, etc) without having to spawn a child process directly.
I believe the file chooser portal is meant to work anywhere, even for non-sandboxed apps: please report to https://github.com/flatpak/xdg-desktop-portal/issues if it doesn't. It needs a working D-Bus session bus, xdg-desktop-portal, and some desktop-specific backend (x-d-p-gnome, x-d-p-kde, etc., or x-d-p-gtk as a last-resort implementation for desktop environments that don't provide their own).
There is no "Zenitylike" portal. It was suggested in https://github.com/flatpak/xdg-desktop-portal/discussions/1816, but there are (IMO valid) concerns about scope creep: the purpose of portals is to cross the privilege boundary between sandbox and trusted computing base, and not so much to provide an abstraction layer between desktop environments, but there is nothing in "pop up a warning message" or "ask a question" that actually needs to cross the privilege boundary.
here is nothing in "pop up a warning message" or "ask a question" that actually needs to cross the privilege boundary.
Oh, I was only asking about file dialogs, not a complete toolkit (nor about throwing away any fallback/toolkit code we have internal to SDL either).
I'll take the wins where I can get them, having a file dialog portal is one such win.
@Kontrabant @icculus Do we pick SDL_ttf (at some point in the future when system font lookup gets added) or fcft for font rendering on Wayland and maybe X11? slouken said SDL_ttf, but I want to hear your opinions too.
Also here is an idea on how to solve the "backend seperation" problem. Notice the seperate drawing and text drivers. They are there to make the toolkit work better on more "generic" platforms with no drawing APIs like Wayland/KMSDRM and so we can reuse the SDL_ttf/fcft driver on X11.
If we go foward with this "metatoolkit" idea, do we end up using it over libdecor for CSDs on Wayland?
We had quite a bit of issues with libdecor in the past and its maintainer is currently seemingly busy with other work.
At this point libdecor is only relevant on GNOME (and Weston, but you can probably count the number of people who use it for non-embedded purposes on one hand), and it works well enough at this point. Everything else uses the decoration protocol, so I don't think essentially re-implementing libdecor would be of tremendous use, and would end up shifting the maintenance burden onto SDL.
After some discussion and prototyping it seems like this might be a good approach:
- First, try to use the native messagebox/dialog/menu implementation (zenity is considered "native" for this discussion)
- Fall back to a system independent implementation that uses SDL windows and renderer.
The generic implementation would dynamically load SDL_ttf if available for font support, which would be extended with APIs to enumerate and select appropriate system fonts, and fall back to the debug font where that's not available.