zirias (on snac)

After implementing "#dpi awareness" (calculate resolution of the primary screen and use this for #fontconfig patterns) in #Xmoji, I was unhappy with the (correct) result: Everything too large for my taste. I also added a resource dpi to override the calculated resolution, setting this to 72 gave me the previous results, but it's logically wrong.

I now did a different thing to solve this: Give the Font resource (the class name for fonts other than the emoji font) extra semantics. Xmoji now checks explicitly whether a resource for this class is set, and, if so, considers that value the "default system font", basing all sizes on that.

Now I can just add Xmoji*Font: sans-10 to my .Xresources and get the looks I like with all other settings left at their default on my 96dpi display. 🥳

If you have any objections or run into unexpected behavior testing this, please let me know. I'd like to release Xmoji 0.9 "soon". 😎

(Medien: 1)

Someone mentioned they liked the little "#toolkit" that grew inside of #Xmoji 😉 ...

This gave me the idea I should attempt to document it somehow. If only for my later self 😎. First step: Try to create some visualization. Here's a very early draft of a "class diagram" created with #graphviz – so far showing only "is-a" (#inheritance) relationships. I hope I can add #composition edges there keeping it still readable, we will see... 🤔

And then, it will of course need quite some text explaining how things work together.

CC: @kaveman@bsd.cafe

#X11 #development

(Medien: 1)

It just came to my mind that another thing should probably go on the V1.0 roadmap for #Xmoji: A #manpage. But then, this reminds me of doubts I had ever so often: #Documentation should have a single source of truth (otherwise it will go out of sync eventually).

I could just declare that's the manpage now, which would mean to remove everything I put there from the README.md. Not ideal though, this markdown file is accessible for direct reading on github (and would be on other "hosted git" solutions), while it's still well readable as plain text. This certainly isn't true for some roff-like markup. 😞 There's the additional problem of which markup flavor to choose: the modern mandoc (which is native on #FreeBSD), or the classic troff man macro package (which still seems "native" in #GNU's man-db)... Modern installations support both flavors, but conversions aren't "perfect".

There are also many "document generators" around that typically allow output as html, pdf, man, ... but I didn't find one so far that really gave satisfactory results for man. A while ago, I wrote my own tool which can generate #C source for "help" output, man (in both flavors) and html, and this worked pretty nicely, but the key was a very limited scope, it only supports a few sections (general description, options, environment variables) and only options in the classic #POSIX style (single letter, collapsible). So, it wouldn't fit the bill for Xmoji.

Great ideas anyone? 😁

I just added an important piece of #documentation to #Xmoji's README.md: the commandline arguments. No idea how I could forget about documenting that so far 🙈

(Note the -class and -f options aren't implemented in Xmoji 0.8 yet)

#X11 #emoji #keyboard

(Medien: 1)

#OSS #development ... one thing I learned from bad experience is to never rush a release.

I just fixed a very stupid bug I introduced in #Xmoji while changing all the config file handling to work fully async¹ (simulated using a threadpool). There was a code path attempting to call fclose() on NULL. As a result, Xmoji didn't work any more if there wasn't a config file yet.

I didn't notice for two days straight, because I have my config file on my machine ... 🙈

These things happen, and if you don't want to release something with really silly bugs, give it some time 😉 ... and btw, I'd appreciate some testing done not by me, you know, different environment, different user expectations, this helps discovering more bugs!

Xmoji 0.9 will be there soon, I hope this time not too soon 😁

¹ I remember mentioning in some previous toot asking for help with testing that this was an intrusive change needing proper testing. Guess that's also experience 🤷😜

#POSIX #C #programming

So, you want to launch some external tool. Ok, fork()/exec() is simple enough.

But you don't want to "care" for it (wait()) if it's running longer. Ok, just fork some intermediate child, init will adopt it when this child exits.

But wait ... you do want to know if execution itself fails ... or if the tool exits "somewhat quickly" with an error. Okay, this will be interesting ...

Seriously, I'm quite unsure whether this code here is correct. But it's surprisingly large for that "simple" job.
https://github.com/Zirias/xmoji/blob/master/src/bin/xmoji/xdgopen.c#L56

I like concise documentation 😏

#Linux #manpages

(Medien: 1)

Finally fixed the annoying little build system bug in #Xmoji. Now, the internal libdir is always appended to LDFLAGS (non-overridable).

Just for fun, I once wanted to see how the build log grew 🙈 ... #XRandr #panning made it easy to get a screenshot 😁

#X11 #emoji #keyboard #development

(Medien: 1)

Call for testing... #Xmoji 0.9 to be released soon!

The major thing still missing from my roadmap to V1.0 is the tray icon, but I think it makes sense to have yet another 0.x release first.

0.9 will bring you a single instance mode (on by default, but can be turned off). This is expected to be especially useful if you have some key binding to launch Xmoji. If it's already running, you'll just get the running instance on top of your current (virtual) desktop!

I also modified my code handling the configuration file to prefer "async" operation (simulated using a thread pool), so it should never stall the GUI. This is a pretty intrusive change, therefore it should be tested for a while before releasing. That's where you can easily help, build/install it from github and if you find something, please open an issue, thank you 🤩:
https://github.com/Zirias/xmoji/issues

I'd also love to add more translations ... gentle hint:
https://github.com/Zirias/xmoji/blob/master/TRANSLATE.md

All in all, this is really a fun project for me, I very much enjoy doing it in #C. I keep learning new things, and at the same time, really understanding the logic of your own code down to the #POSIX API and/or #X11 protocol layer often gives opportunities to come up with the best solutions for a certain problem.

Here's my "development environment" btw: xterm, tmux, zsh, git, vim. 😏

#X11 #emoji #keyboard #development

(Medien: 1)

Having my $HOME on #NFS, I'm sometimes annoyed by lots of applications "freezing" when there's some issue with the NFS server. I just decided I'll try to prevent this in #Xmoji.

Now, how to do that? Nonblocking mode (which I use for sockets etc) doesn't do anything for regular files, they're always "ready to read/write". Still, actually reading or writing might block your thread. Then there's #POSIX #aio. From what I found, this has issues in real implementations, e.g. #FreeBSD uses kernel workers for implementing it, which are limited, and also doesn't even allow it on NFS by default, because it could cause deadlocks. Looking at the #Linux side, there seems to be some platform-specific async I/O implementation in the kernel, but #glibc implements the POSIX aio entirely in userspace... 🤯

Ok, screw all that. I'll do the simple thing and use worker #threads for file I/O calls, should be somewhat easy as I already have a "threadpool" in #poser. I just started doing that in my "filewatcher" in case it needs to use stat():
https://github.com/Zirias/xmoji/commit/8ba637c482e82791c9e20db21ce95a3e854b6f86

More to follow ... 😉

#C #development #async