3721bcb868
Actually, commit 1c5adc6c35cffaedc08c7d1dd1b03a3269d1367c commented out code without ever fixing it. I think this was responsible for the 'workspace switching sometimes does not work' bug. My observations: Had it again today and analyzed a log of it. Looks like after unmapping the windows on one workspace (in my case: chromium, eclipse, urxvt, focus on eclipse) we get UnmapNotify events for chromium and eclipse, but then we get an EnterNotify for the terminal (due to unmapping the other windows and therefore mapping the terminal under the cursor), only afterwards the UnmapNotify follows. So, there are two things wrong with that: • We handle EnterNotifys for unmapped windows • Unmapping windows sometimes works in a sequence, sometimes the sequence gets split. Not sure why (if unmapping can take longer for some windows or if our syncing is wrong -- but i checked the latter briefly and it looks correct). Maybe GrabServer helps? • We don’t ignore EnterNotify events caused by UnmapNotifies. We used to, but then there was a different problem and we decided to solve the EnterNotify problem in another way, which actually never happened (commit 1c5adc6c35cffaedc08c7d1dd1b03a3269d1367c).
README file for the "tree" branch of i3
=======================================
This is a *massive* refactoring of i3. It was driven by thinking about whether
a different data structure could make things easier (for users and developers).
The old data structure of a table provided relatively flexible layouts but was
*very* hard to implement.
The new data structure is a tree. You can have horizontally and vertically split
containers. Each container can contain either nothing yet (waiting for a window
or for the user to put more containers in it), one or more containers or exactly
one window. RandR Outputs and workspaces are not treated specially, but they
are just containers inside the tree.
This structure allows for easy serialization, meaning multiple things:
- we can store and reload the layout for inplace restarts (this is already working)
- we can store parts of the layout and load them at any position in our tree
(partly working)
- we can load a layout specifying the physical positions of RandR outputs
for pathologic screen setups
- we can load a default layout for each workspace to specify the position
of dock clients
- we can use test-driven development to a much higher degree because we have
access to the whole tree
Ripping out the core data structures of i3 and replacing them of course has
some side-effects, which I will describe here (the list may not be complete,
new side-effects may not be known yet):
- Empty containers are allowed. They can swallow windows based on certain
criteria. We can implement session-saving this way.
- Assignments (put windows on certain workspaces, put workspaces on certain
outputs) are just special cases of the point above.
- Window decorations are now always rendered on the parent window. This means
we don’t have to carry around ugly Stack_Windows any more.
- Operations always (?) operate on containers, so you can make a container
(containing multiple windows) fullscreen or floating (for example) and no
longer just single windows.
- All X11 requests are now pushed to X11 in a separate step (rendering is one
step, updating X11 another). This makes talking to X11 a lot less error-prone
and allows for simpler code.
======================
SOME WORDS OF WARNING:
======================
The current state of the branch is not nearly the quality you know of i3. It
is in flux, changes and crashes are to be expected. Many features do not work
yet. It is only suitable if you want to help developing or have a look at what
is coming. Do *NOT* use it for production! You have been warned.