Orestis Floros [Tue, 21 Aug 2018 18:10:02 +0000 (21:10 +0300)]
Call dragloop callback on DRAG_SUCCESS
A race condition is possible. For example, if we first receive a
XCB_MOTION_NOTIFY event and then, while drain_drag_events is still
running, a XCB_BUTTON_RELEASE event the first event is never handled
because we return.
Orestis Floros [Tue, 21 Aug 2018 18:06:00 +0000 (21:06 +0300)]
floating_drag_window: return on DRAG_REVERT
Right now tree_render() is called twice on DRAG_REVERT since
floating_reposition calls it.
Also, on DRAG_REVERT the scratchpad state shouldn't change since the
user canceled the action.
Kill misbehaving subscribed clients instead of hanging
This change only affects clients that are subscribed to events, which
should be the main cause of our problems.
In the common case (no buffered data) the behaviour doesn't change at
all: the message is sent directly, no ev_io / ev_timeout callback is
enabled. Once a write to a client's socket is not completed fully
(returns with EAGAIN error), we put the message in the tail of a queue
and init an ev_io callback and a corresponding timer. If the timer is
triggered first, the socket is closed and the client connection is
removed. If the socket becomes writeable before the timeout we either
reset the timer if we couldn't push all the buffered data or completely
remove it if everything was pushed.
We could also replace ipc_send_message() for all client connections in
i3, not just those subscribed to events.
Furthermore, we could limit the amount of messages stored and increase
the timeout (or use multiple timeouts): eg it's ok if a client is not
reading for 10 seconds and we are only holding 5KB of messages for them
but it is not ok if they are inactive for 5 seconds and we have 30MB of
messages held.
This was introduced in 252db3b8c (#3245). That commit moved the
con_activate line inside the loop, meaning it wouldn't always be called.
When the mouse moved after a rename with focus_follows_mouse enabled,
check_crossing_screen_boundary (src/handlers.c:111) called
con_descend_focused that used the wrong focus order.
I also change con_activate to con_focus since we don't really want to
raise floating containers there.
Orestis Floros [Wed, 28 Mar 2018 01:05:48 +0000 (04:05 +0300)]
Use get_assigned_output for numbers
This prohibits the usage of workspaces assigned to other outputs in
create_workspace_on_output.
Eg, with config:
workspace 1 output fake-0
workspace 2 output fake-0
and 2 screens workspace 2 would be used for the second screen even
though it is assigned to the first one.
Also introduces a test for workspace assignments that includes the case
described above and some tests that don't fail in the next branch.
Orestis Floros [Wed, 28 Mar 2018 00:35:40 +0000 (03:35 +0300)]
Introduce get_assigned_output
This also replaces code in create_workspace_on_output() that is
theoretically more efficient but:
1. It isn't a huge difference since it depends on the number of outputs,
that shouldn't be high.
2. get_assigned_output will be modified and used for #555, then its
logic should be followed in create_workspace_on_output() too.
Another note for create_workspace_on_output: if assigned is not NULL the
condition (assigned != output->con) should never be false, ie if there
is an assigned output to this name, it isn't the current one. This
happens because the current callers check for assignments before calling
create_workspace_on_output().
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:
https://github.com/awesomeWM/awesome/commit/6f2424e90170be4acaa1d140f966ab6bb8a4d217
Orestis Floros [Sat, 2 Jun 2018 14:58:10 +0000 (17:58 +0300)]
docs: link workspace_auto_back_and_forth from workspace command
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.
Dan Elkouby [Fri, 1 Jun 2018 15:55:35 +0000 (18:55 +0300)]
Reframe swallowed windows if depth doesn't match
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.
Orestis Floros [Tue, 8 May 2018 14:05:46 +0000 (17:05 +0300)]
Replace strncpy call with memcpy when result is not NUL-terminated
This fixes a new warning from GCC 8.1, -Wstringop-truncation:
https://gcc.gnu.org/gcc-8/changes.html
https://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));
> }
Dan Elkouby [Sat, 5 May 2018 10:30:48 +0000 (13:30 +0300)]
Activate the focused child when scrolling over tab/stack decorations
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.
Orestis Floros [Tue, 1 May 2018 10:49:55 +0000 (13:49 +0300)]
Fix DEPENDS table
- 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
Oliver Graff [Tue, 1 May 2018 08:25:13 +0000 (04:25 -0400)]
Don't refocus a workspace cleaned up by `workspace_show` during rename
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.
Fix: ConfigureNotify can crash i3 with fake-outputs
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.
Don't call con_fullscreen_permits_focusing with ignore_focus
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.
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.
i3bar: don't reset verbosity when parsing config values
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.
projects / i3 / i3 / log