Do not handle click events on dock clients because they are not managed
windows. Dock clients are responsible for sending the message to i3 to
focus a workspace if that is appropriate. i3bar now sends the message to
focus the correct workspace when that is appropriate.
Otherwise, it could interfere with the dock clients own click handling,
which could be an action to focus a different workspace than i3 had
assumed, such as would be the case with a workspace widget.
The X11 protocol description states:
The window the event is reported with respect to is called the event
window. The event window is found by starting with the source window
and looking up the hierarchy for the first window on which any client
has selected interest in the event.
For the case of urxvt with URxvt.internalBorder > 0, urxvt sets up a
subwindow for its actual contents that is placed “in the middle” of the
urxvt window. In terms of the X11 protocol, the source window is urxvt’s
window, but urxvt does not select ButtonPress events for that.
Therefore, X11 will go up in the hierarchy and deliver the event to i3
for i3’s window decoration, even though this was not actually a click on
the decoration, but into the managed window.
Therefore, we check whether child != XCB_NONE for clicks on window
decorations and then handle them as a click inside the window.
fixes#1176
When the user initiates a drag resize, draw the resize bar on the border
of the two involved containers and snap the pointer.
This solution produces cleaner code than the former approach where the
caller obfuscated the click coordinates of the event. This may confuse
someone expecting a true button press event.
Fixes an issue where the resize cursor is not shown when the resize bar
is clicked until the user begins to drag the mouse.
Fixes an issue where focus is not properly updated after the drag is
complete when `focus_follows_mouse' option is set, leaving the pointer
in an unfocused window in some cases.
Fixes an issue where the resize bar may jump a few pixels when the mouse
is first moved.
(Thanks to pbos for suggesting this fix and providing an example
implementation)
With this commit, the default behavior is to display popups while there
is a fullscreen application only if the popup belongs to that
application (as determined by the WM_TRANSIENT_FOR hint which
applications have to set properly).
fixes#663
With this commit, the "default" layout is replaced by the splith and
splitv layouts. splith is equivalent to default with orientation
horizontal and splitv is equivalent to default with orientation
vertical.
The "split h" and "split v" commands continue to work as before, they
split the current container and you will end up in a split container
with layout splith (after "split h") or splitv (after "split v").
To change a splith container into a splitv container, use either "layout
splitv" or "layout toggle split". The latter command is used in the
default config as mod+l (previously "layout default"). In case you have
"layout default" in your config file, it is recommended to just replace
it by "layout toggle split", which will work as "layout default" did
before when pressing it once, but toggle between horizontal/vertical
when pressing it repeatedly.
The rationale behind this commit is that it’s cleaner to have all
parameters that influence how windows are rendered in the layout itself
rather than having a special parameter in combination with only one
layout. This enables us to change existing split containers in all cases
without breaking existing features (see ticket #464). Also, users should
feel more confident about whether they are actually splitting or just
changing an existing split container now.
As a nice side-effect, this commit brings back the "layout toggle"
feature we once had in i3 version 3 (see the userguide).
AFAIK, it is safe to use in-place restart to upgrade into versions
after this commit (switching to an older version will break your layout,
though).
Fixes#464
Runs the same code as for non-stacked / non-tabbed containers, but on the
parent of the container (which is the stacked / tabbed con, since route_click
gets called with the child).
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!
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.
Warning: This is not yet thoroughly tested, so be prepared to
encounter some segfaults. Please enable logging and coredumps,
so we can fix bugs quickly.
Using this command, you can limit the amount of columns or rows for
a stacking container. This allows for better usage of screen estate
when using stacking containers with many clients.
Examples:
i3-msg "stack-limit cols 2"
You will now have a stack window which has two columns of windows.
Tony Crisci