fbce834b introduced a bug where scrolling over the decoration while
another container is focused would not focus the tabbed/stacked
container itself, but would instead move focus through the currently
focused container.
Using 'default:' cases can hide logical errors which would lead to i3
crashes for users. With this change the compiler will print a warning
when a case is not handled. For example, if I add a new value in the
Font.type enum:
../../i3/libi3/font.c: In function ‘draw_text’:
../../i3/libi3/font.c:378:5: warning: enumeration value ‘NEWFONT’ not handled in switch [-Wswitch]
switch (savedFont->type) {
^~~~~~
The current behaviour is buggy in the following layout:
T [ A* V [ B C ] ], where the focus stack in V is B > C.
When the user scrolls down, focus correctly moves to B but if the user
scrolls down again the whole vertical container is focused.
This happens because 'bool scroll_next_possible' is false but
con_activate is called on the tabbed container's sibling - the vertical
container.
Applied for:
1. '[...] focus' for a floating container raises it to the top.
2. Focusing a window through a focus event raises it to the top.
Fixes#2572
This introduces the flag --exclude-titlebar for mouse bindings which
allows bindings like
bindsym --whole-window --border --exclude-titlebar button3 focus
fixes#2347
Including config.h is necessary to get e.g. the _GNU_SOURCE define and
any other definitions that autoconf declares. Hence, config.h needs to
be included as the first header in each file.
This is done either via:
1. Including "common.h" (i3bar)
2. Including "libi3.h"
3. Including "all.h" (i3)
4. Including <config.h> directly
Also remove now-unused I3__FILE__, add copyright/license statement
where missing and switch include/all.h to #pragma once.
Prior to this commit a binding specifying only --whole-window would
trigger even when clicking on the window border. However, this should
only happen if --border is specified.
fixes#2348
Previously, mouse bindings could only be run when a window was present,
by using --whole-window. Such bindings would not work on empty
workspaces. However, this is a valid usecase for bindings like
bindsym $mod+button4 workspace prev
bindsym $mod+button5 workspace next
Hence, we need to grab the root window as well and run bindings on it.
fixes#2097
fixes#1835
This commit improves the translation of keysyms to keycodes by loading
keymaps using libxkbcommon-x11 and using libxkbcommon for figuring out
the keymap, depending on each keybinding’s modifiers. This way, the
upper layers of complex layouts are now usable with i3’s bindsym
directive, such as de_neo’s layer 3 and higher.
Furthermore, the commit generalizes the handling of different XKB
groups. We formerly had support only for two separate groups, the
default group 1, and group 2. While Mode_switch is only one way to
switch to group 2, we called the binding option Mode_switch. With this
commit, the new names Group1, Group2 (an alias for Mode_switch), Group3
and Group4 are introduced for configuring bindings. This is only useful
for advanced keyboard layouts, such as people loading two keyboard
layouts and switching between them (us, ru seems to be a popular
combination).
When grabbing keys, one can only specify the modifier mask, but not an
XKB state mask (or value), so we still dynamically unbind and re-bind
keys whenever the XKB group changes.
The commit was manually tested using the following i3 config:
bindsym Group4+n nop heya from group 4
bindsym Group3+n nop heya from group 3
bindsym Group2+n nop heya from group 2
bindsym n nop heya
bindsym shift+N nop explicit shift binding
bindsym shift+r nop implicit shift binding
bindcode Group2+38 nop fallback overwritten in group 2 only
bindcode 38 nop fallback
…with the following layout:
setxkbmap -layout "us,ua,ru,de" -variant ",winkeys,,neo" \
-option "grp:shift_caps_toggle,grp_led:scroll" \
-model pc104 -rules evdev
By default (xkb group 1, us layout), pressing “n” will result in the
“heya” message appearing. Pressing “a” will result in the “fallback”
message appearing. “j” is not triggered.
By pressing Shift+CapsLock you switch to the next group (xkb group 2, ua
layout). Pressing “a” will result in the “fallback overwritten in group
2 only” message, pressing “n” will still result in “heya”. “j” is not
triggered.
In the next group (xkb group 3, ru layout), pressing “a” will result in
the “fallback” message again, pressing “n” will result in “heya”,
“j” is not triggered.
In the last group (xkb group 4, de_neo layout), pressing “a” will still
result in “fallback”, pressing “n” will result in “heya”, pressing “j”
will result in “heya from group 4”.
Pressing shift+n results in “explicit shift binding”, pressing shift+r
results in “implicit shift binding”. This ensures that keysym
translation falls back to looking at non-shift keys (“r” can be used
instead of ”R”) and that the order of keybindings doesn’t play a role
(“bindsym n” does not override “bindsym shift+n”, even though it’s
specified earlier in the config).
The fallback behavior ensures use-cases such as ticket #1775 are still
covered.
Only binding keys when the X server is in the corresponding XKB group
ensures use-cases such as ticket #585 are still covered.
1. Add a function writeall and make swrite wrap that function. Use either writeall or swrite, depending on whether we want to exit on errors or not.
2. Fix warnings when compiling with a higher optimisation level.
(CFLAGS ?= -pipe -O3 -march=native -mtune=native -freorder-blocks-and-partition)
Signed-off-by: hwangcc <hwangcc@csie.nctu.edu.tw>
If the mouse cursor is hidden (by unclutter, for example), then scrolling
in the window decoration creates an event with a child
(i.e. event->child != XCB_NONE). This causes route_click() to be called
with dest=CLICK_INSIDE, which prevents scrolling through a stacked layout.
To fix this, check if a click is in the window decoration _before_
checking if the event has a child.
Add the `--whole-window` switch for mouse bindings. This switch controls
what part of the container the pointer must be over to trigger a mouse
binding. The default is to only trigger mouse bindings over the
titlebars. With this switch, a mouse binding will be triggered over the
main part of the window as well.
This is a breaking change to the previous behavior, which would trigger
a mouse binding with a modifier over any part of the window.
fixes#1429
Do not set focused_id to XCB_NONE in route click to force resend focus,
in some cases to an already focused window.
Sending focus again on click is not necessary and may cause problems
with certain wine or mono apps. Resending focus makes combo boxes not
work in Office 2010.
This effectively reverts commit 250577da, so in case this commit causes
any problems with Eclipse to resurface, we’ll revert this commit in
favor of 250577da (the Eclipse-related bug fix).
A configured mouse binding (for example `bindsym button3 kill`) runs
its command when the mouse button is pressed over parts of a container.
If the binding has no modifer, it will only run when the button is
clicked on the window titlebar.
Otherwise if the binding has a modifier, it will run over the titlebar
or any part of the contained window.
fixes#558
This should be the last commit that formats a big bunch of files. From
here on, whenever I merge patches, I’ll run clang-format like described
in the title.
This has multiple effects:
1) The i3 codebase is now consistently formatted. clang-format uncovered
plenty of places where inconsistent code made it into our code base.
2) When writing code, you don’t need to think or worry about our coding
style. Write it in yours, then run clang-format-3.5
3) When submitting patches, we don’t need to argue about coding style.
The basic idea is that we don’t want to care about _how_ we write the
code, but _what_ it does :). The coding style that we use is defined in
the .clang-format config file and is based on the google style, but
adapted in such a way that the number of modifications to the i3 code
base is minimal.
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
Dan Elkouby