[yjftsjthsd-h]

I am loving the shift from 'X11 is too big and messy to ever reimplement' to 'there are multiple wildly different X servers being built from scratch'.

Also, has anyone run it successfully? I got as far as building and running with --display and then running `DISPLAY=:7 dwm` and `DISPLAY=:7 alacritty`, but I can't seem to focus the window to actually type. Given that the author posted a picture of the thing actually running a live environment and claims to actually be using it, I'm pretty sure this is a me problem but I haven't been able to figure out where it is. Mouse works, too.

[vidarh]

Yeah, I have a mostly-functioning X11 server in Ruby, myself (not anywhere public yet).

Isene and I have relatively similar philosophies on this, except I have Claude burning tokens on optimizing and fixing my Ruby compiler now because I still want things in a high-level language, and my entire stack is Ruby instead of asm. But I love what he's doing - I just don't love x86 asm...

Turns out a functioning X server is a relatively simple piece of software. It's mostly just tedious. And most of the bulk is protocol handling that Claude can handle really trivially.

[ptx]

Wasn't a lot of the protocol encoded in XML as part of libxcb? Could that be used to generate the tedious code for the X server?

[vidarh]

Yes, you're right.

There are other tedious bits too, like all of the details around exactly how to propagate which events, but the protocol encoding is certainly one of the most tedious bits.

[Kelteseth]

> 'there are multiple wildly different X servers being built from scratch'

by claude code. So this was only possible since no human had to bear looking at X original source code.

[vidarh]

I think not looking at the original X source code is probably a good thing. The protocol is reasonably well specified, and you can further use the XML specification used for XCB. Most of the requests are pretty simple.

For some of the trickier ones it might be worth diving into an X11 implementation, but you can also defer most of the trickier ones other than getting the event handling right (most of the old school drawing API mostly matters if you want to run 30+ year old software that hasn't been updated much since; that said it might be nice to be able to run twm and xeyes - I have a whole separate file in my own X11 server for legacy stuff required to run twm and xeyes and similar ancient software, but not useful for anything else I actually care to run...)

[bogdan]

Try running `tile` as a wm. I imagine it's not fully compliant to support dwm.

[yjftsjthsd-h]

Huh. So it's not the window manager. It's individual applications that are working or not.

Working: tile, dwm, pcmanfm-qt, feh, dmenu, glass

Not: alacritty, st

So... Thus far, anything but a terminal other than glass. I'd think the problem was alacritty doing fancy things with APIs that frame doesn't have, but st??

[vidarh]

There are 3-4 typical different approaches to rendering text on X. If it's not yet (or not correctly) implementing one or two of them, that'd explain it.

EDIT: Testing with xtruss shows st uses RenderCompositeGlyphs8(), part of the RENDER extension. I don't have Alacritty installed, but I think Alacritty uses the GPU, at least by default? Looking at the source for Glass it seems to use PolyText16 - the "old school" old server-side font rendering API. A lot of older X11 apps would work fine with PolyText16, and a lot of newer X11 apps does all the text rendering client side into a shared memory buffer without requiring GPU support, so it's not hard to end up with a set of applications where none of them would run into either gap.

EDIT2: I've looked at the Frame source, and it does seem to have support for the RenderCompositeGlyph calls and other supporting request, so not sure what the issue with st is. It's not doing anything unconventional.

I'd try rxvt (PolyText8/16) or xterm (ImageText8/16). If either/both works it's likely an issue with the RenderCompositeGlyphs support.