Rule for matching by window type?
When I run zoom it opens up a splash dialog. The name and class are "zoom", which is the same as the main zoom window. I'd like to set up rules that handle this dialog differently than the main window
Here's the relevant pieces of xprop.
WM_NAME(STRING) =
_NET_WM_NAME(UTF8_STRING) = "zoom"
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_SPLASH, _KDE_NET_WM_WINDOW_TYPE_OVERRIDE, _NET_WM_WINDOW_TYPE_NORMAL
_XEMBED_INFO(_XEMBED_INFO) = 0x0, 0x1
WM_CLASS(STRING) = "zoom", "zoom"
In other wms I've been able to set up rules based on the type being a splash window. Perhaps rule
could match on type as well? e.g. rule [SUBCOMMAND] class="^zoom$" type="^splash$" [SETTING]
(As a sidenote, I find the rule subcommands a little hard to work with. I think that's because match rules and settings to apply both look like var=value
. Maybe the matcher args could be prepended with "match_" to make that a little more obvious? Dunno. This sidenote is totally out of scope ramblings, the real request is the type part.)
Comments (6)
-
repo owner -
reporter Here’s a screenshot. This pops up when I start a new meeting. The window on the top right appears to be managed.
Full output from
xprop
. If there’s some other way to find window names, I’d be happy to try it.xprop _NET_WM_DESKTOP(CARDINAL) = 9 _NET_WM_STATE(ATOM) = _NET_WM_STATE_ABOVE, _NET_WM_STATE_STAYS_ON_TOP _NET_WM_WINDOW_OPACITY(CARDINAL) = 4294967295 WM_STATE(WM_STATE): window state: Normal icon window: 0x0 _NET_WM_USER_TIME(CARDINAL) = 130960207 WM_TRANSIENT_FOR(WINDOW): window id # 0x4a00008 _NET_WM_ICON(CARDINAL) = Icon (64 x 64): (not shown) XdndAware(ATOM) = BITMAP WM_NAME(STRING) = _NET_WM_NAME(UTF8_STRING) = "zoom" _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_SPLASH, _KDE_NET_WM_WINDOW_TYPE_OVERRIDE, _NET_WM_WINDOW_TYPE_NORMAL _XEMBED_INFO(_XEMBED_INFO) = 0x0, 0x1 WM_CLIENT_LEADER(WINDOW): window id # 0x4a00008 WM_HINTS(WM_HINTS): Client accepts input or input focus: True window id # of group leader: 0x4a00008 WM_CLIENT_MACHINE(STRING) = "sashimi" _NET_WM_PID(CARDINAL) = 475845 _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 77594703 WM_CLASS(STRING) = "zoom", "zoom" WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST WM_NORMAL_HINTS(WM_SIZE_HINTS): user specified location: 722, 509 user specified size: 476 by 76 window gravity: Static ~
Now that I look at it, WM_NAME is blank and it’s NET_WM_NAME that’s set to zoom. I have no idea which is more correct. The class is zoom, which is of course the same as the main zoom window.
Re: sidenote. I can certainly appreciate wanting to keep the parsing code simple.
-
repo owner I've just pushed a commit with the initial work on type matching within rules, like with the other match strings it can be passed as
match_type={splash|dialog}
andtype={splash|dialog}
. For now only splash and dialog windows are supported, partially because dk only supports a few window types (dock|desktop|dialog|splash) where desktop and dock windows aren't managed the same, the rest are treated as normal windows.Hopefully you can test out this commit and see if it does what you need.
These changes won't be available in the AUR package until I do a version update.
Lemme know, cheers
-
reporter Worked perfectly! TY for the fix.
dkcmd rule type=splash float=true
-
repo owner Good stuff, I'll chalk this up as solved for now but leave it open for a bit if you want to comment further or notice any issues.
Should be making it's way into a new AUR version once I resolve the other issues.
Cheers
-
repo owner - changed status to resolved
- Log in to comment
Is this splash window being managed as a normal window (borders drawn, tiled, etc..)? Are you sure it doesn't have a different title that can be matched?
I installed zoom from the AUR and I don't really get a splash window.
I can add support for type matching the types dk supports but if the window is an override_redirect window dk won't manage it regardless of type (which I suspect it is).
Re the side note: All values looking alike is a feature imo and makes parsing more simple and ordering doesn't matter. Originally I planned to move most string matches into the config header as arrays but haven't gotten around to it yet, this would allow people to change the names of not only base commands (like it is now) but also the sub-matches for commands like
rule
. I'll add a commit to allow usingmatch_
for class, instance, and title but the original will still be the default and accepted (bothclass
andmatch_class
are ok).