The reason it was broken was that it was ok for the sum of the
percentages to be something other than 1.0. Now this is no longer
the case, the sum of the percentages must always be 1.0 or an
assertion will fail when we render the containers.
This enables compilation with llvm-clang and thus closes ticket #101.
While it makes the code more ugly, I don’t see a beautiful solution
which would enable us to stay with the more elegant solution of
nested functions and still allow compilation with any other compiler
than gcc.
Thanks to Merovius for doing a proof of concept on this one and
being a driving force behind the idea.
Using RandR instead of Xinerama means that we are now able to use
the full potential of the modern way of configuring screens. That
means, i3 now has an idea of the outputs your graphic driver
provides, which allowed us to get rid of the ugly way of detecting
changes in the screen configuration which we used before. Now, your
workspaces should not be confused when changing output modes anymore.
Also, instead of having ugly heuristics to assign your workspaces
to (the screen at position X or the second screen in the list of
screens) you will be able to just specify an output name.
As this change basically touches everything, you should be prepared
for bugs. Please test and report them!
We now use the virtual screen’s size/position instead of the X root
window for the grabwin (grabwin = the area in which the pointer may
move when resizing).
Thus, no more flickering because the window was first mapped and then
moved. Especially users of multiple monitors should be happy now ;-).
Rather radical change, though, so be prepared for problems.
This is a relatively big change, however all cases should be handled by
now.
Because the function to do graphical resizing got rather large, I’ve created
a new file src/resize.c for it.
This fixes ticket #35.
Deiz