On Tue, 23 Jun 2020 at 14:48, <phillb...@cock.li> wrote: > I am writing a wm for myself and I have a question about how dwm (and > a lot of other WMs that copies dwm, such as katriawm and berry) hides > clients. > > dwm manage() a client when it receives a MapRequest event and unmanage() > it when it receives both a UnmapNotify or a DestroyNotify event, while > hide clients by moving it to WIDTH(c) * -2.
Moving windows off-/on-screen is usually faster for quick view manipulation than unmap/map. It doesn't offer an opportunity for mouse pointer triggered focus/configure events either (I have observed such in the older days as well with pointer warping in areas of unmapped windows). All those reasons might have been bugs in the X server or of some X clients at the time. But I would argue that unmap/map remains slower than moving an unwanted window off-/onscreen. > Well, a window unmapped by a client can be mapped again later until it > be destroyed, so dwm can end up manage()ing a client twice if this > client chooses to unmap and then map again one of its windows. If a client unmaps a window, it has reason to do so and dwm will unmanage such a window, even if it's offscreen (aka not in the current view). > Why doesn't dwm hide windows by unmapping them, ignore UnmapNotify > events, and only manage() a client after a MapRequest event if this > client was not found by wintoclient()? > > I think that hiding a window by unmaping it is a way more obvious > approach than moving it to a invisible place. Is there any reason why > dwm hides windows like that? See above, there were reasons at the time. They might not be valid anymore today, but I think the strategy chosen has had no adverse effects even today. IMO the next evolutionary step of dwm will be considering to migrate to wayland at some point. X has always been a nightmare. Best regards, Anselm
