Rule for matching by window type?

Issue #7 resolved
Jon Sagotsky created an issue

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)

  1. Nate Maia repo owner

    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 using match_ for class, instance, and title but the original will still be the default and accepted (both class and match_class are ok).

  2. Jon Sagotsky 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.

  3. Nate Maia 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} and type={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

  4. Nate Maia 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

  5. Log in to comment