lingo.lol is one of the many independent Mastodon servers you can use to participate in the fediverse.
A place for linguists, philologists, and other lovers of languages.

Server stats:

69
active users

#icccm

0 posts0 participants0 posts today
zirias (on snac)<a href="https://snac.bsd.cafe?t=x11" class="mention hashtag" rel="nofollow noopener" target="_blank">#X11</a> <a href="https://snac.bsd.cafe?t=programming" class="mention hashtag" rel="nofollow noopener" target="_blank">#programming</a> <a href="https://snac.bsd.cafe?t=tales" class="mention hashtag" rel="nofollow noopener" target="_blank">#tales</a> – the <i>magic pager powers!</i> 🤩<br><br>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.<br><br>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).<br><br>But then, there are very valid usecases where e.g. bringing a window to the front is most likely <b>exactly what the user wants</b>. While implementing single-instance mode (which I plan to make optional of course!) in <a href="https://snac.bsd.cafe?t=xmoji" class="mention hashtag" rel="nofollow noopener" target="_blank">#Xmoji</a>, 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 <i>as if it was newly started</i>, which is, of course, on top ...<br><br>Well, enter <a href="https://snac.bsd.cafe?t=ewmh" class="mention hashtag" rel="nofollow noopener" target="_blank">#EWMH</a> (which is used for communication with the window manager additionally to <a href="https://snac.bsd.cafe?t=icccm" class="mention hashtag" rel="nofollow noopener" target="_blank">#ICCCM</a> in all "modern" environments). They identified that <b>pagers</b> 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 <code>1</code> if the request is issued by a "normal" application, and to <code>2</code> if it is issued by a pager. Window managers are required to <b>always obey the pager</b>.<br><br>Now for the magic trick: What if we just tell the window manager "hey, I'm a pager"? Oh, I <b>love it</b>! 😂 (<i>sudo make me a sandwich</i> style, just better).<br><br>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. 🙄<br><br>Side note: <a href="https://snac.bsd.cafe?t=windows" class="mention hashtag" rel="nofollow noopener" target="_blank">#Windows</a> 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...<br>
Felix Palmen :freebsd: :c64:<p>Still reading <a href="https://mastodon.bsd.cafe/tags/ICCCM" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ICCCM</span></a>, fixing stuff in my <a href="https://mastodon.bsd.cafe/tags/xcb" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>xcb</span></a>-based <a href="https://mastodon.bsd.cafe/tags/X11" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>X11</span></a> code ... this time, getting "window states" correct 😅<br><a href="https://github.com/Zirias/xmoji/commit/d244b35d1fe53226c37833949312b6ea2a0412ec" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/Zirias/xmoji/commit</span><span class="invisible">/d244b35d1fe53226c37833949312b6ea2a0412ec</span></a></p><p>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. <a href="https://mastodon.bsd.cafe/tags/fvwm3" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>fvwm3</span></a> 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. 😎</p>
Felix Palmen :freebsd: :c64:<p><a href="https://mastodon.bsd.cafe/tags/X11" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>X11</span></a> has the concept of <a href="https://mastodon.bsd.cafe/tags/Atoms" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Atoms</span></a> 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.</p><p>But did you know why all the pre-defined ones (and many others specified in X-related specifications) are all uppercase?</p><p>Reading the <a href="https://mastodon.bsd.cafe/tags/ICCCM" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ICCCM</span></a>, I learned it's for easy interaction with <a href="https://mastodon.bsd.cafe/tags/LISP" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LISP</span></a> 😂</p><p>Try running `xlsatoms` in your X session, it seems many don't care about that any more (or maybe don't even know? 🙈)</p>