One of the often repeated claims is that you need #Wayland to support multiple monitors with different #DPI and have correct #scaling, because there's no way in #X11 to do it.

Well, that's always been a myth. Now there's some nice blog post demonstrating that with actual code:

https://flak.tedunangst.com/post/forbidden-secrets-of-ancient-X11-scaling-technology-revealed

Yes it requires an extension, #XRandR, but that's been a "standard" extension in #Xorg for a LONG time. It's exactly what I'm still planning to also support in #Xmoji, as soon as I find the time.

forbidden secrets of ancient X11 scaling technology revealed

@feld @pertho Doesn't feel like something I'd like to try though. It would be pretty much #FreeBSD-specific, but worse than that, you shouldn't rely on dtrace availability, as it's an optionally loadable profiling tool (so, it would also be a "misuse" regarding purpose). Related to that, I'm pretty sure it requires superuser privileges for everything, which would be another issue for some general-purpose application software.

No, the "canonical" solution for filesystem watching on a BSD system is indeed #kqueue. And unfortunately, it does fall short a bit compared to #Linux' #inotify. For my #xmoji tool, I wanted notifications about any change on the runtime configuration file, and additionally to the pure #POSIX solution of periodically calling stat() (which is stupid, but still works for a single file), I implemented backends for both inotify and kqueue. For just a single file, kqueue's requirement of having an open file descriptor is just a minor annoyance, but you can deal with that. Note it's not as simple as it sounds in any case, e.g. when the file is deleted, you want to watch the directory of course, so you learn when it's re-created ... which with kqueue requires opendir() 🙈 ... still doable. But for scenarios where you want to watch a whole tree with potentially lots of files and directories, this is really bad and #inotify really shines.

@peppe To be clear about that, I don't question the fact that #X11 is full of old cruft that's mostly useless nowadays. It became more than clear to me while implementing my #xmoji tool, which uses almost exclusively #XRender requests for rendering (an *extension* to X11, not part of the core protocol), because X core drawing requests are really designed for 1990es hardware, supporting color palettes with limited entries, but no alpha channel whatsoever. Similar goes for font support in the X11 core protocol, it's useless supporting only bitmap fonts with no antialiasing etc, so I use client-side rasterizing (with freetype) and XRender only for compositing the result. There are more silly examples, like the "Compound Text" encoding monstrosity, because the core design predates Unicode, and so on....

In a nutshell, a major rework of what the X core protocol supports would be necessary.

But then, you can *still* dislike a suggested solution. I think #wayland is taking the "simplicity" much too far, so now both compositors and clients (rendering windows) have to do the same stuff over and over again. It's a pointless exercise trying to create a wayland client without huge libraries (such as e.g. cairo for client-side rendering, better yet use a full-blown toolkit like Qt or GTK that already makes use of cairo), while this is perfectly possible for X.

Ok, first reaction (confirming my suspicion that #glamor causes the bug) was super quick, I'm impressed! Let's see whether anyone jumps in soon to actually analyze the root cause. 😎

JFTR, it's the bug I already probe for in #xmoji to enable a silly workaround when necessary, applying a transformation to the source picture.

#X11 #Xorg #XRender #development

Well, I really like #X11 (#Xorg) ... and my son loves #PeppaPig. Which gives me a stupid idea. I could write something called #Xchicken. Make some chicken lay some eggs with mouse clicks on some #XRender surface.

Rough roadmap:
- Draw some chicken and eggs, probably as SVG?
- Reuse code from #Xmoji, add special widget supporting some "layered canvas"
- Implement game logic
- Add sound? (Hm, gotta look into #OSS and maybe #sndio, cause #FreeBSD ... #Linux weirdness maybe later)
- ....?

I'll probably never start though 🙈

I want to finally resume work on #Xmoji. Starting with a bit of house-keeping, I factored out a function probing for a weird #XRender (presumably only with #glamor) bug, so it doesn't distract from the normal X client startup, and took the opportunity to also document it:

https://github.com/Zirias/xmoji/blob/7d617cd74813590c08182bf963c622d219842b17/src/bin/xmoji/x11adapter.c#L623

If anything is really wrong with #X11 or #XOrg, it's bugs like this 😔 ...

xmoji/src/bin/xmoji/x11adapter.c at 7d617cd74813590c08182bf963c622d219842b17 · Zirias/xmoji

Plain X11 emoji keyboard. Contribute to Zirias/xmoji development by creating an account on GitHub.

GitHub

@gdr Hoping to encourage packagers, I just added a bit more documentation about building #Xmoji 😉

https://github.com/Zirias/xmoji/commit/fb67444a47c17e893f213f84eb014bd71f3410f4

#X11 #emoji #keyboard

README.md: Improve build documentation · Zirias/xmoji@fb67444

Add sub-sections explaining generic build configuration of zimk and considerations for packaging Xmoji.

GitHub

@gdr So you're looking for some #emoji picker to work with #X11? Allow me to suggest my own pet project, #Xmoji!

https://github.com/Zirias/xmoji

X11-only, minimal (IMHO) dependencies, no "toolkit" and plain C implementation. It doesn't need to call any external tools like x11-emoji-picker does. I also intend to resume work on it, a few features are still missing.

In case you like it, I'd appreciate contributions, like for example new translation files, or some package builds (currently only #FreeBSD, #NetBSD and #NixOS exist).

GitHub - Zirias/xmoji: Plain X11 emoji keyboard

Plain X11 emoji keyboard. Contribute to Zirias/xmoji development by creating an account on GitHub.

GitHub

Minor news about #Xmoji: It's now featured on LinuxLinks.com 🍻
https://www.linuxlinks.com/xmoji-plain-x11-emoji-keyboard/

On their comparison of #emoji pickers for #Linux, it ranks 4th: https://www.linuxlinks.com/best-free-open-source-gui-emoji-pickers/

My goal with Xmoji is to create the "best" emoji keyboard for plain #X11. Given the scope of this comparison (Linux, any GUI which of course includes #wayland ... 🙈), I'd claim I'm pretty much "on track" here. 😎 It certainly can't rank first, because:

- It's X11 only (by design!)
- There's not a single #package for any major Linux distribution.

Maybe you could help to "fix" the "package issue"? 👋😇 Packages currently exist for #FreeBSD and #NetBSD.

Xmoji - plain X11 emoji keyboard - LinuxLinks

Xmoji is a simple emoji keyboard for X11 designed to work without relying on any toolkit or input method. It's written in C.

LinuxLinks
I'm a #software #developer and #architect. I'm not a #business #analyst, #project manager, or whatever.

Well, with my own pet #opensource project getting some exposure because some people like to use it, I see I need to accept all the roles 😅. Here trying to do some "requirements engineering" for #Xmoji: https://github.com/Zirias/xmoji/issues/18
Keyboard-centric input mode · Issue #18 · Zirias/xmoji

I have a keybind set up to launch Xmoji with a hotkey. It would be nice if Xmoji would automatically focus on the search bar when it launches, rather than the "history" tab, so I can just hit my ho...

GitHub