Re: [i3] Containers in i3
Thanks very much for your detailed answer! I will study it carefully and make some experiments and maybe come up with a tree-model I can understand better--something I love doing. I like i3 very much because: (1) trees are IMO a better starting point than the column models others use; (2) I hate having to go through the pre-designed layouts given to you by some others (e.g. awesome and xmonad) (in the Microsoft spirit of "We know what's best for you"). So I'm glad i3 has surprises! (I think the tragedy of doing mathematics is that you start with something totally magical, and you put in a lot of thought and work to understand it; and if you succeed you destroy its magic (but not totally!).) On Mon, Jul 15, 2013 at 12:00 AM, Axel Wagner wrote: > Hi, > > Excerpts from Harry Allenby's message of 2013-07-15 07:50:39 +0200: > > I'm a very literal-minded mathematician > > Then let me, as a fellow mathematician try to explain at least part of > your questions ;) > > > (3) I just don't grasp the concept of a container in i3. It seems to > > me that the basic objects are windows, and that "container" is a > > derived, relational notion, namely: two windows may (or may not) be in > > the same container. [So, mathematically, I think of a container as an > > equivalence class of windows; but I don't know what the equivalence > > relation is.] > > Mathematically it is pretty simple. Containers are nodes in a tree, > whose root the X-root-window is. Children of this root level there are > individual outputs, children of the outputs are the workspaces, whose > children in turn are the container-trees containing the windows you see. > > A container can either be an inner node containing more containers (I > think this is called a „split-container“ in the documentation), or it > can be a leaf, containing a window. > > The nodes are not all equal, leafs contain windows and near the top of > the hierarchy there has to be special treatment (to use the more > user-friendly abstractions of outputs and workspaces), but mostly this > should be the way to think of it. > > > (2) If I press mod+v and make some windows, are they all in the same > > container? If I now press mod+h and make some more windows, are they > > in a different container? > > Yes and no. If by „window“ you think of „a leaf node in the container > tree“, then yes. > > If you create some windows (for example pressing Mod+Enter to > open some terminals), then each one is put in an individual container. > These containers are then put in a big container. If you then press > mod+h, the currently focused node in the tree (which would be a leaf in > most cases, so a container having a window inside it) is replaced by a > new container, with the old content as a subtree. If you then open some > windows, they are new leafs which are put in that new container. > > So I think the solution here is to stop thinking about windows as > entities in the container-tree, because they're really not. The > container-tree is an abstraction used by i3 and leaf-nodes in this tree > have a window-property attached to them. > > > (1) I'm sitting in front of an i3-screen with a focused window. I want > > to know (preferably in a semi-algorithmic statement), if I press Mod + > > s, exactly which windows will be stacked. In particular, does the > > answer depend on the history of the focused window? > > I'm actually not very clear of this myself. It just magically does > exactly what I want. I _think_ the container being stacked is always the > parent of the currently focused container. > > So, if you just open a bunch of terminals on an empty workspace, focus > one of them, your layout would be something like (I apologize for my > crude ASCII-art): > > Workspace > / | | | \ >C1 C2 C3 C4 C5 >| | | | | >T1 T2 T3 T4 T5 > > With C1…C5 being node-containers and T1…T5 are the five windows attached to > these node-containers. > Pressing Alt+s would (if you focus for example T1, or rather C1) stack > all your terminals. > > If on the other hand you open some terminals, split one leaf and open > some more, your tree will look like this: > > Workspace >/ | \ > C1 C2 C3 > || / \ > T1 T2 C4 C5 > || >T4 T5 > > Now if you focus C4 or C5 and press Mod+s, you will get a workspace with > two terminals visible (T1/T2) and one stacked container (C3), containing > two terminals (T4/T5). > > If on the other hand you focus C1 ore C2 and press Mod+s, you will get a > stacked workspace and can cycle between T1, T2 and (T4+T5). > > One small warning: I think near the top of the container-tree (at the > workspace-level and above) there is some special-casing regarding this, > because you cannot sensibly „stack“ workspaces. So if you try focusing > an entire workspace (via focus parent) you just might get unexpected > results. > > > So, I hope I could make at least some things more clear. Maybe I > confused you
Re: [i3] Containers in i3
Hi, Excerpts from Harry Allenby's message of 2013-07-15 07:50:39 +0200: > I'm a very literal-minded mathematician Then let me, as a fellow mathematician try to explain at least part of your questions ;) > (3) I just don't grasp the concept of a container in i3. It seems to > me that the basic objects are windows, and that "container" is a > derived, relational notion, namely: two windows may (or may not) be in > the same container. [So, mathematically, I think of a container as an > equivalence class of windows; but I don't know what the equivalence > relation is.] Mathematically it is pretty simple. Containers are nodes in a tree, whose root the X-root-window is. Children of this root level there are individual outputs, children of the outputs are the workspaces, whose children in turn are the container-trees containing the windows you see. A container can either be an inner node containing more containers (I think this is called a „split-container“ in the documentation), or it can be a leaf, containing a window. The nodes are not all equal, leafs contain windows and near the top of the hierarchy there has to be special treatment (to use the more user-friendly abstractions of outputs and workspaces), but mostly this should be the way to think of it. > (2) If I press mod+v and make some windows, are they all in the same > container? If I now press mod+h and make some more windows, are they > in a different container? Yes and no. If by „window“ you think of „a leaf node in the container tree“, then yes. If you create some windows (for example pressing Mod+Enter to open some terminals), then each one is put in an individual container. These containers are then put in a big container. If you then press mod+h, the currently focused node in the tree (which would be a leaf in most cases, so a container having a window inside it) is replaced by a new container, with the old content as a subtree. If you then open some windows, they are new leafs which are put in that new container. So I think the solution here is to stop thinking about windows as entities in the container-tree, because they're really not. The container-tree is an abstraction used by i3 and leaf-nodes in this tree have a window-property attached to them. > (1) I'm sitting in front of an i3-screen with a focused window. I want > to know (preferably in a semi-algorithmic statement), if I press Mod + > s, exactly which windows will be stacked. In particular, does the > answer depend on the history of the focused window? I'm actually not very clear of this myself. It just magically does exactly what I want. I _think_ the container being stacked is always the parent of the currently focused container. So, if you just open a bunch of terminals on an empty workspace, focus one of them, your layout would be something like (I apologize for my crude ASCII-art): Workspace / | | | \ C1 C2 C3 C4 C5 | | | | | T1 T2 T3 T4 T5 With C1…C5 being node-containers and T1…T5 are the five windows attached to these node-containers. Pressing Alt+s would (if you focus for example T1, or rather C1) stack all your terminals. If on the other hand you open some terminals, split one leaf and open some more, your tree will look like this: Workspace / | \ C1 C2 C3 || / \ T1 T2 C4 C5 || T4 T5 Now if you focus C4 or C5 and press Mod+s, you will get a workspace with two terminals visible (T1/T2) and one stacked container (C3), containing two terminals (T4/T5). If on the other hand you focus C1 ore C2 and press Mod+s, you will get a stacked workspace and can cycle between T1, T2 and (T4+T5). One small warning: I think near the top of the container-tree (at the workspace-level and above) there is some special-casing regarding this, because you cannot sensibly „stack“ workspaces. So if you try focusing an entire workspace (via focus parent) you just might get unexpected results. So, I hope I could make at least some things more clear. Maybe I confused you even more, in that case „sorry“ ;) Kind regards, Axel signature.asc Description: PGP signature
[i3] Containers in i3
Hello. I'm new to this list. Recently I've gotten interested in tiling window managers, and I studied the excellent reviews of more than 30 at the Crunchbang Wiki [http://crunchbang.org/forums/viewtopic.php?id=18273] and elsewhere, and I've tried out i3, awesome, and xmonad, and I think i3 is the one for me. I've watched all the videos on i3 available at YouTbue (including the one on tree structure and containers), and studied the User Guide, but I'm a very literal-minded mathematician and I'm still having problems with understanding and using the concept of containers. I have three questions (in order of abstractness). (1) I'm sitting in front of an i3-screen with a focused window. I want to know (preferably in a semi-algorithmic statement), if I press Mod + s, exactly which windows will be stacked. In particular, does the answer depend on the history of the focused window? (2) If I press mod+v and make some windows, are they all in the same container? If I now press mod+h and make some more windows, are they in a different container? (3) I just don't grasp the concept of a container in i3. It seems to me that the basic objects are windows, and that "container" is a derived, relational notion, namely: two windows may (or may not) be in the same container. [So, mathematically, I think of a container as an equivalence class of windows; but I don't know what the equivalence relation is.] Thank you for your patience. http://crunchbang.org/forums/viewtopic.php?id=18273
