I finally did it and moved to a more appropriate "home realm" for a #FreeBSD enthusiast. Thanks @stefano for offering this!
Moving followers worked flawlessly, restoring all my settings was pretty quick, but of course all my old toots are left on https://techhub.social/@zirias 🙈
So I guess I'll introduce myself here by writing a little thread, adding a few of my works that someone might find interesting. But first a bit of "who am I":
I'm a "professional" software architect/developer (mostly #dotnet platform in the day job), FreeBSD hobby-admin and ports committer, #C64 fan (and occassionally coder and even musician), and apart from computers also interested in music (playing a few instruments myself), traveling, cooking, sometimes sports, sometimes politics ... but probably won't toot about any non-technical stuff (or, very very rarely).
Let's start with my most recent opensource dev-project:
#qXmoji is an #X11#emoji#keyboard. Although it uses #Qt for its GUI, the mechanism to "type" emojis is pure X11. This means any X11 client can receive them (whether that client can correctly display them is an entirely different issue 🙈) ... not even #XIM awarenesss is needed.
The mechanism to inject fake "emoji keyboard events" is quite hacky and dirty, but it works!
Can now select 5 "scale factors" for the size of the emojis, "Tiny" being the same size as default window text (which is normally indeed tiny for emojis)
Auto-stores these settings as well as the window dimensions (not position!)
Functionally the same (just clickable emojis in tabbed groups, display size and wait-time for restoring the X11 keyboard map configurable), but v0.2 has correct README info and build-fixes, so Qt tools are found without fiddling with make variables 🙈 so, use v0.2 😎
Thinking about what to include in #qxmoji v0.5. Many questions in mind...
I'll definitely "outscope" #l10n. Would be nice, but would also mean to import localized emoji names somehow (and, where to find them? 🤔)
For now:
🔹Unify persisting settings. history and window size are persisted on exit, wait time and display scale on every change. Not sure which one is the "better" approach...
🔹Should it be "single instance"? Should it offer an option for a "tray icon"?
🔹Add an "About dialog". Cause that's what you always do. 🙈
🔹Maybe find a way to speed up initial creation of the Emoji buttons?
🔹Anything else ...❓
🔹Add a "single instance" mode (configurable)
🔹Add a "tray icon" (configurable behavior)
🔹Add an "About" dialog
🔹Enforce using Qt's "xcb" platform
🔹Fix detaching on startup, add a flag (-d) to prevent it
Pretty usable as it is I hope ... although one could of course improve a lot (but have you heard of the 80-20-rule?) 🫣
Screenshot from #KDE this time, no particular reason, I'm still running #fvwm here 😎
This brings a lot of improvements and fixes, the most relevant being immediate persistence of settings and watching the settings file for external changes. To make this feasible also for restoring the history, a lot of work went into generating static emoji data that can be used efficiently (e.g. containing a hash table to find an emoji quickly).
BTW, this even works on #NFS, so if you have your home shared and you're running qXmoji on two machines as the same user, the history will auto-update in both instances 🥳
This brings several improvements, mainly in the build system, but the major change is support for localization, with translated Emoji names imported from #Unicode#CLDR. I added a German translation, see screenshot. Once again, I'd appreciate more translations, the process to translate is documented here: https://github.com/Zirias/qxmoji/blob/master/TRANSLATE.md