Tony Crisci [Tue, 7 Jan 2014 18:32:21 +0000 (13:32 -0500)]
i3bar Bugfix: don't show "EOF" status line error
When the `status_command` sends EOF, it is terminated. Terminating this
process prints an error message to the status line (hence, a race
condition). This error message is always more useful than the former
"EOF" status line error because it shows the exit code.
Tony Crisci [Wed, 8 Jan 2014 07:51:27 +0000 (02:51 -0500)]
i3bar: Amend status line error 127 message
Exit 127 can be returned by the shell when the command is not found or
when the `status_command` process returns 127 because of a missing C
library dependency.
Tony Crisci [Tue, 26 Nov 2013 10:46:10 +0000 (05:46 -0500)]
Movement into a branch considers movement direction
Change the behavior of movement into a branch with respect to the
position the moving con will be placed within the branch when the
movement is complete.
The correct position is determined by the direction of movement or the
position of the focused-inactive container within the branch.
If the direction of movement is the same as the orientation of the
branch container, append or prepend the container to the branch in the
obvious way. If the movement is to the right or downward, insert the
moving container in the first position (i.e., the leftmost or top
position resp.) If the movement is to the left or upward, insert the
moving container in the last position (i.e., the rightmost or bottom
position resp.)
If the direction of movement is different from the orientation of the
branch container, insert the container into the branch after the
focused-inactive container.
Tony Crisci [Sat, 4 Jan 2014 12:04:56 +0000 (07:04 -0500)]
Disable render-time pointer warps if asked
When `focus_follows_mouse` configuration option is disabled, do not warp
the pointer when focus changes outputs after rendering.
Rationale: this option is meant to be disabled by users who have a setup
where the mouse is usually in the way. These users tend to move the
mouse to a corner or use a utility to hide the pointer when it is not
active. When this user switches focus between outputs, the mouse is
placed in the center of the screen.
This is clearly against the spirit of disabling `focus_follows_mouse`.
Disabling this option now implies disabling "mouse follows focus".
Tony Crisci [Fri, 27 Dec 2013 03:00:06 +0000 (22:00 -0500)]
i3bar: Don't start child unless status_command
If a command is passed to `start_child` which is NULL, such as in the
case when there is no `status_command` specified in the bar config, do
not start a child process to listen on stdin.
Tony Crisci [Sat, 21 Dec 2013 19:29:22 +0000 (14:29 -0500)]
Snap pointer to resize bar on drag resize
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)
Tony Crisci [Thu, 26 Dec 2013 05:30:21 +0000 (00:30 -0500)]
i3bar: Set `mapped` flag on trayclient creation
When a trayclient is first created as a structure in memory, explicitly
set the `mapped` flag to false. Otherwise it may initialize to `true` in
some circumstances without actually being mapped, causing a request to
be mapped from the client to be ignored.
Create the trayclient in memory before handling a request to be mapped
immediately.
only LOG() the DPI when it changes, DLOG() it otherwise (Thanks lkraav)
This avoids flooding stdout every time some text (e.g. a window
decoration) is drawn, yet leaves the message in place when it’s actually
relevant (upon DPI changes).
dragging: instead of using a custom event loop, use libev
This is done by installing a new check watcher that replaces the main
X11 event handler and calling ev_run with EVRUN_ONCE until the dragging
loop left state DRAGGING.
With this commit, other handlers, most notably the redraw handler for
placeholder windows, get a chance to run when dragging (placeholder!)
windows around.
state->initial is set to false before calling x_push_node() since we
began pushing the window stack before pushing changes. Therefore, the
condition could never be true.
Tony Crisci [Sun, 15 Dec 2013 09:21:18 +0000 (04:21 -0500)]
i3bar: Print error message when status_command fails
Add a function to i3bar to print an error message in the status line
when the child process invoked by status_command fails to provide
input that can be displayed as a statusline.
When the child provides JSON that cannot be parsed, alert the user and
convey a short message provided by yajl communicating the specific
problem.
When the child (or the shell executing the status command) exits
unexpectedly, alert the user and display the exit code. The cases where
the status command is not executable or not found in the user's PATH are
treated specially.
Tony Crisci [Mon, 2 Dec 2013 23:06:19 +0000 (18:06 -0500)]
Testcases: init pointer in a predictable position
Tests may disturb the pointer in their normal operation that may lead to
unexpected results in later tests using that display. Reset the pointer
before a test begins to (0, 0) to save test developers from related
"gotchas" and reduce multi-monitor test boilerplate.
Tony Crisci [Mon, 2 Dec 2013 16:23:52 +0000 (11:23 -0500)]
Refactor and improve test 514
Split test 514's assertion into three assertions to make it more
explicit what is being tested, and why a run might fail.
Move critical test code out of the event handler to clarify flow and
allow a query of the actual current workspace to use in assertions.
Works around an issue which caused this test to fail spurriously because
of pointer-related quirks in the i3 test suite which would sometimes
cause i3 to open on workspace 2 (However, the test is now agnostic to
the initial workspace or output).
Tony Crisci [Sun, 24 Nov 2013 04:09:01 +0000 (23:09 -0500)]
i3bar: Realign tray clients on map/unmap notify
UnmapNotify events are interpreted by i3bar as an action taken by an
application to hide its tray window. Likewise, MapNotify events are
interpreted as an action taken by by an application to show its tray
window.
The actual cause of these events may be the application itself, or the
result of some action taken by i3bar itself at the request of the
application in the course of the XEmbed protocol.
We respond by adjusting the size of the tray window and realigning any
tray clients that remain. This will make room for the mapping window or
close the gap left by the unmapping window when the bar is redrawn.
Lancelot SIX [Thu, 21 Nov 2013 21:03:49 +0000 (22:03 +0100)]
Remove references to PATH_MAX macro
Since the macro PATH_MAX is not defined on every system (GNU/Hurd being
one of those who do not define it), we remove all references to this
macro. Instead, we use a buffer of arbitraty size and grow it when
needed to contain paths.
persist root window’s background contents to a pixmap
The commit title is fairly technical, so I’ll try to explain.
Recently, users of GDM3 (I’m sure) and LightDM (I think) have reported
that when switching to a new workspace, the contents of the previous
workspace are still visible. i3bar updates, though, so it is the X11
root window which is not being updated here.
When using GDM3, X11 will be started with -background none, and no
background pixmap or pixel is set. Then, apparently,
gnome-settings-daemon will display a fade animation from whatever is
currently on the window to the destination contents. I think this is to
avoid flickering when logging in, which would occur when just setting a
specific background pixmap or pixel.
So, this commit will, when i3 starts first (not on restarts), copy the
contents of the X11 root window (typicall a grey background, at least on
my machine with GDM3) into a pixmap and set that pixmap as background
pixmap. That way, the content will be preserved and one has a
background, instead of what is perceived as a bug :).
This commit has some chance of breakage, so I’m prepared to revert it
unless we can figure out the issues and roll forward.
According to the XEmbed protocol specification, this is one way for a
tray client to finish the protocol. After this event is received, i3bar
should have no more interaction with the tray client.
Tony Crisci [Fri, 22 Nov 2013 15:00:49 +0000 (10:00 -0500)]
Remove-child callback skips output content cons
Every container 'above' (in the hierarchy) the workspace content should
not be closed when the last child was removed.
Add a check for output content containers and do not handle them. These
cons are at the root of the output container with dockarea siblings.
They may be run through this callback when an output is killed with
RandR.
Fixes an issue that caused content cons to become urgent when the output
is killed with RandR.