Weekly report 20-39

Weekly report 20-39

There my time went

I wanted to make some more progress on wdmtg, so that I can finally be done with it. This has turned itself into yet another rabbit hole. First, I had issues with Vala, where I was unable to subclass GSource--the compiler special-cases it and fails to generate code for any fields you declare in your object, which always becomes a simple typedef of GSource. Considering that this was just another nail in the coffin, so to speak, with countless hours spent dealing with having to read API documentation for both C libraries and their Vala bindings, looking for relationships, I have given up and rewritten the entire thing in C, save for the GUI, which currently amounts to a trivial subclass of GtkWindow. I still hold on to my belief that writing GTK+ code in C is worse than doing it in Vala, and I’m ready to be disappointed again. These binding problems are what makes me so excited about Go and its separate, native ecosystem.

Following that, I pondered about Xlib error handling, and whether GTK+ couldn’t have any issues with my custom handler. The best way to take care of this is, of course, to port all my Xlib code to XCB and thus avoid any possible interactions altogether. That has sadly, though perhaps unsurprisingly, brought some problems of its own, the least of which is a lack of decent documentation. But I’ve been there, and I already know how to deal with it, for the most part.

In general, XCB requires you to write a lot more code. And sometimes you won’t be able to find large pieces of matching functionality at all, not even as separate libraries[1]. Such was the case with converting the old COMPOUND_TEXT format to Unicode, which Xlib does transparently in its Xutf8TextPropertyToTextList and related functions. It may not be really used much anymore, given that UTF8_STRING is in wide use now, though I wanted to retain the ability to read out titles of ancient X11 applications, if at all possible. So I had another look at the specification and, seeing as it didn’t look too intimidating, decided to make my own parser/convertor, just excluding support for CJK encodings, as I don’t particularly care about them and they carry a high cost. It took me a ‘mere’ day and the result is easy to port to XGB in the future as well.

Call me the master of all rabbit holes. A yak shaver par excellence. I so wish to work on a higher level of abstraction. I always seem to get dragged down to the gory details.

That being said, I’m inching closer to a real prototype. Most of the critical work is behind me.

Code style

Historically, I’ve been putting a GNU-style space before the opening parenthesis of a function and made sure to put all braces on a new line, if the programming language allowed it. But you know what? Screw doing both of these. I’ve already learnt that such choices are mostly just meaningless personal preferences. Starting with this project, I’m adopting a more generic code style. I won’t have to make as many mental adjustments when switching between projects.


1. The READMEs say the following: ‘If you find any of these libraries useful, please let us know what you’re using and why you aren’t in a mental hospital yet.’