Choosing a backend

I got drawn into a discussion today and swiftly realized there is no right answer. But there should be!

The question is deceptively simple: Which order should graphics toolkits probe for backends?

My contention is that the answer is: “it depends”.

Suppose that I’m running a traditional X11 based desktop and am testing with a new technology (obviously Mir, but the same applies to Wayland) running as a window on top of it. (I.e. Mir-on-X or Wayland-on-X)

In this case I want any new application to *default* to connecting to the main X11 desktop – I don’t want my test session to “capture” any applications launched normally.

Now suppose I’m running a new technology desktop that provides an X11 socket as a backup (Xmir/Xwayland). In this case I want any new application to *default* to connecting to the main Mir/Wayland desktop – only if the toolkit doesn’t support Mir/Wayland should it connect to the X11 socket.

Now GDK, for example, provides for this with GDK_BACKEND=mir,wayland,x11 or GDK_BACKEND=x11,mir,wayland (as needed). But that is only one toolkit: OTTOMH Qt has QT_QPA_PLATFORM and SDL has SDL_VIDEODRIVER. (I’m sure there are others.)

What is needed is a standard environment variable that all toolkits (and other graphics libs) can use to prioritize backends. One of my colleagues suggested XDG_TOOLKIT_BACKEND (working much the way that GDK_BACKEND does).

That only helps if all the toolkits take notice. Is it worth pursuing?

5 thoughts on “Choosing a backend”

  1. I don’t think so.

    Because “testing a new technology” is a developer-enabled short-term operation. And as the developer you will already know what you’re doing, so you’ll set the right environment variables.

    Also, it should definitely not be an environment variable, because you’ll never find one that works for everyone. (I’ve wanted to make GDK_BACKEND support “x11-core” for example to select our barebones X11 without XINput and Xrender support.)

    If you wanted to support it, the windowing system should support a way to query if it is running inside a different windowing system so toolkits can decide dynamically to connect to those instead.

    And when we argued this for GTK, we decided it’s not worth it, because there is just no use case for running 2 windowing systems at the same time.

    1. If there were no use case for running 2 windowing systems at the same time then there would be no need for Xwayland nor Xmir.

      Knowing if a windowing system is running inside another wouldn’t tell a toolkit which one the user intends it to connect to. (In any case, I can imagine starting Xmir or Xwayland by socket activation – which is wasteful if it is only needed to answer this query.)

      One environment variable cannot address all needs, but having one recognized by all libraries can help:

      /1/ the developer that needs to figure out the right environment variables for every application; and,
      /2/ the windowing system that supports multiple connection mechanisms for compatibility purposes

      But it would only be useful if support were widespread – so you’re probably right.

Comments are closed.