Urgency seems to be broken

Issue #3 resolved
Jon Sagotsky created an issue

I’m running arch with the latest dk from aur. Dotfiles here: https://github.com/sagotsky/.dotfiles/tree/master/config/dk

I haven’t been able to get urgent borders working. I suspect my urgency hints are being eaten because they aren’t showing up in polybar anymore.

I’ve tried setting urgency the following ways

  • Waiting for a slack message
  • xdotool set_window --urgency 1 0xWINDOW_ID
  • wmctrl -r 0xWINDOW_ID -b add,demands_attention

No luck in any of them.

Comments (7)

  1. Nate Maia repo owner

    The default behaviour is to focus newly opened and urgent windows so you won't get any border change.

    If you were to run dkcmd set focus_open=false focus_urgent=false then open something that sets the urgency hint as per ICCCM WM_HINTS https://tronche.com/gui/x/icccm/sec-4.html or set it (likely with the xdotool command) it should work. Also applications that set their own like google-chrome-stable do show urgent borders when the focus is disabled. Glad to link a vid if you like but trust me it's working.

    Perhaps this should be expanded to include the EWMH _NET_WM_STATE_DEMANDS_ATTENTION but I've yet to find a use for it and it would complicate _NET_WM_STATE with the need to support more than one atom (mainly STATE_FULLSCREEN).

    The urgency hints might be eaten by dk as we do request a lot of events so I'll look into this.

  2. Jon Sagotsky reporter

    dkcmd set focus_open=false focus_urgent=false

    Ah that makes sense. Didn’t make the connection between those settings and the borders not showing up.

    something that sets the urgency hint as per ICCCM WM_HINTS

    It looks like you’re right and xdotool --urgency sets the WM_HINTS bit but wmctrl is doing something else.

    I’ll take your word for it that chrome’s borders are working. Unfortunately all my scripts are using _NET_WM_STATE so I think I can sleep on this feature until I have a chance to fix them. I don’t really grok the complexity in supporting multiple atoms.

  3. Nate Maia repo owner

    Atoms are just unsigned ints so multiple support would require a loop until hitting a terminator. I don't think it's a bad idea to include support for this as icccm is slowly being phased out in favour of ewmh.

    Bit busy with work and life lately but I'll for sure work on this in the near-ish future.

  4. Jon Sagotsky reporter

    Good news. My testing of this feature was flaws. It totally works.

    I didn’t realize the urgency hint would show up on a WM event. I thought the hint being added was its own event and so borders would show up immediately. That assumption probably comes from some other WM. The problem with how I was testing this was I was using two windows. One was a terminal to set urgency. The other was the window I wanted to see get a border. I had to introduce a third window (or at a different desktop) and toggle between the two non-urgent windows to see the hook show up.

    It would still be nice to get `_NET_WM_STATE_DEMANDS_ATTENTION` support, but it’s a feature request rather than a bug now.

  5. Nate Maia repo owner

    So I've added some basic support for _NET_WM_STATE_DEMANDS_ATTENTION and tweaked the behavior when opening windows. If both focus_urgent and focus_open are 0/false then newly opened windows will be set as urgent (I'll likely split this off to another setting open_urgent).

    An easy way to test this is use a browser and open a page from a terminal firefox https://duckduckgo.com/, if there's an existing instance of ff running it will be set urgent or focused based on the focus_urgent setting. I also noticed that wmctrl -r 0xWINDOW_ID -b add,demands_attention isn't a valid wmctrl command on my system, they don't seem to support the setting of the net demands attention atom for whatever reason, most seem to leave it up to the clients/wm.

    I'll note this as solved for now but feel free to grab the latest source and build/test so you can catch anything I missed.

    Cheers

  6. Log in to comment