handle ButtonPress events with child != XCB_NONE (Thanks xeen)
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.
Steve Jones [Sat, 1 Feb 2014 16:09:51 +0000 (16:09 +0000)]
Set EWMH desktop properties on startup.
Calls ewmh_update_current_desktop on startup to set the
_NET_CURRENT_DESKTOP property. Without this change the property only
gets set after the workspaces have been manipulated. Also exclude
hidden workspaces (i.e. those starting with "__" from the workspace
index.
Tony Crisci [Tue, 4 Feb 2014 15:52:52 +0000 (10:52 -0500)]
Document the existence of a C ipc project
Add a link to https://github.com/acrisci/i3-ipc which is a new ipc
library in the design phase of development. When it is stable, it will
provide bindings to many high-level scripting languages with
GObject-introspection.
This project aims to replace the unmaintained Python library and offer
an ipc library in new languages such as Lua and JavaScript.
Tony Crisci [Sun, 19 Jan 2014 15:22:50 +0000 (10:22 -0500)]
Do not create container pixmap when not needed
The pixmap of a borderless container will not be used (except for the
titlebar in a stack or tabs). Make sure these containers do not have a
pixmap because it can only get in the way.
Tony Crisci [Wed, 15 Jan 2014 02:16:54 +0000 (21:16 -0500)]
Respect Motif hint for window decorations
When the _MOTIF_WM_HINTS property of a window specifies it should have
no title bar, or no decorations at all, respond by setting the border
style of that container to BS_PIXEL or BS_NONE respectively.
This comes from the old Motif window manager. It was originally intended
to specify exactly what sort of decorations a window should have, and
exactly what sort of user input it should respond to. The EWMH spec
intended to replace Motif hints with _NET_WM_WINDOW_TYPE, but it is
still in use by popular widget toolkits such as GTK+ and Java AWT.
i3's implementation simply mirrors Gnome's Metacity. Official
documentation of this hint is nowhere to be found.
For more information see:
https://people.gnome.org/~tthurman/docs/metacity/xprops_8h-source.html
http://stackoverflow.com/questions/13787553/detect-if-a-x11-window-has-decorations
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.
projects / i3 / i3 / log