Getting closer: I now have a Pixmap class (to hold and render bitmap data, loading it from #PNG using #libpng), an ImageLabel widget to display a pixmap, and the first working "real" (using #EWMH) dialog window! ๐Ÿฅณ (of course, for testing, an "about box" ๐Ÿ™ˆ)

libpng was surprisingly easy. Getting bitmap data with an alpha channel in some #X11 pixmap was surprisingly hard ๐Ÿง. It seems just uploading it with #xcb (xcb_image_put) converts the alpha channel to a single bit, making the corners look super ugly ๐Ÿคจ.

So now, I separate out the alpha channel to upload it to a separate pixmap and then combine that with the rgb-pixmap into an argb-pixmap that's finally used for rendering, here's the whole dance:
https://github.com/Zirias/xmoji/blob/b7216b5f134985d9daa3f6b6da8315e9b6739440/src/bin/xmoji/pixmap.c#L68
I *could* save one rendering request by keeping those two pixmaps and render with a mask each time, but didn't because it will consume more server-side memory...

#X11 and #XRender experts: Do I miss anything, is there a saner way? ๐Ÿค”

xmoji/src/bin/xmoji/pixmap.c at b7216b5f134985d9daa3f6b6da8315e9b6739440 ยท Zirias/xmoji

Contribute to Zirias/xmoji development by creating an account on GitHub.

GitHub

#X11 #programming with #xcb: Adding more more-or-less useful window properties.

- _NET_WM_ICON, containing three icon pixmaps of different sizes
- _MOTIF_WM_HINTS, in an attempt to tell the window manager which buttons I'd like to see (which, well, is interpreted quite liberally if at all, e.g. I don't want a minimize button for my dialog, but, there it is, this time testing in #KDE/#kwin)

The window icons work nicely, but I now have serious doubts about big-#endian platforms (I just copy the bytes obtained from #libpng to X11 ...)

Any good ideas for testing big-endian without owning actual big-endian hardware please? Thanks! ๐Ÿ˜Š

On a side note, the build is quickly growing ๐Ÿง

A relevant part of it comes from "embedding" #binary #png images into the executable. Here's indeed a weakness of my favorite #programming language: #C. There's just no standard way to include binary data ๐Ÿ˜’

In the past, I had hacked something together with #objcopy. Non-portable, and doesn't work any more with the llvm tooling installed with #FreeBSD 13.3. I tried the #incbin pseudo-opcode which worked perfectly, but that's non-portable as well, you can't rely on the #assembler to support it. So I took the only portable route, generating C source (embedding the binary data into "string literals"), which requires a separate little tool built in a sub-make ๐Ÿคฏ

This is really a feature #C desperately needs: a standard way to embed binary data.

@zirias

There's just no standard way to include binary data ๐Ÿ˜’

There is, #embed is part of C23. Prior to that, xxd -i is the easiest way: it takes a binary file and generates a C header file that includes the binary data as a char array.

@david_chisnall #xxd is nice, but typically comes with a #vim package, so that's kind of a weird build dependency ๐Ÿ™ƒ

Fortunately, the code needed to do it myself isn't too large:
https://github.com/Zirias/xmoji/blob/master/tools/bin2cstr/src/bin2cstr.c

-> Very nice #C23 solves this! It's probably not too portable to require it just yet, but then it's just a matter of time ๐Ÿ˜Š

xmoji/tools/bin2cstr/src/bin2cstr.c at master ยท Zirias/xmoji

Contribute to Zirias/xmoji development by creating an account on GitHub.

GitHub
@zirias It's separately packaged on FreeBSD. I didn't realise it was part of vim until a couple of years ago when I found a Linux machine that didn't have it and didn't have an xxd package. I can't imagine not having it installed, it's such a useful tool.
@david_chisnall Sure! But requiring it as a build tool is still a different story, at least as long as you expect interested hobbyists to build from source on their local machines ๐Ÿ˜‰ I generally try to keep the "build-only" dependencies to a minimum...