Chris's Wiki :: blog/unix/XIconificationManyWays Commentshttps://utcc.utoronto.ca/~cks/space/blog/unix/XIconificationManyWays?atomcommentsDWiki2023-02-02T15:08:38ZRecent comments in Chris's Wiki :: blog/unix/XIconificationManyWays.From 125.235.62.241 on /blog/unix/XIconificationManyWaystag:CSpace:blog/unix/XIconificationManyWays:ebbf378c877a0aa47271292d314bdb5fa3ee89a7From 125.235.62.241<div class="wikitext"><p>The X11 bug is very likely caused by <a href="https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/126">https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/126</a> which enables Xlib thread-safe mode by default. This could cause deadlocks with some programs that aren't compatible with Xlib thread-safe mode (e.g. calling Xlib functions inside an Xlib callback). <a href="https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/176">https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/176</a> tries to mitigate some of the incompatibilities and should be in Xlib 1.8.4 but the only way to eliminate all compatibility issues is to rebuild Xlib with the `--disable-thread-safety-constructor` configure flag.</p>
</div>2023-02-02T15:08:38ZBy Thomas Adam on /blog/unix/XIconificationManyWaystag:CSpace:blog/unix/XIconificationManyWays:2306a1c2f13ad1bc621942ff0662e0756a38195eThomas Adam<div class="wikitext"><p>It's worth mentioning that the X11 bug with iconified windows causing the XServer to crash shouldn't be conflated with how the ICCCM2 expects icons to work with window managers.</p>
<p>Fvwm is perhaps the only exemplar on how to handle iconified windows. There's several historical "hacks" in its iconification code to work around other proprietary XServer implementations, as well as optimisations in rendering iconified windows. Such as caching the pixmap used for the icon itself, the GraphicsContext its using (to avoid round-trips to talking to the XServer). Other things include unmapping transient windows first so that when you deiconify, the stacking order is preserved. Transient windows need interaction from the user, so having them in the same stacking order transitioning from an iconified state, keeps that correct.</p>
<p>There's two main parts to an iconified window -- the icon itself, and the icon title. They're separate windows but share the same XEvent hints so that the operation on the icon itself is the same no matter where you click on it.</p>
<p>I think you mentioned about rectangles around icons (which are actually <em>borders</em> in X11 parlance) -- it's not true that you won't see them when not using the SHAPE extension -- all SHAPE does is mask out the region of the window so that clicking close enough to it reaches the root window and not the icon itself.</p>
<p>There's other considerations as well -- in other WMs/DEs which treat iconification via a taskbar, there's no interim state that needs to be tracked in terms of the relationship between iconified window and parent window. If the icon moves between pages in fvwm, where does the parent get remapped when it leaves the iconified state? What about desks? Currently, fvwm has logic for all of this.</p>
<p>I should probably write all of this up in much more technical detail at some point.</p>
</div>2023-01-14T12:43:05ZBy Aristotle Pagaltzis on /blog/unix/XIconificationManyWaystag:CSpace:blog/unix/XIconificationManyWays:68471f5644db009289c7ed3f9ebc703bc26c8d02Aristotle Pagaltzishttp://plasmasturm.org/<div class="wikitext"><p>Had Matt not beaten me to it, I would have left roughly the same comment myself. But because he did, I did not, and instead waited for any response to it. While checking for that, I ended up following the link to Wikipedia’s taskbar article, and so I learned something I otherwise never might have:</p>
<p>To my surprise, Windows actually had a taskbar in 1.0. (Or something close to it anyway – a bar for iconfied program icons, but without the Start menu or tray.)</p>
<p>I had always assumed, as Matt apparently did, that Windows was born with iconification to the desktop, and only introduced the taskbar in Windows 95. Because that’s how I experienced it: the first version of Windows I encountered was 3.0, which is typical, because that was the first version to gain real traction.</p>
<p>I wouldn’t have guessed that Windows had a taskbar and lost it (by 2.0, according to <a href="https://www.howtogeek.com/733912/a-visual-history-of-windows-icons-from-windows-1-to-11/">a How-To Geek article</a>, which came out in 1987 – (co?)incidentally, just after X11) before going back to it in Win95. Looking back now, it actually only had iconification to the desktop during a 7-year period – albeit an important one.</p>
</div>2023-01-10T18:34:58ZBy Matt Boeh on /blog/unix/XIconificationManyWaystag:CSpace:blog/unix/XIconificationManyWays:053cc878b71f178133770fea6c844f91e6b9fb3cMatt Boehhttps://mboeh.com<div class="wikitext"><p>Minor correction: Windows didn't have a taskbar or a "desktop folder" until 95. Windows 3 displayed active programs on the desktop and used minimize-to-icon. Early Mac Systems didn't have minimize at all. By MacOS 9 it had "window shade" minimization. It wasn't until OS X that they adopted the Dock from NeXTSTEP.</p>
</div>2023-01-06T05:34:32Z