https://www.x.org/releases/current/doc/kbproto/xkbproto.html#Detectable_Autorepeat
Detectable autorepeat should only affect --release bindings. Currently,
when a user keeps a key pressed, we get multiple KeyPress and KeyRelease
events. With this change, we still get multiple KeyPress events, which
means that you can still keep a key pressed to repeatedly execute a
normal binding, but only one KeyRelease event when the key is physically
released.
Unfortunately, this change is not currently testable because detectable
autorepeat doesn't seem to work under Xephyr. AwesomeWM experienced the
same problem:
6f2424e901Fixes#3306
The current text is confusing. '--no-auto-back-and-forth' doesn't
disable the 'workspace back_and_forth' command, the flag is not even
valid for that command.
X will not allow a window with ParentRelative background to be created
or reparented under a window with mismatching color depth.
Deal with this by destroying the container frame and creating a new one
with the right depth upon swallowing.
Defer destruction of the frame window until after the updated tree has
been rendered to avoid some distracting flickering.
Fixes#3297
This fixes a new warning from GCC 8.1, -Wstringop-truncation:
https://gcc.gnu.org/gcc-8/changes.htmlhttps://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Warning-Options.html#index-Wstringop-truncation
Replacing with memcpy is what gcc suggests:
> As another example, the following call to strncpy results in copying
> to d just the characters preceding the terminating NUL, without
> appending the NUL to the end. Assuming the result of strncpy is
> necessarily a NUL-terminated string is a common mistake, and so the
> call is diagnosed. To avoid the warning when the result is not
> expected to be NUL-terminated, call memcpy instead.
> void copy (char *d, const char *s)
> {
> strncpy (d, s, strlen (s));
> }
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.
- Align right border
- Add a missing '/' in libsn's and util-xrm's link for consistency
- Replace wrong character for border next to pango's min version
- Correct the Pod::Simple link
When moving a workspace to the current output by way of a rename, if the
current workspace is empty, it will be removed by `workspace_show`.
Attempting to restore focus to this removed workspace causes a crash.
Follow the pattern in workspace.c:996 to only restore the original focus if the
original workspace still exists.
Add a test to ensure that the renamed workspace moves to its appropriate
output and that a crash does not occur.
Fixes#3228
handle_screen_change() and handle_configure_notify() call
randr_query_outputs() where root_output is not initialized because
randr_init() is never called when config.fake_outputs is not NULL.
When we don't modify the focus we aren't risking giving focus to a
container behind the current fullscreen one.
_con_move_to_con can with ignore_focus is called through the swap
command or through con_move_to_workspace for floating containers. This
change shouldn't break the expectations of the callers there.
Fixes issue #3259.
This is enough to fix the crash discussed in #3259 even though the next
commit can fix it independently. This commit is useful because it
generally makes sense to abort the command when the first call to
_con_move_to_con fails.
- 'border toggle' now accepts an optional pixel argument which will be
ignored when switching to BS_NONE.
- 'border pixel' now defaults to 1 pixel instead of 2.
- Calling 'border normal' or 'border pixel' will use the configured
default_border_width if one exists. Also applies to floating windows.
Fix the issue #3227(https://github.com/i3/i3/issues/3227).
1).Make cmd_scratchpad_show() use the information coming from scratchpad_show().
2).Add a test case 298-scratchpad-show.t.
Was used for the removed option 'terminal' and for 'font'. 'font' is no
longer this aggressive and doesn't use the macro.
Killing i3 when an option is missing would be super backwards
incompatible so I doubt we are going to use this ever again.
When i3bar is called with the -V flag but there is no 'verbose yes'
directive in the bar {} config, the verbosity config value is reset.
This will introduce the opposite, negligible issue: you can't disable
i3bar's verbosity by deleting the 'verbose yes' directive in the bar {}
config. To fix this we would need an enum for config.verbose.
Closes#3220.
Orestis Floros