The Clang Static Analyzer uncovered those issues:
- The variable "changed" in handlers.c is written to, but it's
never read since that specific write, so the write is not
necessary.
- In util.c, "tail" may be NULL. In that case, we shouldn't pass
it to strlen because strlen's behavior is not defined when s is
NULL.
- In util.c, "write_index" is incremented twice. It's never used
anymore after being incremented once, so the second increment is
not necessary.
This fixes the bug which caused floating windows to be visible even when
switching to a different workspace.
Instead of ignoring a specific sequence, we now set an ignore_unmap counter for
each container. (So, should containers be closed too early or stay open even if
they should be closed, we probably need to have a closer look at the counter.
At the moment, it is increased by one on reparenting and unmapping (for
workspace changes) and decremented by one on each UnmapNotify event).
This system is better because a sequence does not describe a single unmap or
reparent request but a request to X11 on the network layer -- which can contain
multiple requests.
This would lead to i3 thinking that a new window was already managed if it
has the same X-ID as the old window. Instead, we need to fix the EnterNotify
problem in a different way.
This helps for windows which are immediately destroyed instead of
unmapped, like when starting i3status | ./foobar | dzen2 -dock
and foobar does not exist (i3status and dzen2 will get a SIGPIPE).
Before this commit, i3 used key bindings in SYNC mode for bindings
like Mode_switch + <a> and replayed the key if the current state
did not include Mode_switch. This had some problems:
1) The WM needed to acknowledge much more key presses than you
actually had bindings for, thus making the system a bit laggy
sometimes.
2) Users of layouts who constantly type in the third level (like
russian layouts) did not get their cyrillic symbols correctly
(they were not replayed right), neither did the keybindings
work in both modes.
So, the current implementation uses the following approach: XKB
provides an event which contains the current state (including
the current level). i3 signs up for this event and upon receival,
it re-maps the bindings using Mode_switch (enables them when the
level goes to the third level and disables them as soon as the
level goes back to normal). This fixes both problems.
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!
Actually, WM_CLASS contains two null-terminated strings, so we cannot
use asprintf() to get its value but rather use strdup() to get both
of them. Both values are compared when a client is matched against
a wm_class/title combination (for assignments for example).
This makes it more clear that the option is meant to be a special
case (it *disables* part of the focus handling). Also, when
initializing the config data structure with zeros, it will get
initialized with the right value.
Furthermore, the config file parser now also accepts various values
which represent "true", not only numbers.
Starting from this commit, a borderless window will always be
borderless if it is the only window in a container. For example,
you can have Firefox borderless in a tabbed container and as soon
as the download manager or a viewer gets opened, the container
will be rendered like a normal tabbed container.
This solves the user-interface dilemma of borderless/1-px-border
windows inside stacked/tabbed containers, at least for this special
case. Thanks to Merovius for this suggestion.
Calculations were wrong (they simply didn’t take into account that
there is more than one border style, the code was from before we
implemented that…). We cannot directly set child_rect to the coordinates
as resize_client takes rect and calculates the child_rect, so we need
the new lines of code for this bugfix in any case (rect needs to be
updated).
This did not happen all the time. It seems like you need to have a
container which is in stacking/tabbing mode on the screen which
is being reconfigured. (when doing xrandr --output VGA1 --off for
example)
Sometimes, it may happen that the focus is "nowhere" and thus the
user is stuck. This was often the case with opera, sometimes with
pcmanfm. See ticket #118.
This fixes many problems we were having with a dynamically growing
array because of the realloc (pointers inside the area which was
allocated were no longer valid as soon as the realloc moved the
memory to another address).
Again, this is a rather big change, so expect problems and enable
core-dumps.
For example, you can create a mode which will let you resize windows
with some easy to use keys. So, instead of binding a combination
of your homerow and modifiers to resize, like this:
bind Mod4+44 resize right +10
bind Mod4+45 resize right -10
...
You can instead define a new mode:
mode "resize" {
bind 44 resize right +10
bind 45 resize right -10
...
bind 36 mode default
}
bindsym Mod4+r mode resize
So, if you press Mod4+r now, your keybindings will be set to the ones
defined in your resize mode above. You can then use your homerow
(without any other modifier) to resize the current column/row and
press enter to go back to the default mode when you are done.
Note that using this option requires you to enable the new lexer/parser
by passing the -l flag to i3 when starting.
This warning only showed up with CFLAGS=-O2.
The variables in question could never be uninitialized because
they were definitely set, have a look at the code. But anyways,
less warnings is always a good thing ;-).
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).
Before this fix, you could go upwards and select the screen which
was at the rightmost because it also was the one topmost (if all
screen’s top position is equal).
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.
Also update documentation (manpage, userguide).
To make the code easier to read/write when checking if a client is
floating, introduce client_is_floating().
Before, we only sent a fake message. While this was sufficient for the
client side most of the time, it didn’t allow us to open floating
windows with the correct size.
Instead of building arrays of colorpixels we can simply use a pointer
to a struct Colortriple. Furthermore, by getting the colorpixels when
loading the configuration, we save a lot of function calls in the
main code.
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
We abuse (1 << 8) as mode_switch bit, which is in the range of the
filtered state bits (see previous commit). Therefore, we need to
filter first and then check for mode_switch.
Furthermore, we used 0x2 before, which was just wrong. So, use our
bitmask, not the normal one (0x2).
We abuse (1 << 8) as mode_switch bit, which is in the range of the
filtered state bits (see previous commit). Therefore, we need to
filter first and then check for mode_switch.
Furthermore, we used 0x2 before, which was just wrong. So, use our
bitmask, not the normal one (0x2).
Sometimes, when the mouse button gets stuck, state contains the bit for
BUTTON_MASK_1 (or other buttons). We filter them out to continue processing
keys correctly.
Sometimes, when the mouse button gets stuck, state contains the bit for
BUTTON_MASK_1 (or other buttons). We filter them out to continue processing
keys correctly.
Killing a dock client and having destroyed workspace 1 before (or the workspace
on which the dock client was started when it was not auto-started) crashed i3 before
this bugfix.
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.
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.
However, it is a bit more flexible obviously. You can specify the
offset of the window you want to go to, to implement workflows like
the following:
* Jump to mutt
* Jump to irssi
* Jump back ("focus 2" would be the command)
Apparantly, under some conditions (using LANG=en_US.UTF-8, other locale
variables unset), asprintf() says "Invalid or incomplete multibyte or
wide character" when given a string in COMPOUND_TEXT encoding.
For now, we properly handle asprintf-errors (this should have been
before), but there might be a better solution.
This fixes ticket #24. The crash appeared only under special conditions:
- The screen on which you switch to must be empty or at least not as
full as the screen on which you were before.
- You switch focus using your mouse.
- You previously selected a column/row which is not availably on the
destination screen (for example (1,1) and switching to an empty
screen).
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.
Before, all clients were reconfigured to just raise them, when focus should
be set. However, this generated lots of notify events, which in turn lead
to an endless loop of setting focus, reconfiguring, setting focus, …
Michael Stapelberg