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).
Please test this! Plug in screens, unplug them, use your video projector,
change resolutions, etc.
To use the assignments, use the following syntax:
workspace <number> [screen <screen>] [name]
Where screen can be one of:
<number> (It is not provided that these numbers stay constant, so use with care)
<x>x<y> (Coordinates where the screen starts, so 1280 will be fine to match the
screen right of the main screen if your main screen is 1280 pixels
width. However, 1281 will not match)
<x>
x<y>
Some examples follow:
workspace 1 screen 0
workspace 1 screen 1
workspace 1 screen 1280x0
workspace 2 screen 1280
workspace 3 screen x0
workspace 3 screen 1 www
workspace 4 screen 0 mail
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.
Use bn (normal), bp (1-px), bb (borderless) as commands to change the
border style of the currently focused window. Feel free to use i3-msg
to do this.
Details which are missing: A command to hide/show all floating clients,
moving/resizing clients with your mouse holding Mod1 (click anywhere
in the client, not just on its borders), resize/move by keyboard, select
next/previous client by keyboard
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.
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