🚦🚥 ... ok it works 🌋
A super-simple #emoji keyboard for #x11.
Well, I *did* have to fiddle with the keymap.
And I had to add delays 🤯👹 (otherwise there are races between keymap changes and keyboard events).
And I had to misuse the #Xtest extension, cause applications ignore "synthetic" events. 🫥😣
But hey, it works 🕺
Now needs some basic, uhm, "features" (like recently used, like search by name).
Fixed build with #Qt6 now (and defaulting to that, but #Qt5 still supported).
I also added a README.md explaining the uglyness of what it does with #X11 / #xcb. But again, hey, it works 🙈🍄🐸🦉 (lots of emojis for no purpose, sorry 😂)
The looks with completely unconfigured #Qt6 tell me it needs yet another feature: Configurable scale factor. These emojis are just TOO small 🧌
First "features" added ...
* 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!)
#qXmoji v0.1 and v0.2 released 😎
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 😎
🥳 #qXmoji v0.3 released 🍻🍕
Now there are the "basic" features you'd expect from an emoji keyboard:
✅ Search as you type
✅ Recently used
Found a small bug, #xcb requests were synchronously checked, but this only works when calling the _checked() flavor of them ... 🙈
Fixed in #qXmoji v0.4
Also added a clear button to the search field, this seems somewhat useful 😉
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 ...❓
Please comment if you have thoughts to share 🙃
#qXmoji v0.5 released!
https://github.com/Zirias/qxmoji/releases/tag/v0.5
This brings a *few* of the ideas I had:
🔹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 😎
#qXmoji v0.6 released!
https://github.com/Zirias/qxmoji/releases/tag/v0.6
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 🥳
#qXmoji v0.7 released!
https://github.com/Zirias/qxmoji/releases/tag/v0.7
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
Updated FreeBSD port:
https://people.freebsd.org/~zirias/patches/0001-x11-qxmoji-Add-new-port.patch
The obligatory post-release-🤦-commit:
https://github.com/Zirias/qxmoji/commit/80f9d807837f774414fa5a26cc4dfad22499a2c1
Is there a tool checking for these? Pointless/leftover includes in #C and C++?
I have one little piece of custom platform-specific code in #qXmoji.
Background is that #Qt's QFileSystemWatcher doesn't work correctly on #NFS (and probably other network filesystems). It uses some platform mechanism (e.g. inotify on #Linux, kqueue on #FreeBSD) internally, so exact behavior probably depends on the platform. On FreeBSD, it *seemed* to work, but only when the change to the file on NFS is done from the local machine. 🙄
Now regarding this code:
https://github.com/Zirias/qxmoji/blob/master/src/bin/qxmoji/nfsdetect.c
-- I still have doubts.
▪ Should it check for other filesystems as well? Which ones?
▪ Will this construct checking for 'BSD4_4' in <sys/param.h> reliably detect every OS derived from 4.4BSD (assuming a POSIXy system that *has* sys/param.h)?
▪ Should it have implementations for *other* POSIXy systems than 4.4BSD-descendants and Linux?
▪ Why the hell is there no standard for checking the *filesystem* a file resides on? 🧐😁
▪ Why the hell is there no standard for checking the filesystem a file resides on? 🧐😁
Wow, I'd always assumed statfs was POSIX, but apparently not. I hadn't realised how anaemic the Linux version is either. It omits almost all of the useful information (such as the mount point).
In general, filesystem monitor things on network shares tend to be unreliable because they'd need the server to notify the client of writes, which is hard to scale. Apple's fswatch interface is particularly well designed to avoid ever blocking writes: if you don't keep up with consuming the firehose in userspace then you just get a notification that some writes have happened and you should go and check the modification times of files in the directories that you're watching. I believe it includes the timestamp of the first write that you missed, so you can just look for modifications newer than that.
It's possible to imagine a networked version of this but it would be very hard to implement. Consider an NFS server with 1,000 clients. Each client is doing writes and is also watching a load of files. One write may trigger monitoring events for all 1,000 clients. That's a lot of state to keep around. I don't think any network filesystem has a protocol for doing this (please point to it if I'm wrong, I'd love to see a protocol actually designed to do this!) and so, at best, you have to fall back to periodically polling the mtimes.
I believe the AFS / CODA caching protocol could be fudged to do this if you told the server that you had a local cache of all of the blocks in all of the files that you're watching.
> at best, you have to fall back to periodically polling the mtimes.
which is exactly what I'm using this code for now ... if it tells me the file resides on NFS, I disable the QFileSystemWatcher and use a simple QTimer checking the mtime 😉
@zirias libfswatch has a poll mode that does this for you and hides the details of exactly what it's doing.
The thing I really want that none of the low-level APIs I've seen exposes, is a notification when the last file descriptor with write permission to a file is closed. Most of the use cases I have for this kind of monitoring are telling me when a file has changed not that a file is changing. Instead the kernel wants to tell me that a write just happened, but ignores the fact that the same file descriptor will be used for a bunch of other writes.
Felix Palmen 📯
David Chisnall (*Now with 50% more sarcasm!*)