Don't send mouse button escapes to a mouse grabbing client when the
cursor is outside the grid (i.e. when it is inside the margins).
Also don't do *any* kind of selection when the cursor is outside the
grid. Previously, we only checked this for selection_start(), but
e.g. double clicking would run selection_extend(), or
selection_mark_word() etc.
Previously, the selection was only updated when the mouse cursor was
inside the grid. This makes it difficult to e.g. do large selections
fast, since you often end up moving the cursor outside the grid, or
outside the terminal window even.
Now, we update the selection regardless of *where* the cursor is. This
is done by bounding the row/col we pass to 'selection_update()' to the
grid, while still setting the seat's row/col to -1 when the cursor is
outside the grid, to ensure the xcursor etc are set correctly.
Care must also be taken to *not* pass any motion events to a mouse
grabbing client, when the cursor is outside the grid.
Closes#70.
This fixes an issue where the col/row were incorrectly set to 0
instead of -1, when the mouse cursor was inside the grid margins.
This resulted in e.g. the mouse cursor having the wrong shape, and
foot incorrectly handling mouse events as if they were inside the
grid.
Foot is a Wayland client and cannot be run outside of a Wayland
session. As such, it makes more sense to use $WAYLAND_SESSION instead
of $XDG_SESSION_ID in the default socket path since this makes it
clearer which Wayland session we belong to.
Closes#55.
The documentation incorrectly stated that the default path is
$XDG_RUNTIME_DIR/foot.sock.
The correct default path is
* $XDG_RUNTIME_DIR/foot-$XDG_SESSION_ID.sock
* $XDG_RUNTIME_DIR/foot-no-session.sock
* /tmp/foot.sock
Depending on whether XDG_RUNTIME_DIR and XDG_SESSION_ID has been set
or not.
This also removes the '<>' from the default when XDG_SESSION_ID is not
set.
Closes#53.
This reverts commit 027a8de6f5.
I was a bit quick on this one, and only tested error cases. Turns out,
this causes foot to hang in a blocking read(3) on the event FD.
This is because while the FD has FD_CLOEXEC, that flag is per file
descriptor. I.e. the forked copy of the event fd is closed when we
exec(), but since this isn't a pipe, nothing is signaled to the parent
process, which thus remains blocking in read(3) since its copy of the
event fd hasn't been closed.
We _could_ write a dummy value on the event fd just before exec(), but
then we wouldn't be able to catch errors from exec() self - only
errors *before* exec().
Replace the pipe we used to communicate errors after fork(), but
before exec() to the parent process with an event FD.
The overhead in the kernel is much lower to setup an event fd,
compared to a pipe.
Since we need to restore the status flags anyway, there's nothing to
gain from emitting the user notifications after dup:ing the pts file
descriptor.
On the other hand, emitting user notifications *before* dup:ing means
we can still print error messages for e.g. write(3) errors.
We (need to) set O_NONBLOCK on the pts file description before
emitting the user-notifications, to ensure we don't block in write(3).
However, since file status flags are per *file*, not per
file *descriptor*, this ends up setting O_NONBLOCK on the dup:ed
stdin/stdout/stderr file descriptors too.
Not all clients want this, or can handle this.
Thus we need to restore the original flags before exec:ing the client.
This fixes "makepkg" build failures.
The main process is blocking and waiting for us to close the error
pipe (in exec(3), via O_CLOEXEC).
Thus, pts data will *not* be processed until we've exec:d the shell.
Because of this we must not write too much and block in write(3). Do
this by setting O_NONBLOCK on the pts fd (*after* dup:ing it to
stdin/stderr/sdout) and watch for EAGAIN EWOULDBLOCK.
When enabled, the mouse cursor is hidden when the user types in the
terminal. It is un-hidden when the user moves the mouse, or when the
window loses keyboard focus.
