In this post I want to create a single file C file program to open a windows inside Linux without using xlib or any similar libraries. The idea is to explore X11 protocol and see how it is used to interact with X server to create windows.

source: HN

If you hang around people who automate things in their X session, you may have heard of xdotool. If you’ve tried it, you may have noticed that xdotool seems pretty successful in manipulating the windows of X programs, despite the general feelings about SendEvents, and so you might wonder what’s going on here. The answer is that xdotool (and other automation programs) use a second mechanism to inject synthetic events, the XTEST extension (protocol).

Most people who deal with X resources, me included, generally deal with them at a relatively superficial level. At this level, you can say that X resources are a text based key/value database, with the name (key) of every resource being a composite name that specifies both its program and some program specific name (although there are conventions for the name portion). But if you start to look at the actual names for X resources, things start looking a little more odd.

Into the rabbit hole.

Also: https://utcc.utoronto.ca/~cks/space/blog/unix/XResourcesFailure

One of the problems with X resources is that they’re arcane and hard to manage.

DDC, display data channel, is a protocol for reading information about what resolutions and so on a monitor supports. It was later extended to DDC/CI, that lets you set brightness and other parameters, but fundamentally, the original idea was to stick a cheap i2c eeprom on each device with some basic info on it. (Technically, the original idea was even simpler than that, but let’s not get into that.)

It began in the VGA days, but has become so entrenched that even modern hardware with HDMI or DisplayPort supports it. That’s right, in an HDMI cable, nestled amongst the high-speed differential pairs, there’s an exceedingly slow i2c bus.

Tiny OLED dot-matrix displays often have an i2c controller, so I had the idea to try and plug one directly into an HDMI port.

source: HN

Some useful config options showing off flexibility beyond the basics.

source: Dfly

One of the important consequences of this split between core input events and XIE events is that events that look identical at the core input event level (for example, as shown by xev) may be different at the XIE level (as interpreted by libXi and then toolkit libraries, and perhaps as shown by xinput). This means that some programs will treat them exactly the same because they’re indistinguishable and some programs may react to them differently. This can cause rather odd issues, but that’s a story for another entry.

Also: https://utcc.utoronto.ca/~cks/space/blog/linux/XInputGtkScrollPuzzle

oxbar is a X11 status bar for OpenBSD showing various system stats. It has a configurable display and works out-of-the-box on most modern window managers in an intuitive fashion. oxbar supports FreeType font rendering and styling, true transparency & alpha blending on all UI components (including the root window), and a simple configuration format that can concisely support multiple themes.

source: vermaden

The X protocol (and server) come with a pre-defined set of cursors. If your program is happy with one of these, you use it by telling the X server that you want cursor number N with XCreateFontCursor(). As mentioned in the manpage (and hinted at by the function name), the server loads these cursors from a specific X font, which is exposed to clients under the special font name ‘cursor’. Like the special ‘fixed’ font name, this isn’t even a XLFD font name and so there’s no way to specify what pixel size you want your cursors to be in; you get whatever (font) size the font is or the server decides on (if the X font the server is using is one where it can do that, and I’m not sure that the X server even supports resizable fonts for the special cursor font).

A shell may be more accurate?

source: HN

The goal of Explanations is to try to allow people to play with fun parts of computers. Graphics, compression, audio. The tagline is my biggest inspiration: “Play, don’t show”, riffing off the typical “Show, don’t tell” rule of writers and authors everywhere. Why bother giving a diagram when I give you an inspector and let you poke at things yourself!

Previously, this series was known as “Xplain” and was more focused on the X11 window system and protocol, but I’ve been slowly moving towards anything that interests me, and I’m hijacking this project for it since I really like the format and style I’ve developed. The code for every single one of these demos is available in the GitHub repo, and I do try to comment heavily and go into even more depth there! Play with the code! Use it for one of your own projects! It’s all MIT/X11 licensed. I very much appreciate followup questions and any sort of feedback through the links mentioned above.

You might have noticed that when you ran your mouse over the stipple, your cursor changed. That’s because this isn’t just any old stipple image, that stipple is actually the background of a full X server session running in your browser using HTML5 canvas. All of the interactive demos will use this framework to explain what’s going on under the hood.

Author comment: https://news.ycombinator.com/item?id=21041340

source: L

One answer to what I want out of my window manager is ‘fvwm’. It’s my current window manager and I’m not likely to switch to anything else because I’m perfectly satisfied with it. But that’s not a good answer, because fvwm has a lot of features and I’m not using them all. As with everyone who uses a highly customizable thing, my important subset of fvwm is probably not quite the same as anyone else’s important subset of it.

The 80/20 rule rears its ugly head.

Although I don’t know how it was done in the early days of X, the modern standard for this is part of the Extended Window Manager Hints. In EWMH, applications give the window manager a number of possible icons, generally in different sizes, as ARGB bitmaps (instead of, say, SVG format). The window manager or desktop environment can then pick whichever icon size it likes best, taking into account things like the display resolution and so on, and display it however it wants to (in its original size or scaled up or down).

Contents
A survey of toolkits
So let’s build one
Drawing in X
What almost everyone gets wrong
Text rendering
Double buffering
Keyboard
Scaling
Cursors
Demo and future

A setting for every config and a config for every setting.

source: Dfly

Also: https://www.jwz.org/blog/2017/12/xscreensaver-5-38/

And so began my epic journey into the wild and uncharted jungles of the Linux keyboard system. Or should I say systems. I wish I could draw you a map here, but I don’t have one. All I know is, I wandered about through many strange lands, having adventures. Please do not assume that anything in this article is technically correct.

More: https://shitpost.plover.com/s/software-sucks-3.html

source: Dfly

There is an integrated development window manager where you can: Select any compiler error text in any terminal and open the correct file and line in your text editor. Click on the output of ls in any terminal and open the corresponding file with the correct program. Click any url from any text on your OS and open it in your browser. What if I told you it is actually just a 100 line shell script?

https://github.com/andrewchambers/godothecorrectthing

source: L

As the guy who single-handedly prevented X from becoming an ANSI standard, I’d be happy to start another thread on this topic if people are interested.

source: L

Or X in general, probably.

source: L

How does that work? Is there more than one clipboard? How many are there? Do all X11 clients support all forms of clipboards?

Some bonus links:

https://keithp.com/~keithp/talks/selection.ps

https://www.jwz.org/doc/x-cut-and-paste.html

http://lists.slug.org.au/archives/slug-chat/2001/July/msg00054.html

source: L