Anyone who claims to have used and *liked* Xlib is either a fool or a lying fool. It's that simple. 25 years ago, Xlib might have been the best thing since sliced bread. Guess what? Times change. Xlib didn't.
Now, I'm sure there are people who grew up writing Cobol for a living. Some, in a perverted form of masochism, may have even ended up liking the language. That doesn't mean the language doesn't suck, it just means they are looking at it through rose-colored glasses.
As someone who has been working with xlib, win32, carbon, cocoa and a handful of other low-level APIs for the better part of a decade, rest assured that xlib/X11 is every bit as painful as most people claim it is. Its design is fundamentally broken. For instance:
- Bad threading model. XInitThreads must be the very first call and every single call must be protected by XLockDsplay/XUnlockDisplay. Good luck embedding a 3rd-party component that doesn't follow this pattern in your application. For instance, GTK+.
- Ill-designed mouse input system. No relative movement events, single mouse wheel treated as two discrete *buttons* not an axis (making polling impossible), all modified settings take effect globally (e.g. your FPS game needs to disable pointer acceleration; if it crashes, it will remain disabled *globally*). No way to disassociate the logical from the physical mouse location. No support for high-resolution wheel events, multi-touch or any other remotely modern feature.
- Ill-designed keyboard shortcuts model. In conjuction with the above, this leads to a huge number of applications calling XGrabPointer/Keyboard, which is a fucking usability nightmare.
- Awful multi-monitor support. There are several different, incompatible multi-monitor APIs, each with different capabilities. Some APIs will cause the screen to flicker just by querying available video modes. It's such a nightmare that it's only in 2011 that X11 gained the ability to block the mouse pointer from entering the void outside visible monitor areas (something that has never even been an issue on other operating systems).
- Drawing commands are slow and extremely low quality (no antialiasing, no subpixel precision, plain bitmap fonts, a fucking nightmare). Using these is the best way to make your application look like a sad 1990 relic. Video rendering must go through a different API. Hardware-accelerated video rendering through one of 3 different APIs. Accelerated drawing commands through yet another different API.
XCB fixes *some* of those issues but introduces more of its own. Try creating an EGL or OpenGL context with it, for example. Besides, XCB doesn't alleviate any of the input, multi-monitor and rendering problems.
So yeah, keep shoveling shit over a bad foundation. The result can only go one way, and that way is down the drain. Apple relegated X11 to an optional legacy component of its desktop OS and banished it completely from its mobile one. Google did the same and based Android and ChromeOS on completely different technology. Mainstream Linux distros are preparing to jump ship as soon the replacement is ready. KWin and Qt can already run on Wayland.
Make no mistake, X11 is on its way out. It will remain as a legacy option, but investing large amounts of time and money into it no longer looks like a very bright idea.



Reply With Quote