The goal and scope of the GTK backend in druid-shell

[xStrom]

What exactly is the goal of the GTK backend in druid-shell?

Is it a temporary solution or a more permanent one?

• If temporary, what is the real goal? Some sort of barebones X11 and Wayland support?
• If it's a permanent target, then what is the scope?
  • Ubuntu
  • All Linux flavors (distros/X11/Wayland)
  • All GTK platforms (including Windows/macOS)

The problem with GTK is that it's not consistent. It has platform specific behavior. For example for mouse events the ModifierType docs state the GDK X backend interprets button press events for button 4-7 as scroll events, so gdk_button4_mask and gdk_button5_mask will never be set. There are also similar issues with keyboard events.

This means that it's not possible to just target one GTK. The GTK druid-shell layer has to basically have an internal gtk-shell abstraction which deals with delivering a consistent GTK API across the different platforms that GTK might run on.

[luleyleo]

Considering the fact that GTK is way more than we would actually need in combination with the compile times it causes (I was really impressed how much faster druid could compile when I tried it on Windows) I would prefer to replace it with more fitting solutions such as barebones X11 and Wayland support.

It is currently not really possible to see if the X11 back end has better compile times as it depends on GTK due to how the druid-shell build is organized, but I would imagine it to be much faster.

Also a problem we will have with X11 + Wayland is that druid-shell would have to chose the correct back end at runtime but I think that can be solved by having some kind of middle layer that merges the X11 and the Wayland back ends.

[xStrom]

With dropping GTK I guess some of the issues are menus, titlebars, file dialogs. There would need to be druid implementations of these, right?

[luleyleo]

For bare bones X11 and Wayland context menus will always need a druid implementation while menubars, titlebars and file dialogs in some / most cases will need a druid implementation.

For example on KDE there is an optional MacOS like menu bar (If the user wants it) and always titlebars. And when bundling as Flatpak there will be file dialogs.

So yes, in the end all of those need a druid implementation at least as a fallback option.