#X11 #programming #tales – the magic pager powers! 🤩

There's a general problem with windowing systems and desktop environments. You can do stuff with windows like, bring them to the front, activate them, move them to a different virtual desktop, and so on. That's nice until something bad happens like a user accidentally typing sensitive stuff into a wrong window ... or maybe just annoying the user.

So, windowing systems started to do things to prevent this. E.g. they just ignore something an application wants to do ... or replace it with something different (hey, this window wants to be activated, let's flash it in the taskbar instead).

But then, there are very valid usecases where e.g. bringing a window to the front is most likely exactly what the user wants. While implementing single-instance mode (which I plan to make optional of course!) in #Xmoji, I had such a usecase. So, the user only wants to have a single instance of that app running. Yet the user starts it again ... 🤔 the natural expectation would be that the already running instance appears on the screen as if it was newly started, which is, of course, on top ...

Well, enter #EWMH (which is used for communication with the window manager additionally to #ICCCM in all "modern" environments). They identified that pagers always have valid reasons to do anything to windows. So, they added a field to lots of requests, the "source identifier", which must be set to 1 if the request is issued by a "normal" application, and to 2 if it is issued by a pager. Window managers are required to always obey the pager.

Now for the magic trick: What if we just tell the window manager "hey, I'm a pager"? Oh, I love it! 😂 (sudo make me a sandwich style, just better).

Of course that's sarcasm. The initial problem just can't be solved that way. It can only be solved in individual applications, that just shouldn't do unexpected nonsense with their windows. 🙄

Side note: #Windows does it differently. An application on a windows desktop can only "self-activate" if the currently active application explicitly passes permission. That's a lot more boring (I can't just pretend something and make the desktop obey me 😞), but also doesn't solve the problem. While I could certainly cover my usecase in Xmoji that way (I mean, the new instance can pass that permission to the already running one), I'm sure there are lots of other valid usecases for e.g. activating a window that just can't be done on a Windows desktop...

Still reading #ICCCM, fixing stuff in my #xcb-based #X11 code ... this time, getting "window states" correct 😅
https://github.com/Zirias/xmoji/commit/d244b35d1fe53226c37833949312b6ea2a0412ec

This only makes sense in presence of an ICCCM-compliant window manager, which *should* be a given, but who knows? I now deduce this by whether I'm getting a WM_STATE property or not. When my window gets one, it's only considered "closed" once this is deleted (or, changed to "Withdrawn", which e.g. #fvwm3 is doing, but then I just delete it myself in response). Otherwise, the window is considered closed as soon as the UnmapNotify arrives. I hope this is a sane approach. 😎

Window: [ICCCM] Handle window state · Zirias/xmoji@d244b35

* Set WM_HINTS to desired initial state * Monitor WM_STATE * Send UnmapNotify to root when closing * When hide-mode is minimize, send CHANGE_STATE message on Widget_hide() * Notify X11App of window...

GitHub

#X11 has the concept of #Atoms for interned strings. For those not aware, this allows using numeric identifiers instead of the actual strings for commonly used names, e.g. for window properties, property types, etc.

But did you know why all the pre-defined ones (and many others specified in X-related specifications) are all uppercase?

Reading the #ICCCM, I learned it's for easy interaction with #LISP 😂

Try running `xlsatoms` in your X session, it seems many don't care about that any more (or maybe don't even know? 🙈)

@jhx Well then, #ICCCM compliance status of my #X11 #selections implementation: "I think so" 🙈

Only supports text content so far (without support for this weird/ancient COMPOUND_TEXT encoding, but I guess that's not strictly required?), but in theory extensible for other data formats. Almost 1000 lines of C source 🤪

https://github.com/Zirias/xmoji/blob/master/src/bin/xmoji/xselection.c

xmoji/src/bin/xmoji/xselection.c at master · Zirias/xmoji

Contribute to Zirias/xmoji development by creating an account on GitHub.

GitHub

@thomasadam Didn't expect #ICCCM #X11 selection handling to be *that* complex 🤯

I just finished implementing the MULTIPLE method, and have no idea how to ever test that 🫤 ... then still missing: Accepting INCR transfers (sending is done), and also no idea how to test (sending was easy, just pretend a very tiny maximum request size) …

Meanwhile >700 lines of C for handling these selections 😅

@jhx Yeah, really wonder what kind of bug *this* is. It's certainly a bug (of the weird kind, I mean, how do you manage that? Have every thread ask the same thing at once or what?). It doesn't *break* anything, so probably nobody cares, but it certainly wastes resources big time 😂

Meanwhile, I'll probably have to completely redesign my own "X11 selection" code. It works, but it's completely non-compliant, ignoring maximum request sizes, "alloc" errors from writing over-sized properties, INCR transfer method for transferring selections in chunks, etc ... #ICCCM is really a complex beast 🤯

@claudiom @prahou It's actually been very comforting and helpful that #OpenBSD's #FVWM is an older version (with the occasional bug fixes) from before the license changed, both because it's more similar to what #MLVWM was based on, plus is a compatible license if I ever decide I'd like to integrate some code from it. That said, the #EWMH (#NetWM) implementation will cause them to diverge a bit. (It's frustrating to advocate for #ICCCM adherence these days because many forget EWMH _extends_ it.)

Here is one think I would like to work on:

better protocol documentation (how we actually implement things!) and integration testing between many implementation.

There is enough bad blood between Fediverse participants already.

If the new implementation is coming I feel like we need to have Mastodon Inter-Client Conventions documented asap.

(Those who remember #X11 may recall #ICCCM - Inter-Client Communication Conventions Manual this is what I think we need)

#activepub #ostatus #mastodev