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!
Thanks to Mikael for bringing it to my mind. This change introduces
two new color classes, client.urgent and bar.urgent. By default,
urgent clients are drawn in red (colors by Atsutane).
Use "bindsym" instead of "bind". You have to use the names of keys
as in xmodmap. To get a list of currently bounud symbols, use
xmodmap -pke
Technical quirk: Xlib generated MappingNotify events upon
XkbMapNotify events (from XKB, as the name says). XCB does not yet
have support for XKB, thus we need to select and handle the event
by ourself. Hopefully, this will change in the future.
Thanks to psychoschlumpf for the hint. Having comments in the headers
makes it easier to get the big picture when not being interested in the
source.
The doxygen file extracts as much as it can into HTML files. Please note
that this is not official/supported documentation, but rather being nice
to people who have to/want to use doxygen (I don’t).
Let me paste the header of the doxygen file:
You can use this file with doxygen to create a pseudo-documentation
automatically from source. doxygen-comments are not used very extensively
in i3, mostly for the reason that it clutters the source code and has no
real use (doxygen’s output looks really ugly).
So, if you want to use it, here you go. This is however not a supported
document, and I recommend you have a look at the docs/ folder or at
http://i3.zekjur.net/ for more, real documentation.
There was a race condition when mapping a window and not setting the event mask
before. Therefore, the ReparentNotify and (more important) the UnmapNotify generated
by reparenting were not received, thus leaving the awaiting_useless_unmap variable
of the client "true". To just make it work, in previous commits the DestroyNotify
handler was introduced. Fortunately, with fixing this race condition by first
setting the event mask and mapping the window afterwards, we can remove this handler.
As for the dock windows, there were quite some occurences were client->container
was used without checking if the client is inside a container at all.
Furthermore, the client’s strut containing the space to reserve at the screen edge
is now checked and the desired height is set to the window’s height if the strut
contains 0 or if no strut was specified at all.
By specifying XCB_EVENT_MASK_SUBSTRUCTURE_REDIRECT, the window manager
will get map request events instead of map notify events, and therefore
can act sooner (the window won’t be positioned on the screen and moved
afterwards).
Furthermore, this fixes some problems with GIMP/VLC (and probably others)
which caused endless loops.
Also, events which should be ignored are now saved in a queue rather than
saving just the last event. This should eliminate race conditions.
Note that there is a new FIXME in src/handlers.c. Some windows generate
unmap notify events when reparenting while others don’t. We need to
understand, document and implement a more correct way to handle this.
Michael Stapelberg