#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...

Getting closer: I now have a Pixmap class (to hold and render bitmap data, loading it from #PNG using #libpng), an ImageLabel widget to display a pixmap, and the first working "real" (using #EWMH) dialog window! ๐Ÿฅณ (of course, for testing, an "about box" ๐Ÿ™ˆ)

libpng was surprisingly easy. Getting bitmap data with an alpha channel in some #X11 pixmap was surprisingly hard ๐Ÿง. It seems just uploading it with #xcb (xcb_image_put) converts the alpha channel to a single bit, making the corners look super ugly ๐Ÿคจ.

So now, I separate out the alpha channel to upload it to a separate pixmap and then combine that with the rgb-pixmap into an argb-pixmap that's finally used for rendering, here's the whole dance:
https://github.com/Zirias/xmoji/blob/b7216b5f134985d9daa3f6b6da8315e9b6739440/src/bin/xmoji/pixmap.c#L68
I *could* save one rendering request by keeping those two pixmaps and render with a mask each time, but didn't because it will consume more server-side memory...

#X11 and #XRender experts: Do I miss anything, is there a saner way? ๐Ÿค”

xmoji/src/bin/xmoji/pixmap.c at b7216b5f134985d9daa3f6b6da8315e9b6739440 ยท Zirias/xmoji

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

GitHub

It has come to my attention that many people are under the impression that your window manager, desktop environment, and operating system installation are all closely interlinked so that the only practical way of switching one of these is to re-install.

This is not the case.

A desktop environment is a set of applications that use a particular set of libraries to achieve a more or less unified look-and-feel. One of those applications is usually a window manager.

Window managers are largely interchangeable with each other thanks to the invention of Extended Window Manager Hints about 20 years ago.

The only partial truth of this impression of unity is that installing and running more desktop environments and more window managers will incur a larger cost in disk space (to store them) and RAM (when loading multiple libraries). Back when a nice desktop machine had 128MB of RAM and a 2 GB disk, that could be concerning.

A Raspberry Pi now comes with up to 8GB of RAM (64x more) and a 128GB microSD card or a 1 TB SSD. Space is no longer a concern on that scale.

Go forth and experiment. Install multiple desktops simultaneously, choose between them when you start your X11 session, and figure out what you like.

#linux #bsd #X11 #gnome #xfce #kde #lxde #fvwm #i3wm #ewmh

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 #x11 #emoji #keyboard

Add second method to hide in taskbar ยท Zirias/qxmoji@2a404cd

Setting the _NET_WM_WINDOW_TYPE_UTILITY window type (which is directly supported by Qt) works in KDE, but not in some other window managers, so also keep the method to toggle _NET_WM_STATE_SKIP_TAS...

GitHub

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? ๐Ÿ˜–โ“

#qxmoji #emoji #keyboard

So it appears to me that under #wayland, #portals are the reimplementation of the #ewmh spec under #xorg. The sad thing here is Iโ€™m not observing any oversight and governance to these protocols.

When I last mentioned this about mini icon support, that discussion went south very quickly. Without proper governance, as there was with the EWMH, such discussions become a free-for-all with people giving their opinion about something they donโ€™t understand.

Given that #wayland comes from former #xorg devs who probably know about EWMH, Iโ€™d expect better. This lack of governance is appalling and needs to change. #portals need better governance than random ignorant people proposing extensions.

@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.)

@claudiom @prahou Can't remember if I ever tried to get #MLVWM running in X11 under NetBSD on my LC III back in the day, but definitely used it under X11.app/XQuartz.app under Mac OS X.

Once I started using #OpenBSD on workstations, I continued the trend, and started my effort to track down Takashi Hasegawa. I was ultimately successful and got his blessing to become maintainer (not necessary, but out of respect.) I've only made minor updates so far, but plan on implementing #EWMH support next.