Weekly report 20-39 =================== :tags: blog, report :date: 2020-09-28 There my time went ------------------ I wanted to make some more progress on link:/text/weekly-20-38.html#_where_did_my_time_go[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 https://gitlab.gnome.org/search?search=is_gsource&group_id=8&project_id=1551[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 https://www.remlab.net/op/xlib.shtml[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 https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/36[problems] of its own, the least of which is a lack of decent documentation. But I've link:/article-xgb.html[been] https://git.janouch.name/p/tdv/commit/942bda7db4b7b9e5bae6ad1ad81295b1f346a9f6[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 https://gitlab.freedesktop.org/xorg/lib?filter=libxcb[separate libraries]footnote:[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.`']. 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 https://xfree86.org/4.8.0/ctext.pdf[specification] and, seeing as it didn't look too intimidating, decided to make https://git.janouch.name/p/wdmtg/src/branch/master/compound-text.c[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.