On Tue, 23 Jun 2020 at 14:48, <phillbush_AT_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
Received on Wed Jun 24 2020 - 00:32:23 CEST