Aca programando y dandole matraca a la libreria grafica de bajo nivel XCB, dentro de un docker con Alpine Linux.
Es mas rapido, chiquito (no dependencias) y directo que la famosa SDL, pero al precio de escribir mas, es mas complejo por que expone el subsistema X sin pudor! , y lo peor , muy poca documentacion ! Y ni la IA te salva ! Cual es mi meta (ya perdida) ? escribir el backend de la libreria Nuklear solo en xcb, luego usar la como interfaz para otro proyecto mas loco tipo juego Cataclysm DDA o Space Station 13 (MMORPG)... Pero casi seguro va derecho al cementerio. Pero es la diversion (o locura?) de hacer que aparezca algo en pantalla y se mueva... terrible.... #xcb #graphics #x11 #xlib #linux #gui
#XCB
Excited to announce that our paper with TU Wien on the first plaintext recovery attack against XCB-AES (IEEE 1619.2) has been accepted at #CRYPTO2025!
👉 https://ia.cr/2024/1554
#IEEE #Standardization #XCB #XCB_AES #cosic #kuleuven
A major blocker could be that it relies on my "poser" project: https://github.com/Zirias/poser ... it's a small lib, so you could certainly integrate the parts needed, but I didn't do it, I just made #Xmoji build with a bundled (statically linked) #poser by default instead. Another blocker could be that it does quite some trickery to force #xcb into an #async model with #events and registered event-handlers (provided by poser), so it integrates well with a generic event loop built on #select (which poser does, anything else based on file descriptors like #poll, #epoll, #kqueue would work as well). It abuses xcb functions meant for tracing/debugging for that purpose. 🙈
And then, of course, it's very different from #Xt. It strictly requires #XRender, using its "picture" objects as the primary drawing handle, and just offering the core X11 "drawable" on demand. It strictly requires a "true color" visual. It has NO support whatsoever for core drawing primitives and core (bitmap) fonts. It doesn't create a window for every widget but instead manages widgets fully client-side ... all these are probably not "blockers" but just how you'd design a GUI toolkit for X11 nowadays 😉
And then, of course, it's very different from #Xt. It strictly requires #XRender, using its "picture" objects as the primary drawing handle, and just offering the core X11 "drawable" on demand. It strictly requires a "true color" visual. It has NO support whatsoever for core drawing primitives and core (bitmap) fonts. It doesn't create a window for every widget but instead manages widgets fully client-side ... all these are probably not "blockers" but just how you'd design a GUI toolkit for X11 nowadays 😉
Haha, well, I'd stick to putting "#toolkit" in quotes only. For once, it's entirely non-portable to anything other than #X11 (with #XRender) via #xcb (like e.g. #wayland or #GDI) ... xcb types/interfaces are hardwired practically everywhere. And then, although it might be possible to extend it to some "generic" toolkit specifically for that platform, I have no plans doing so. I strictly only implemented what was necessary for #Xmoji's GUI. 😉
You might have noticed development of #Xmoji slowed down a bit. My time is currently very limited, but another reason is slowly closing in on a version 1.0, and I want to give it some time for proper testing.
I need your help, please! 😁
Xmoji 0.8 introduced an important part for #i18n, translations. But I'm not exactly fluent in many languages. Please, if you can, help me translate! The process is documented in https://github.com/Zirias/xmoji/blob/master/TRANSLATE.md . If there are any issues with these instructions, please let me know.
Xmoji aims to be the "best" tool to input emojis with "pure" X11:
Roadmap to V1.0:
#X11 #emoji #keyboard
I need your help, please! 😁
Xmoji 0.8 introduced an important part for #i18n, translations. But I'm not exactly fluent in many languages. Please, if you can, help me translate! The process is documented in https://github.com/Zirias/xmoji/blob/master/TRANSLATE.md . If there are any issues with these instructions, please let me know.
Xmoji aims to be the "best" tool to input emojis with "pure" X11:
- Written in plain #C, with minimal dependencies
- Uses #Xrender for its UI, communicates with the X server using #xcb
- Offers two methods for input: Faked keyboard events or the "primary selection"
- Has a search tab and a list of recently used emojis
- Customizable appearance using X resources
- Several options to configure key injection and the search method
Roadmap to V1.0:
- Optional single-instance mode
- Optional tray icon
#X11 #emoji #keyboard
#xcb #development thoughts:
One of the features I'd like to add to #Xmoji is a "system #tray icon". I know these aren't "en vogue" any more, but I like the concept a lot for an application you'll typically leave running and only use from time to time, which is likely a usage pattern for an "#emoji #keyboard".
So, I found a spec based on #XEMBED, X selections and client messages (therefore, pure X inter-client communication), I think I can implement that! 👍
https://specifications.freedesktop.org/systemtray-spec/0.2/
Digging deeper, I found there's a successor called #SNI and the spec above is considered "legacy" (after only 20 years, hehe) 🤨. SNI is based on #dbus. Oh damn ... it's not that I particularly hate dbus, it probably makes a lot of sense for complex desktop environments, but I really want to keep #Xmoji "plain #X11". I'll just use the old spec. At least I found #KDE seems to have a compatibility service: xembed-sni-proxy. No idea about Gnome. But then, screw it.
Finally removed the nasty "glitches" setting from #Xmoji!
After lots of (unsuccessful) research whether I can somehow check which modules(!) are loaded on the X server (to find out whether #GLAMOR is used, which I *think* causes a bug in compositing glyphs with #XRender) ... I finally remembered an old strategy which is both horribly ugly and pretty reliable: probing!
I now do a dummy glyph compositing to a single-pixel off-screen pixmap during startup and fetch the resulting pixmap from the server, so I can simply *see* whether the result is buggy. 🙈
https://github.com/Zirias/xmoji/commit/93143775e6ad9b01f7f23b2da48c5e6921669fd0
I actually wonder why I didn't have that idea much earlier. E.g. coding on the #C64, probing the hardware (e.g. to identify VIC and SID model by their behavior) is a pretty common thing to do 🥸
In case anyone is interested, this is how this exercise looks like:
The point coordinates for the consecutively rendered triangles are in the arrays "points" (the "background") and "x1points" and "x2points" (the "X") 🤪
I guess I "fixed" it now, this looks pretty obvious, right? 😎
Using triangles to render an X is really a "fun" exercise btw 🤯
Tricky question about #X11 (with #xcb) #programming:
Is there a way to determine from an X client whether the X server uses #glamor acceleration?
Background, I experienced a rendering bug compositing #glyphs with #XRender where the source coordinates don't work as expected. I found a workaround (that of course breaks when the bug is *not* present): Apply a transformation to the source picture.
I now suspect it's glamor introducing this bug, independent from the actual GPU driver. So it would be awesome if I could automatically enable the workaround when needed. I guess it's not possible though, but hey, I can ask 😎
#Xmoji 0.3 released!
I decided to not mark it as a pre-release any more because it now has the history tab, which IMHO completes the minimal feature set to make it actually useful.
It's still in a very early stage and might have bugs I didn't find yet, so, testers would be very welcome! 🤗
Get the source tarball (.tar.xz) from here:
While testing for the next pre-release, here's one of the weirder commits. In a nutshell, there are interesting surprises regarding the behavior of some window managers – the "story" is in the commit message 🤪😅
https://github.com/Zirias/xmoji/commit/4b6a83b154e54137855789a7781805f6d81babd3
Finally some progress again with #Xmoji (#X11 #emoji #keyboard): Added the history tab!
History is persisted in a config file that should also hold other runtime config later and is watched for changes. For now, I only implemented the naive portable "watching" method periodically calling #stat ... backends for #FreeBSD #kqueue and #Linux #inotify will (hopefully!) follow 😉
@doerk @gnemmi The freedom (of choice!) offered to users *should* be basically the same with GNU/Linux – in theory. My guess what's wrong is that very few (or even just one) distributors are "in control", but contrary to a BSD and thanks to the radical "bazaar" model, they aren't "the project" and mostly just follow their niche interests (like e.g. selling in the "enterprise" market).
Regarding #Wayland, I never even tried. I'm pretty sure (based on what I read on forums, irc, mailing-lists etc) I could run my favorite DE (#KDE #plasma) that way pretty fine, but why should I, as long as I have a flawlessly working #Xorg setup? Plus, I recently run an #fvwm3-based session much more often. Partially because my desktop hardware is (really!) old, partially because I really love its flexibility and configurability. And then, that's "X11 only".
I was looking for an #emoji #keyboard working with X11 (not dependent on specific input methods or toolkits like Qt or GTK) and didn't find anything matching my expectations, that's why I decided to build one. I more or less finished something using #Qt for the GUI (but plain X11 for actual emoji input). Works well enough, but I needed bad hacks around performance issues to make it at least acceptable on my old hardware. That's how I started looking at "raw" X11 at all (using #xcb). And here I am, hoping to finish that one soon, with mission statement "build the perfect plain X11 emoji keyboard" ... we will see:
https://github.com/Zirias/xmoji
And now did the same for the 1x1 pixmaps needed as a "pen" for compositing shapes (or glyphs) in a solid color.
I can't see any change in performance even on my very old desktop, but still it avoids a lot of requests on the line (so, might be relevant on a remote #X11 connection) and also avoids allocating tons of redundant pixmaps in the X server. And I really don't like inefficiency. 😊
https://github.com/Zirias/xmoji/blob/master/src/bin/xmoji/pen.c
#X11 #programming with #xcb: Optimizing a few things before starting new #emoji #keyboard features ...
Started with adding an abstraction for rendered "shapes" (alpha masks that can be used to composite a single-colored shape onto something else). Instances are cached and reused without rendering again when the same render function and data is given. Using this for the triangles indicating availability of a "fly-out" menu, I see a *huge* difference on my (very old!) desktop, initial rendering of the tab containing these flyouts is now instant (and took roughly half a second before). You probably can't tell the difference on a modern PC, but still ... 🥳
https://github.com/Zirias/xmoji/commit/164847a899b16773661865dfc6ea7e110867e169
I was using #XCB, I tried raw stuff to the #framebuffer and OMG 1000x faster! AND I can rip shttons of useless code out of my cloud client thin antibrowsers! #OldGuyCoding #Programming For the record, years ago I wrote a raw gui device driver for gui, it took me a few days, SDL took me MONTHS GET OFFA MY LAWN!
Client Info
Server: https://mastodon.social
Version: 2025.07
Repository: https://github.com/cyevgeniy/lmst