#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...
Only slightly related: #fvwm gave me another thing to consider with its "pages" that aren't virtual desktops (which fvwm can also handle), but an automatically managed larger viewport instead. I just added a commit implementing "bring to the current fvwm page", by looking at the window's position and comparing that to the size of the screen ๐ค ...
https://github.com/Zirias/xmoji/commit/a3a041af7d41f901b8e795ccb93e8380f03da873
(@[email protected] does that look somewhat sane to you?)
Overall lots of stuff to do (some of that using the magical pager forces ๐) when a secondary instance is started:
puh ... ๐
@zirias Yes, I think so. The key thing here, as you've noted is to calculate the offset of the page based on the screen.
In your commit, you've used:
while (x < 0) ...
while (y < 0) ...
It's probably unnecessary to do that, but it won't hurt in practice.
See, for example, the implementation in FindScreenOfXY(): https://github.com/fvwmorg/fvwm3/blob/main/libs/FScreen.c#L801
Which is essentially doing the same thing.
Everything else outside of this check is just noise.
@[email protected] well, these loops were necessary in my logic because I missed doing the obvious modulo ... ๐คฆwill fix tomorrow. Thanks for having a look!
Yes, the loops are gone, so this now wastes fewer CPU cycles ๐
https://github.com/Zirias/xmoji/commit/a010d073bdab27a7a8b5b78b71c3b6b8be39406d