i3: Window title changes should trigger window swallowing (layout saving)

@teto reports that i3 doesn’t swallow urxvt with the following layout JSON file:

// vim:ts=4:sw=4:et
{
    "border": "pixel",
    "current_border_width": 1,
    "floating": "auto_off",
    "geometry": {
       "height": 388,
       "width": 734,
       "x": 0,
       "y": 0
    },
    "name": "/home/teto",
    "percent": 1,
    "swallows": [
       {
        "class": "^URxvt$",
       // "instance": "^rxvt\\-unicode$",
        "title": "^/home/teto/dce$"                                                                      
       // "transient_for": "^$"
       }
    ],
    "type": "con"
}

@teto starts urxvt like this:

#!/bin/sh

i3-msg "workspace 9; append_layout $HOME/.i3/test.json"                                                  

urxvt -cd $HOME/dce

Having a look at the logfile reveals that urxvt first starts up with a different title and later changes its _NET_WM_NAME property to set the correct title.

i3 should, once it got the new title, check whether the window can be matched by any of the placeholders and swallow it if so.

This affects not only window titles, but all properties that can be used to swallow a window.

About this issue

Original URL
State: closed
Created 9 years ago
Reactions: 4
Comments: 21 (12 by maintainers)

Commits related to this issue

bugfix: serialize con_id with %p in run_binding() When a con is given to run_binding() to run the command in the context of this con such as when running a mouse binding, serialize the con_id with %p... — committed to acrisci/i3 by acrisci 9 years ago

Most upvoted comments

I can work on this. I do have one question though. I see two ways of implementing this: Destroying the original window’s container and reparenting it to the swallow one or destroying the swallow window container and moving the original container. Is either method preferable?

izzel on Jul 29, 2019

thanks !

teto on Aug 13, 2019

If I launch a Firefox window with a specific url, the title doesn’t get set until the page loads. As a result, my layout restore always puts the Firefox Windows in the wrong spot. On Apr 4, 2016 07:22, “Ingo Bürk” notifications@github.com wrote:

Is there any reason why you need to match on the title? I think in most cases it should be possible to match on class and instance and start the terminals accordingly.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/i3/i3/issues/1668#issuecomment-205318672

alexmcnurlin on Apr 4, 2016

I went ahead and moved this into a new issue @JonnyHaystack.

izzel on May 10, 2020

I get some very strange bugs when restoring multiple windows in a 4x4 grid by appending a layout and then opening terminal windows whose titles adjust are changed after initial window creation. When I use the old workaround of unmapping all the windows in the workspace, appending the layout, then remapping the windows, it works fine as it always has.

How it should look (and how it does look when I restore it in the old way): img-2020-04-25-1750

How it looks when the windows are swallowed after a title change: img-2020-04-25-1751

These are not mere graphical artifiacts, because if I keep pressing enter you can see that the prompt never goes below the top of the “artifact”, so the window must actually be ending there, and the tiling has completely broken.

Also thanks @izzel for your work on this, it’s a great improvement to have. In most situations it has worked perfectly for me, and I’m not sure if this weird bug is directly related to this change or if this change is bringing to light a bug somewhere else in the codebase.

JonnyHaystack on Apr 25, 2020