Qt 5.x on Linux - detect X11 vs Wayland

ileonte

I haven't looked seriously into Qt development since the days of 4.8 but I've recently started doing it again and I have a question I can't seem to find the answer to: with Q_WS_ constants being dropped in favor of Q_OS_ in Qt 5.x how do I detect if my application is being built on an X11 Linux installation versus a Wayland one (or DirectFB or any other graphics backend) ?

SGaist

Hi and welcome to devnet,

AFAIK, there's no drop in replacements. Out of curiosity, what would it change for your application ?

ileonte

@SGaist for this application in particular I'd like to have it respond to a global key binding. Not sure if this is even possible on Wayland without the help of the compositor but on X11 at least I can get away with a fairly window-manager-agnostic solution by using XGrabKey() and a native event filter on the QApplication object.

? Offline

@ileonte Hi, I'm not sure if I understood your intention correctly. Maybe you can check for the presence of the DISPLAY (X11) and WAYLAND_DISPLAY environment variables at runtime?

ileonte

@Wieland I'm talking about compile-time detection - stuff like "do I include xcb headers or wayland headers ?" or "do I tell qmake to include my X11-specific GlobalShortcut implementation into the SOURCES variable or should it include the Wayland one ?". This was possible in Qt 4.x by checking QT_WS_* defines in C++ code and by using x11:SOURCES += ... in the project file but these don't work anymore.

? Offline

@ileonte Ok, understood. AFAIK there is nothing like QT_WS_* there at the moment. I think (but maybe I'm wrong) that #ifdef WAYLAND_VERSION could do the job.

ileonte

@Wieland as far as I understand platform-specific code is kept in plugins in Qt 5.x which means that define you speak of would only be present if I include Wayland headers myself, which is what the initial problem is all about.

SGaist

Isn't wayland a "drop-in" replacement for X11 ?

ileonte

Nope, not even close to :) Especially if you have to interact with it directly instead of through some high-level layer like Qt.

SGaist

Yup, my bad, I've misunderstood the goal of the project. But in that case, shouldn't you be able to use XGrabKey with both wayland and X11 ?

ileonte

@SGaist XGrabKey() is an Xlib function and needs to communicate with an X11 server. On Wayland there is no such thing (people will point to Xwayland but that is not really a solution - Qt itself is a native Wayland client so forcing the extra dependency on Xlib for people running pure-Wayland doesn't make sense).

In any case, this is really not the point of this topic. The point is that I find it strange for Qt to remove this extra bit of platform detection capability. It wasn't that long ago that MacOS was in a similar situation where there were multiple Qt versions (Cocoa vs Carbon) but at that time you still had Q_WS_* to fall back to. On current Linux you have at least 3 competing windowing solutions (X11 vs Wayland vs Mir). Relying on OS detection alone doesn't cut it in cases where you need/want to do something that Qt hasn't covered.

SGaist

Cocoa VS Carbon was another situation, you would either build for one or the other, you wouldn't have both at the same time.

In your current situation, how do you plan to distribute the wayland version of your application ?