floatpos: rules and transient window
rharmonson opened this issue · 8 comments
I suspect this is a case of my ignorance not a bug, but..
Scenario: Using Chromium, the "Save File" window exceeds my display resolution, 4k, which requires RMB drag and LMB to decrease size to select save or cancel.
- Using
RULE(.title = "Save File", .isfloating = 1, .floatpos = "50% 50% 50% 50%" )in config.h does not appear to effect the targeted window. I have enabled the patch in patches.h. - Regarding https://github.com/bakkeby/patches/wiki/floatpos can you add an example of floatpos rule in a rule table? My attempts to add
"50% 50% 50% 50%"and other values for floatpos fail. I am confident that I am not using the appropriate syntax.
~> xprop
WM_STATE(WM_STATE):
window state: Normal
icon window: 0x0
_NET_WM_STATE(ATOM) = _NET_WM_STATE_MODAL
WM_HINTS(WM_HINTS):
Client accepts input or input focus: True
Initial state is Normal State.
window id # of group leader: 0x1000001
WM_TRANSIENT_FOR(WINDOW): window id # 0xe00002
_GTK_THEME_VARIANT(UTF8_STRING) =
XdndAware(ATOM) = BITMAP
_NET_WM_OPAQUE_REGION(CARDINAL) = 0, 0, 3848, 2844
WM_WINDOW_ROLE(STRING) = "GtkFileChooserDialog"
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DIALOG
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 16777230, 16777231
_NET_WM_USER_TIME(CARDINAL) = 18314636
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x100000d
WM_CLIENT_LEADER(WINDOW): window id # 0x1000001
_NET_WM_PID(CARDINAL) = 66445
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLIENT_MACHINE(STRING) = "soc262890"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified minimum size: 1254 by 850
program specified resize increment: 2 by 2
program specified base size: 0 by 0
window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "chrome", "Chrome"
WM_ICON_NAME(STRING) = "Save File"
_NET_WM_ICON_NAME(UTF8_STRING) = "Save File"
WM_NAME(STRING) = "Save File"
_NET_WM_NAME(UTF8_STRING) = "Save File"
Love what you do @bakkeby. Thank you!
In the xprop output there is this line:
WM_TRANSIENT_FOR(WINDOW): window id # 0xe00002
Which means that the window is transient for the parent window. In dwm transient windows always start as floating and inherit the tag and monitor of the parent client window. More so client rules do not apply for transient windows, which is why your rule does not have any effect.
As for examples using a normal array this will be the same as any other patch that adds rule options. The (new) column where you would add the floatpos string (or NULL) depends on the position the new field is added in the Rule struct in dwm.c. This should make sense if you compare the Rule struct fields and the order of the columns in the rules array (which is an array of the Rule data type).
No go for client rules on transient windows using stock dwm or floatpos patch. Okay and thank you educating me. Doing a hunt on suckless' website, I am not seeing a patch that would permit resizing a transient window. Do you know different?
Reviewing the typedef struct in dwm.c, I believe that I am using the correct structure but it errors on compiling even using your examples from the wiki and setting floatpos as NULL. At this point, my original intent for using the patch isn't applicable so I am going to move on to other tasks--anxious to get my antiX dwm respin complete. If I revisit floatpos, I will open a new issue if challenges persist.
Thank you and have a wonderful day @bakkeby!
If you show me what you get then I can give advice.
The patch comes with example rules as per:
patches/dwm/dwm-floatpos-6.3.diff
Lines 36 to 38 in 0d0432e
Is it perhaps a case of differences between config.def.h and config.h?
As for a patch that allows for rules to apply for transient windows; you are correct, there are none. I am sure the reason for this is that with the rules as-is there wouldn't be much reason to have a standalone patch that do this because the options when it comes to client rules is very limited on a stock dwm.
I implemented something like this in one of my other builds. I used a rule filter indicating whether the rule applies to transient windows, normal windows, or both. I can show you how to do this if you want, possibly with an ad-hoc patch.
Is it perhaps a case of differences between config.def.h and config.h?
Good point. If I sync'd my fork, then pulled and did not delete the old config.h before make, that may be problematic, right? Never even occurred to me but the more I think on it.. I am a n00b. Easy enough to test but if true, I am going to write a shell script to update config.h and patches.h after resync's. Sounds like fun!
I implemented something like this in one of my other builds. I used a rule filter indicating whether the rule applies to transient windows, normal windows, or both. I can show you how to do this if you want, possibly with an ad-hoc patch.
Yes! If you point the way, I will give it a go and try not to be too much of a nuisance. :)
@rharmonson I uploaded an example patch for ruled transients here: https://github.com/bakkeby/patches/blob/master/dwm/dwm-ruled_transients-6.3.diff
@bakkeby, awesome!
Finalized my first anitx dwm respin version. Got a bunch of items to fix including this item for the next release.
I am seeing a correlation between the symptom described in my original post and the use of hidpi displays and .Xresources Xft.dpi setting. I'll experiment more in addition to testing the patch.
Thank you, again, and have a good day.
I just tried using Xft.dpi, kind of surprised how well that works (of course it doesn't scale icons or status2d drawings, and seemingly not fallback fonts).
and correct application of Xft.dpi fixed my original problem. I was using too high of a dpi.
$HOME/.Xresources
! Recommend using the following Xft.dpi values: 1080p = 96, 1440p = 128, and 2160p (4k) = 192
Xft.dpi 96
Honestly! I knew this stuff but it falls out of my head. disgusted
On icons, it's been a mixed bag. On my current respin build, icons are displaying correctly but in the past I had to set either gtk or qt variables to correct. Don't remember the details at the moment.
I am going to experiment on your patch if for no other reason than to understand how to manage transient windows.