# Will any program written with XLib work on any desktop environment (Gnome, KDE, etc.)?

I'm making an application that uses Win32 API on Windows but I want to support linux distros too.

Some people say linux doesn't have a native GUI API like Win32 API of Windows.

But I found XLib and it seems like it is somethink similiar to Win32 API. If I use XLib on my project, can I compile and run it on any linux distro that uses any desktop environment without using external libraries?

I don't want to use something like GTK+ or SDL because I'm learning Win32 (just for fun) and using a platform independent library along with Win32 API sounds really absurd.

• You'll have to decide: do you want to learn how to program under Windows with the Win32 API, or do you want to have a portable app? – Vaillancourt Feb 21 '17 at 0:14
• You say you don't want to use a portable solution because you are learning Win32. Well that means you will be using a non-portable solution. At best you will be using conditional compilation, at worst you will be doing a project for each platform. And that while you want to learn Win32? For your mental health, I suggest to focus on Win32 until you are ready to move to something else. – Theraot Feb 21 '17 at 12:42

Short answer: yes, XLib will work for the foreseeable future.

Although in some enviroments there will be additional libraries required. You don't need to worry about that.

XLib

XLib targets X Windows Systems (a.k.a X11). XLib is the classical library to use with X11 as works very close to it. XLib also includes a lot of helper code that eases the integration with the desktop environment.

X11 has been the core for desktop interfaces in the Linux ecosystem for a long time. Desktop Environments such as Gnome and KDE build on top X11... in essence X11 is a protocol, where the client sends requests and the X Server responds (will talk a bit more about that below), this is hidden by XLib which stores the requests in a buffer which are then taken by the X Server which will respond asynchronously, but XLib will make it appear synchronous.

High level components such as buttons et.al. exist as widgets on XLib, so this is the closest to the equivalent Win32 API.

XCB

All the communication hidden by XLib makes error handling harder, which led to the creation of the competition: XCB, which is intended to replace XLib by providing direct access to the X protocol. That means that XCB has a smaller footprint, it is asynchronous and has better performance. This makes XCB better in terms of performance, in particular for threaded applications.

Plot twist: XLib since the version 1.2.0 is actually built ontop of XCB. This means that you can mix XLib and XCB code with no problem... but it means that you need an additional library for XLib since it depends on XCB.

X Server

As mentioned above, there is an X Server that provides the abstract information and talks to the screen and input devices. The server doesn't know anything about user interface design. Then there are X Clients, which will interface with the server... this architecture facilitate for Clients to work over the network allowing access to remote terminals/desktops (although that's an over-simplification).

The X Server doesn't know about GUI, allowing it be changed, that's what Desktop Environments do. In this scenario X11 does all the rendering, although libraries for hardware accelerated graphics might bypass this.

Wayland

In the past there were competitors to X11, many deprecated... and there are new competitors to X11, in particular I want to mention Wayland.

Wayland is another protocol, much simpler than X11, that yields control of the actual rendering to the client.... basically Wayland shares a buffer for video memory where the client renders whatever it wants however it wants, so there is no graphics API. In fact, Wayland will handle the concept of windows and the composition of these buffers in video memory according to the windows they represent. This makes Wayland better for encapsulation in general (no API means less surface, and the model allows to isolate the memory easily).

X11 has needed a lot of updates to remain relevant with new technologies and standards (e.g. supporting font and image formats, supporting hardware acceleration, etc...), but with Wayland that problem goes to the graphic libraries the developer use.

While support for Wayland is increasing, X11 will stay around because of all the software build around it. What is expected to happen is that code from X11 will become part of the kernel, become extensions to Wayland or become libraries to be used by developers.

For instance, what do you do if you have a machine that runs Wayland but you need to run a program that uses X11? Well, there is XWayland that will run an X Server on top of Wayland.

Mir

I also have to mention Mir, which is a competitor to Wayland made by Canonical Ltd. (the people behind Ubuntu). It differs from Wayland in that Wayland doesn’t handle input but Canonical wanted that in there... so they made their own.

Similarly to Wayland, it will be able to run X11 using XWayland... but on top of Mir.

Conclusions

There may come the day where X11 isn't what you want to target. And also in the present there are environments where targeting X11 requires additional libraries.

• Is it possible (is it good idea) to have app that uses X11 with XCB/Xlib and work in Gnome (KDE) environment? Will there be any conflict between "raw" X11 user application and rest of Gnome software and desktop environment extras? – i486 May 15 '20 at 14:29
• @i486 Gnome and KDE, coexist, and are build on top of X11. I'm not aware of any conflicts with Xlib. If anything, using Xlib may require more effort for the same result than using GTK or Qt, but will not depend on the desktop environment. This may further clean some doubts: Difference between Xorg and Gnome/KDE/Xfce. – Theraot May 15 '20 at 21:19