This is now kind of a dev microblog concerning #Xmoji. I'm kind of stalled, now that version 0.7 seems reasonably stable and portable (I see there's a #nix pkg, unfortunately outdated, and a #NetBSD #pkgsrc port, I will deliver #FreeBSD *soon*).

It misses a few convenience features my previous #qXmoji had: save/restore the window size, optionally enforce a single instance, offer a #tray icon. I'll add all of that, seems straight-forward, for the tray icon I'll only implement the old #X11 spec based on #Xembed and if some desktop environment insists on only supporting the newer standard based on #dbus, well, screw that. Too much complexity, sorry.

The real issue is #localization (#l10n), specifically "just" translations. I still have no good concept for that. With #Qt, it was a no-brainer to also use Qt's mechanism. Without a toolkit, obvious choices would be either #POSIX message catalogs, or #GNU #gettext. The latter is much more convenient, but pulls in extra deps (with #GPL/#LGPL foo). Both have in common that they only operate on char* ... 8bit encodings. I have many of my texts stored as char32_t (#Unicode UCS-4 or #UTF32, difference doesn't matter much here). I could redesign that to base everything on #UTF8, but I'm a bit reluctant ... why add more runtime conversions?

I seriously think about coming up with my own tooling. But then, how far should I jump? Should I really try to parse my own source (using LLVM's #libclang for example)? Or should I hardcode tables with identifiers for all translatable texts?

I'll sleep on that a few more nights I guess....

#X11 #emoji #keyboard

#xcb #development thoughts:

One of the features I'd like to add to #Xmoji is a "system #tray icon". I know these aren't "en vogue" any more, but I like the concept a lot for an application you'll typically leave running and only use from time to time, which is likely a usage pattern for an "#emoji #keyboard".

So, I found a spec based on #XEMBED, X selections and client messages (therefore, pure X inter-client communication), I think I can implement that! 👍
https://specifications.freedesktop.org/systemtray-spec/0.2/

Digging deeper, I found there's a successor called #SNI and the spec above is considered "legacy" (after only 20 years, hehe) 🤨. SNI is based on #dbus. Oh damn ... it's not that I particularly hate dbus, it probably makes a lot of sense for complex desktop environments, but I really want to keep #Xmoji "plain #X11". I'll just use the old spec. At least I found #KDE seems to have a compatibility service: xembed-sni-proxy. No idea about Gnome. But then, screw it.

System Tray Protocol Specification

1 Overview # The system tray is an application running on a given X screen that can display small icons provided by running applications. Windows XP calls this feature the notification area. [1] Inspired by KDE, this specification uses the term system tray. From a UI standpoint, the system tray is n…

@atoponce @sotolf I think you get used to lisp, the language works just different to other languages, after a time it's not as bad.
What usually bothers me is Emacs being single threaded quite often or using outdated technologies such as #xembed which is now used to embedded #webkit.
The most annoying issue thou is #GTK doing funny stuff.
Like for example if you loose your display manager connection on #Wayland then GTK just kills your application with _exit().