Re: [dev] [dwm] mapping wm state, and other stories

From: Anselm R Garbe <garbeam_AT_gmail.com>
Date: Tue, 1 Nov 2011 12:11:00 +0100

On 1 November 2011 11:59, Connor Lane Smith <cls_AT_lubutu.com> wrote:
> I noticed dwm has a bug handling _NET_WM_STATE_FULLSCREEN when a
> window is mapped. The EWMH spec says, "The Window Manager SHOULD honor
> _NET_WM_STATE whenever a withdrawn window requests to be mapped. A
> Client wishing to change the state of a window MUST send a
> _NET_WM_STATE client message to the root window." dwm honours
> _NET_WM_STATE_FULLSCREEN client messages in clientmessage(), but
> ignores the property in manage(). We ought to refactor fullscreen
> toggling into a new function and check for the property when the
> window is mapped.

Agreed.

> It would also be nice if dwm supported _NET_WM_WINDOW_TYPE hints as
> well, so we can make _NET_WM_WINDOW_TYPE_DIALOG windows float. (We
> could steal the updatewindowtype() function from Christoph Lohmann's
> dock patch.)

Agreed.

> I sometimes wonder whether it would be simpler to just make
> _NET_WM_STATE_FULLSCREEN switch dwm into monocle mode. Forcing one
> window to be at the front very often leads me to accidentally focus
> and interact with window hidden behind it. Which is why I think
> floating windows ought to be able to be behind tiled windows, too.

I disagree, setting a particular layout implicitly because some random
window says it is in fullscreen state is not a great idea imho.

Also I would say that accidentally focussing windows that are behind
the fullscreen window is a user interaction bug. If that's really an
issue others also have (I rarely had this issue) we could consider
preventing key bindings or mouse actions that toggle the focus through
checking selmon->sel->isfullscreen or somtheing similar.

> I also think we could make floating windows smarter by letting you
> cycle through any floating windows visible on the same monitor, using
> selmon to root us to a single monitor rather than straying off because
> the window "belongs" to another monitor. This would require a single
> client stack instead of one per monitor, like I've talked about
> before. We could also make a floating window's canonical monitor
> dependent on area of intersection, like in dmenu tip. Just throwing
> that out there.

I don't understand this. Cycling through any kind of windows is
monitor specific already, if not we have a bug.

Cheers,
Anselm
Received on Tue Nov 01 2011 - 12:11:00 CET