Re: [dev] [dwm] [patch] USPosition, USSize
On Mon, Aug 08, 2011 at 11:37:55PM -0400, Kurt H Maier wrote: On Mon, Aug 8, 2011 at 10:08 PM, Connor Lane Smith c...@lubutu.com wrote: Basically these two fields state that the client's geometry has been chosen specifically by the user, and the window manager ought to respect that. But we don't, we just tile the window anyway. The traditional X utilities all set this field when the user passes them the '-geom' (or similar) flag, including xterm, rxvt, and so on. This might be the historical reason these exist, but they were conceived before the advent of modern tiling window managers, and imo clients shouldn't be managing themselves anyway. Further, there's no telling what kind of weird-ass program might be abusing these without anyone as yet knowing. Please don't merge this patch into mainline; I'd like xterm et al to behave just they way they have been. +1 But I use resizehints = False; so it won't affect me anyway... -- # Petr Sabata pgpETF58pxB0X.pgp Description: PGP signature
Re: [dev] [dwm] [patch] USPosition, USSize
Honestly, I'm not sure this hint should be respected, at least not without some serious consideration. This would lead to a concept of layers that is entirely binary (either on the 'lower' tiled layer or above it in the specified size) and there's already a way to get this to work - set a class and the resize hint on the window, set config.h to set that class to float and you're done. You've been more explicit, implying that's REALLY what you wanted to do with the window and you're not confusing users by breaking the consistency of how DWM handles windows (tiles them always).
Re: [dev] [dwm] [patch] USPosition, USSize
Of course, Connor's right. Transient windows are always floated. However, I think this is also the expected behavior and DWM's handling of these two cases is as expected. I'm simply stating that the current way that DWM handles windows works fine for most users without us handling yet another hint. There's a workaround for this that's already in the code - setting the window to float in config.h. It's not perfect, but it works in most use cases. I don't particularly see a *need* for this to be incorporated in mainline. Then again, I too am pretty ambivalent about the whole thing too. If we can solve the Doesn't always work as expected thing, I'd be all for it being included to cover corner cases.
Re: [dev] [dwm] [patch] USPosition, USSize
On Tue, Aug 9, 2011 at 9:37 AM, Connor Lane Smith c...@lubutu.com wrote: I think the window manager should do whatever the user asks. Correct. And if I want my windows managed in a specific way, I need to ask the window manager. Someone on IRC said they use -geom and have to special-case every program for it. I have to 'special-case' every program as well. That's how dwm works. -- # Kurt H Maier
Re: [dev] [dwm] [patch] USPosition, USSize
Since there's a few opinions on this, how about we make a dwm focus page? The NetActiveWindow hint is not one of the better ideas in the history of X11, it really got my goat when windows started stealing focus while I'm trying to type elsewhere. Rob focus.md Description: Binary data
Re: [dev] [dwm] [patch] USPosition, USSize
On 9 August 2011 20:41, Rob robpill...@gmail.com wrote: Since there's a few opinions on this, how about we make a dwm focus page? The NetActiveWindow hint is not one of the better ideas in the history of X11, it really got my goat when windows started stealing focus while I'm trying to type elsewhere. I was planning to make a new thread about this, but since you've brought it up... dwm handles _NET_ACTIVE_WINDOW messages by switching focus to the given client, and if it was invisible dwm switches to view every tag with which the client is tagged. This really does not work with dwm's tagging model, and the switch can be very disorienting, where suddenly all those tags windows fill the screen. It's the workspace approach, and it's completely broken. (dwm ignores FocusIn events for this very reason, but doesn't seem to apply the same logic to EWMH.) By the EWMH standard, dwm is *not* required to honour these messages, and can in fact ignore them completely. My suggestion is that dwm should treat the message as an urgency switch, not switching focus and certainly not switching tags. (A side note: dwm's support for _NET_WM_STATE is slightly flawed: it only checks the message's data.l[1] field for the fullscreen atom, whereas it should check both data.l[1] and data.l[2].) These are the only outright bugs in dwm's EWMH support that I've discovered so far. Thanks, cls
[dev] [dwm] [patch] USPosition, USSize
Hey,
I've recently been looking into dwm's window manager hints support.
I've just finished looking through all the ICCCM properties (next up
EWMH), and have found only one which dwm ought to support, but
doesn't: the WM_NORMAL_HINTS USPosition and USSize fields.
Basically these two fields state that the client's geometry has been
chosen specifically by the user, and the window manager ought to
respect that. But we don't, we just tile the window anyway. The
traditional X utilities all set this field when the user passes them
the '-geom' (or similar) flag, including xterm, rxvt, and so on.
I've attached a patch which adds support for these fields in updatesizehints().
Thanks,
cls
diff -r 335c279dbff6 dwm.c
--- a/dwm.c Tue Jun 14 22:28:16 2011 +0100
+++ b/dwm.c Tue Aug 09 03:07:52 2011 +0100
@@ -1882,6 +1882,8 @@
if(!XGetWMNormalHints(dpy, c-win, size, msize))
/* size is uninitialized, ensure that size.flags aren't used */
size.flags = PSize;
+ if(size.flags (USPosition|USSize))
+ c-isfloating = True;
if(size.flags PBaseSize) {
c-basew = size.base_width;
c-baseh = size.base_height;
Re: [dev] [dwm] [patch] USPosition, USSize
On Mon, Aug 8, 2011 at 10:08 PM, Connor Lane Smith c...@lubutu.com wrote: Basically these two fields state that the client's geometry has been chosen specifically by the user, and the window manager ought to respect that. But we don't, we just tile the window anyway. The traditional X utilities all set this field when the user passes them the '-geom' (or similar) flag, including xterm, rxvt, and so on. This might be the historical reason these exist, but they were conceived before the advent of modern tiling window managers, and imo clients shouldn't be managing themselves anyway. Further, there's no telling what kind of weird-ass program might be abusing these without anyone as yet knowing. Please don't merge this patch into mainline; I'd like xterm et al to behave just they way they have been. -- # Kurt H Maier
