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
