🚦🚥 ... 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 😎
Working on improving performance for the next #qXmoji release. This will require pre-generating stuff during build (different string formats and probably static hashtables), so doing this in #POSIX #shell script isn't feasible any more, therefore working on a data generation tool in #C now.
I'm amazed how #lldb shows me my #Emoji structs while debugging this 😂
It seems fighting #Qt for better #performance can be a lost cause 😞 ... after a LOT of refactoring (finally even generating QStringLiteral entries in my #emoji data tables), setting an emoji as text on nearly 4000 QLabel instances is still slow as hell -- but now, compiling the emoji data is horribly slow as well (QStringLiteral doing C++ template "magic" ...) 🙈
(And no, threading won't help here, Qt Widgets can't be used from worker threads ...)
At least I could speed up serializing/deserializing the emoji history. The new format is also surprisingly user-readable 😂
Oh boy #Qt can get *nasty* if you need something "unusual" (like, initialize 4000 Labels all on startup 🎶🤫).
So, I can't fix performance of this, but I can "defer" it with a hacky hidden class like this.
It uses #Qtimer for a 1ms pause between every single emoji, which was the *only* way I found to have Qt still process other events 🤯 ... prefers the currently visible tab for initialization ... and "commits suicide" when done.
I'm proud and ashamed at the same time 🥴
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 🙃
Deep down the #X11 (#xcb) rabbit hole now.
I decided to add a tray icon. I want it optional, with configurable behavior (minimize-to-tray, close-to-tray, no-tray).
Adding this thing was super simple with Qt. Getting anything other than the default behavior ... not so much. Doing lots of things with plain #xcb now.
I'm stuck at hiding the tool from a taskbar. #EWMH has _NET_WM_STATE_SKIP_TASKBAR. In #fvwm (#fvwm3), this works when setting it before the window gets mapped. Sending it as a "client message" when the window is already mapped seems to be just ignored 😠
I then tried #KDE (#kwin). Hm well, doesn't even honor the _NET_WM_STATE property set on the window before mapping it, IOW, it's *always* shown in the taskbar.
WTF? 😖❓
@thomasadam does #fvwm intentionally ignore a client-message attempting to set (or clear) _NET_WM_STATE_SKIP_TASKBAR?
In general, _NET_WM_STATE messages are processed (I checked by setting _NET_WM_STATE_MAXIMIZE_VERT instead, this works ...)
@zirias I’m not near my computer right now, but I believe so. I don’t think for nefarious reasons. If I recall correctly, there’s a comment in the code mentioning that it’s either deliberate or not yet implemented.
File a bug on GH for me. I’ll probably just fix it for you.
@thomasadam Maybe I should search for that comment myself ... if, after all, there *is* a good reason to ignore it ... 🤷♂️
Otherwise, I'll try to hack a minimal reproducer first (my Qt application probably won't qualify 😂)
@thomasadam Well, the comment tells something else 😂
https://github.com/fvwmorg/fvwm3/blob/main/fvwm/ewmh_events.c#L1199
maybe it isn't worth implementing after all if #fvwm3 would be the only wm doing so ... am I the first crazy guy contradicting this comment? 🤡
although I think my usecase makes some sense, I have a toggle for the "tray icon" and think as long as this icon is shown, taskbar is kind of redundant 🙈
@thomasadam Issue created:
https://github.com/fvwmorg/fvwm3/issues/1011
Let's see whether I can wrap my head around #fvwm3 inner workings to do this myself 😉
There's a stub here: https://github.com/fvwmorg/fvwm3/blob/main/fvwm/ewmh_events.c#L1199 Implementing this would allow changing taskbar visibility of a mapped window. Here's a simple tester program...
@thomasadam PR created to address this:
https://github.com/fvwmorg/fvwm3/pull/1012/files
Those are just a few lines of code. Still took me hours, because I did have a hard time to understand enough of #fvwm3's code (and, still unsure whether I did it correctly...) 🙈
Well, maybe this can help me if I ever want to add/fix another thing in fvwm3 😂
Handle client messages for modifying _NET_WM_STATE_SKIP_PAGER and _NET_WM_STATE_SKIP_TASKBAR on mapped windows: Update the window property and broadcast the change for modules. Both are mapped to t...
Guess I *did* enter "shady areas" writing commit messages like this:
https://github.com/Zirias/qxmoji/commit/2a404cd195619265559f9cced21f89ce3d129f40
In theory, all #EWMH window managers should behave the same, I thought ... 😂🙈
#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 😎
Working on improving performance for the next #qXmoji release. This will require pre-generating stuff during build (different string formats and probably static hashtables), so doing this in #POSIX #shell script isn't feasible any more, therefore working on a data generation tool in #C now.
I'm amazed how #lldb shows me my #Emoji structs while debugging this 😂
It seems fighting #Qt for better #performance can be a lost cause 😞 ... after a LOT of refactoring (finally even generating QStringLiteral entries in my #emoji data tables), setting an emoji as text on nearly 4000 QLabel instances is still slow as hell -- but now, compiling the emoji data is horribly slow as well (QStringLiteral doing C++ template "magic" ...) 🙈
(And no, threading won't help here, Qt Widgets can't be used from worker threads ...)
At least I could speed up serializing/deserializing the emoji history. The new format is also surprisingly user-readable 😂
Oh boy #Qt can get *nasty* if you need something "unusual" (like, initialize 4000 Labels all on startup 🎶🤫).
So, I can't fix performance of this, but I can "defer" it with a hacky hidden class like this.
It uses #Qtimer for a 1ms pause between every single emoji, which was the *only* way I found to have Qt still process other events 🤯 ... prefers the currently visible tab for initialization ... and "commits suicide" when done.
I'm proud and ashamed at the same time 🥴
#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 🥳
In case you wondered: Why another #emoji input tool?
As far as I know, #qXmoji is the *only* one working with "pure" #X11, acting like a virtual #keyboard. It *does* need the "Xtest" extension to fake "real" key presses, but that's (almost?) always available. It does *not* need other X clients to use some specific GUI toolkit (Qt, GTK, ...) or be at least XIM (input-method) aware. Instead, ANY X client works as the target – whether it can properly display emojis is another topic of course. 🤡
So, that's why. Well, I found the "x11-emoji-picker" project, but this one relies on some external tool to inject the events, so it's not self-contained and less robust. Do you know of any other similar projects? Then let me know 😎
Who said X11 was dead? It's a lie! 🐸
I now added a screenshot of #qXmoji on github. People need to see screenshots for some reason (I'm no exception) 😄
I wanted "default looks", so, disabled any #Qt theming and thought #fvwm3 with default config should be a very nice match for a tool targeting "plain #X11", and firing up a #Xephyr session, I was quite surprised how polished fvwm3's default config looks nowadays, even integrating #stalonetray when available 👍
I still prefer my custom config, but nevertheless, great job 🙂
Working on the next thing for #qXmoji: #l10n.
First step: Build a hash-table for localized emoji names from Unicode CLDR data.
Use the hashtable to map translations to emojis and auto-generate #Qt #Linguist translation files containing both texts -> done.
I just *had* to check: No, there isn't a catchy german translation for "facepalming" 🙄
Got a vertical prototype working, the tooltips in the "normal" emoji tabs are translated 🥳
🍺o'clock, later ... 🍻
#qXmoji is now completely translatable, and fully localized for 🇩🇪.
So, here comes a request for contributions 😁 (pretty please 🙃):
More languages would be nice! Therefore I documented the process to add them here:
https://github.com/Zirias/qxmoji/blob/master/TRANSLATE.md
If there are no takers, I might be seduced to add #French myself.
TBH, this is kind of a threat to all french-speaking ppl. It's the only language I ever learned besides German and English, and school is a *very* long time ago. It will probably end up somewhat similar to your typical chinese user's manual 😂
Ok, I couldn't resist any more. Here's #French #qXmoji. Or, something like that ...? 🙈
Dear native-speakers, if I messed up TOO badly, help me out and send patches / pull requests 🤣🍻
(edit: ah great, I directly spot the first typo in this screenshot ... gonna fix immediately. Still, the hardest thing is to express technical things in french, I guess that counts as "domain specific language" and I really have NO idea how to do it)
#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 📯
jhx
Thomas Adam
David Chisnall (*Now with 50% more sarcasm!*)