]> git.sur5r.net Git - i3/i3.github.io/blobdiff - docs/layout-saving.html
update debian.sur5r.net keyring
[i3/i3.github.io] / docs / layout-saving.html
index ed61533cc4694785162edc9e7ef31f07bcbdbd36..cddd5827d792e05e643425d93f3df872c6d0c00d 100644 (file)
@@ -4,7 +4,7 @@
 <head>\r
 <link rel="icon" type="image/x-icon" href="/favicon.ico">\r
 <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />\r
-<meta name="generator" content="AsciiDoc 8.6.9" />\r
+<meta name="generator" content="AsciiDoc 8.6.10" />\r
 <title>i3: Layout saving in i3</title>\r
 <link rel="stylesheet" href="/css/style.css" type="text/css" />\r
 <link rel="stylesheet" href="/css/xhtml11.css" type="text/css" />\r
@@ -90,7 +90,7 @@ it will be placed in the corresponding placeholder window. We say it gets
 <strong>swallowed</strong> by the placeholder container, hence the term.</p></div>\r
 <div class="paragraph"><p>Note: Swallowing windows into unsatisfied placeholder windows takes precedence\r
 over\r
-<a href="http://i3wm.org/docs/userguide.html#_automatically_putting_clients_on_specific_workspaces">assignment\r
+<a href="https://i3wm.org/docs/userguide.html#_automatically_putting_clients_on_specific_workspaces">assignment\r
 rules</a>. For example, if you assign all Emacs windows to workspace 1 in your i3\r
 configuration file, but there is a placeholder window on workspace 2 which\r
 matches Emacs as well, your newly started Emacs window will end up in the\r
@@ -202,7 +202,7 @@ a Chrome window:</p></div>
 </a>\r
 </span></p></div>\r
 <div class="paragraph"><p>The structure of this JSON file looks a lot like the <tt>TREE</tt> reply, see\r
-<a href="http://build.i3wm.org/docs/ipc.html#_tree_reply">http://build.i3wm.org/docs/ipc.html#_tree_reply</a> for documentation on that. Some\r
+<a href="https://build.i3wm.org/docs/ipc.html#_tree_reply">https://build.i3wm.org/docs/ipc.html#_tree_reply</a> for documentation on that. Some\r
 properties are excluded because they are not relevant when restoring a layout.</p></div>\r
 <div class="paragraph"><p>Most importantly, look at the "swallows" section of each window. This is where\r
 you need to be more or less specific. As an example, remember the section about\r
@@ -253,23 +253,25 @@ the window which matches any of the criteria. As an example:</p></div>
 <div class="olist arabic"><ol class="arabic">\r
 <li>\r
 <p>\r
-Layout files contain multiple “JSON documents” on the top level, whereas the\r
-   JSON standard only allows precisely one “document” (array or hash).\r
+Layout files contain multiple “JSON texts” at the top level. The JSON\r
+   standard doesn&#8217;t prohibit this, but in practice most JSON parsers only\r
+   allow precisely one “text” per document/file, and will mark multiple texts\r
+   as invalid JSON.\r
 </p>\r
 </li>\r
 <li>\r
 <p>\r
-Layout files contain comments which are not standardized, but understood by\r
-   many parsers.\r
+Layout files contain comments which are not allowed by the JSON standard,\r
+   but are understood by many parsers.\r
 </p>\r
 </li>\r
 </ol></div>\r
-<div class="paragraph"><p>Both deviations from the JSON standard are to make manual editing by humans\r
+<div class="paragraph"><p>Both of these deviations from the norm are to make manual editing by humans\r
 easier. In case you are writing a more elaborate tool for manipulating these\r
 layouts, you can either use a JSON parser that supports these deviations (for\r
 example libyajl), transform the layout file to a JSON-conforming file, or\r
-<a href="http://cr.i3wm.org/">submit a patch</a> to make <tt>i3-save-tree(1)</tt> optionally\r
-output standard-conforming JSON.</p></div>\r
+<a href="https://github.com/i3/i3/blob/next/.github/CONTRIBUTING.md">submit a patch</a>\r
+to make <tt>i3-save-tree(1)</tt> optionally output standard-conforming JSON.</p></div>\r
 </div>\r
 </div>\r
 </div>\r
@@ -301,6 +303,29 @@ container:</p></div>
 }</tt></pre>\r
 </div></div>\r
 </div>\r
+<div class="sect2">\r
+<h3 id="_placeholders_using_window_title_matches_don_8217_t_swallow_the_window">4.2. Placeholders using window title matches don&#8217;t swallow the window</h3>\r
+<div class="paragraph"><p>If you use the <tt>title</tt> attribute to match a window and find that it doesn&#8217;t\r
+work or only works sometimes, the reason might be that the application sets the\r
+title only after making the window visible. This will be especially true for\r
+programs running inside terminal emulators, e.g., <tt>urxvt -e irssi</tt> when\r
+matching on <tt>title: "irssi"</tt>.</p></div>\r
+<div class="paragraph"><p>One way to deal with this is to not rely on the title, but instead use, e.g.,\r
+the <tt>instance</tt> attribute and running the program to set this window instance to\r
+that value:</p></div>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt># Run irssi via\r
+# urxvt -name "irssi-container" -e irssi\r
+\r
+"swallows": [\r
+    {\r
+        "class": "URxvt",\r
+        "instance": "irssi-container"\r
+    }\r
+]</tt></pre>\r
+</div></div>\r
+</div>\r
 </div>\r
 </div>\r
 </div>\r