This commit implements the StatusNotifierItem protocol, and enables
swaybar to show tray icons. It also uses `xembedsniproxy` in order to
communicate with xembed applications.
The tray is completely optional, and can be disabled on compile time
with the `enable-tray` option. Or on runtime with the bar config option
`tray_output none`.
Overview of changes:
In swaybar very little is changed outside the tray subfolder except
that all events are now polled in `event_loop.c`, this creates no
functional difference.
Six bar configuration options were added, these are detailed in
sway-bar(5)
The tray subfolder is where all protocol implementation takes place and
is organised as follows:
tray/sni_watcher.c:
This file contains the StatusNotifierWatcher. It keeps track of
items and hosts and reports when they come or go.
tray/tray.c
This file contains the StatusNotifierHost. It keeps track of
sway's version of the items and represents the tray itself.
tray/sni.c
This file contains the StatusNotifierItem struct and all
communication with individual items.
tray/icon.c
This file implements the icon theme protocol. It allows for
finding icons by name, rather than by pixmap.
tray/dbus.c
This file allows for asynchronous DBus communication.
See #986#343
Increase _POSIX_SOURCE value where needed.
Increase _XOPEN_SOURCE value where needed.
Conditionally link to libcap (only on Linux).
Possibly some trailing whitespace fixes (automatic).
- When policies are allocated, the ipc target path goes
through symlink resolution. The result is used as
the canonical for matching pids to policies at runtime.
In particular, this matches up with the target of
the `/proc/<pid>/exe`.
- There's a possible race condition if this isn't done
correctly, read below.
Originally, validate_ipc_target() always tried to resolve
its argument for symlinks, and returned a parogram target string
if it validates. This created a possible race condition with
security implications. The problem is that get_feature_policy()
first independently resolved the policy target in order to check
whether a policy already exists. If it didn't find any, it called
alloc_feature_policy() which called validate_ipc_target() which
resolved the policy target again. In the time between the two
checks, the symlink could be altered, and a lucky attacker could
fool the program into thinking that a policy doesn't exist
for a target, and then switch the symlink to point at another file.
At the very least this could allow him to create two policies
for the same program target, and possibly to bypass security
by associating the permissions for one target with another,
or force default permissions to apply to a target for which
a more specific rule has been configured. So we don't that.
Instead, the policy target is resolved once and that result is
used for the rest of the lookup/creation process.
In i3 every mark is unique and one mark cannot be used in more than one
window, sway behavior has been amended to match this.
`swaymsg -t get_marks` will now return an array of all marks used in sway.
See #98
- Moved ``<sys/capability.h>`` include inside `__linux__` guard,
because all uses are similarly guarded.
- <sys/capability.h> is part of an optional devel package, at least
in fedora. CMake now explicitly checks that libcap devel files
are available.
- Added libcap to the list of install packages in .travis.yml, to
make the dependency explicit. travis-ci installs the package by
default, which is why this hasn't surfaced previously.
This commit changes how commands decide what container to act on.
Commands get the current container though `current_container`, a global
defined in sway/commands.c. If a criteria is given before a command,
then the following command will be run once for every container the
criteria matches with a reference to the matching container in
'current_container'. Commands should use this instead of
`get_focused_container()` from now on.
This commit also fixes a few (minor) mistakes made in implementing marks
such as non-escaped arrows in sway(5) and calling the "mark" command
"floating" by accident. It also cleans up `criteria.c` in a few places.
This commit adds three commands to sway: `show_marks`, `mark` and
`unmark`. Marks are displayed right-aligned in the window border as i3
does. Marks may be found using criteria.
Fixes#1007
Fixes#1120
When the parent of a view is C_WORKSPACE and the movement direction
is either MOVE_PREV or MOVE_NEXT, the code would attempt to move the
views to the next output, but swayc_adjacent_output can't accept
non-directional movement commands and causes undefined behaviour and
a segfault.
If the code is simply skipped, we end up in an infinite loop.
Instead, we can allow containers whose parent is a C_WORKSPACE take the
path that handles MOVE_PREV and MOVE_NEXT, which behaves as you would
expect.
I'm not certain that this fix is entirely correct as the desired behaviour
of move_container is not very well defined, but it seems to work.
Hardcoding it to L_HORIZ does not make sense to me,
as you get the unexpected behaviour that windows will be
arranged horizontally until you switch the layout.
As best I can tell this todo was intended to add workspace movement to
the given output with the `workspace <ws> output <op>` command, but i3
does not behave this way.
This commit allows unquoted spaces in worspace names in order to keep
compatability with i3. The names _must not_ contain the string "output"
which is documented in 'sway.5' because how sway detects the `move
<workspace> output <output>` command. Also I documented that "number"
may be used before the worspace name without affecting how the name is
evaluated.
This commit lets the 'move' command apply to floating containers as well
as tiled ones. The command may be appended with a number of pixels and
then optionally the string `px` (like '10 px') in order to move the
container more or fewer than the standard ten pixels.
Previous implementation would not preserve dimension of groups
along the major axis. This should avoid weird behavior when
using container motion commands.
This fixes issue #733. Now if the user focuses output right but is at
the rightmost monitor, the focus will wrap the the leftmost monitor.
This commit adds a new function, swayc_opposite_output, which selects
the opposite output given a position and a direction. Now, when calling
output_by_name, we first check if there is an adjacent output to switch
to. If that fails, we call swayc_opposite_output to handle wrapping.
- "layout auto_left|auto_xxx" are now "layout auto xxx"
- "layout incmaster <n>" is now "layout auto master [set|inc] <n>"
- "layout incncol <n>" is now "layout auto ncol [set|inc] <n>"
- prior to this modification, the requested pixels were added/removed
to both edges of the modified container. To preserve sizes,
only half the pixels should be added/removed to each edge.
- added L_AUTO_FIRST/LAST instead of using explicit layouts.
- when switching between auto layout that don't share the same major axis, invert the
width/height of their child views to preserve their relative proportions.
Don't switch the internal tracking of focus to the swaylock surface,
to allow for switching back to the previously active window (or the
currently active window, if some new process changed).
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
When destroying lock surfaces, we really should only unlock a
desktop_shell if the set of lock surfaces has dropped to zero (since
callers need to do a set_lock_surface for every output).
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Exherbo installs architecture dependent data in a different place than architecture
independent data. More concretely: binaries go in /usr/$chost/{bin,lib},
data goes in /usr/share and configs in /etc, /etc is already configurable
through CMAKE_INSTALL_FULL_SYSCONFDIR but the datadir was not. This
patch fixes it so that things can be pushed in the right places.
- Make sure CMake always finds absolute paths for Cairo, Pango and GdkPixbuf
- Add forgotten json-c include path to swaymsg/CMakeLists.txt
- Disable -Werror because of assert warnings
- Add correct /proc/pid/file path for FreeBSD
- Use libepoll-shim on FreeBSD
- Only use Linux capabilities on, well, Linux
For workspace containers, swayc_change_layout also changes ->layout alongside
->workspace_layout when it's a sensible thing to do. There is an additional test
for 'layout toggle' command which ensures that containers will be tiled
horizontally after toggling from tabbed or stacked.
If workspace layout is set to tabbed or stacked, its C_VIEW children
should get wrapped in a container. Alongside that, move_container was
modified to retain previous functionality.
LD_PRELOAD enables keyloggers to easily be made. This solution isn't
perfect - really a secure system wouldn't have LD_PRELOAD at all. It was
a stupid idea in the first place.
Some users may want to switch buttons on their input devices, turns out
libinput already supports it. Let's add a support for it in our config.
Signed-off-by: Michał Winiarski <knr@hardline.pl>
This does two important things when using alpha:
1. At corners, borders don't double in opacity
2. Foreground elements (text) can be made transparent and you can see
fully through to the wallpaper
Add swayc_change_layout function, which changes either layout or
workspace_layout, depending on the container type. Workspace being
always L_HORIZ makes this much more i3-compatible.
This is necessary because commands in the config file (mode for
instance) emit ipc events, and if ipc_init has not been called the
ipc_clients_list is not initialized, and we segfault. This fixes that
bug.
This implements commands such as:
workspace number 9: test
If a workspace with the given number exists then it will be focused,
otherwise a new workspace with the given name will be created.
When using a bar on a named output, load_swaybars() requires the
output to be active (ie. in the root container), but this is not the case if
the bar is added to the last output. To fix this, load_swaybars() is now
called after the output has been added to the root container.
After fixing that, swaybar would segfault due to using the wrong index
variable when loading outputs and config.
Indicator border color is now used only when a container is the only
child. Reason for the change? i3 does it this way. Sway container
borders are now a bit more similar to i3 ones.
This patch makes it possible to move views between outputs using the
`move left|right|up|down` commands.
It behaves similar to i3 with one important difference. The focus will
always follow the view being moved, unlike i3 where the focus doesn't
always follow the view to a new output (I assume that's a bug in i3).
`vertical` and `horizontal` should be swapped.
If border_left and border_right were set to 0, the vertical borders
instead of the horizontal borders would be hidden.
i3 handles this command equally.
Fixes#819. If workspace is focused and command 'move container to
workspace/output' is issued, workspace child containers are wrapped in a
new container and moved according to command.
This is a feature that can't work the same as i3, because there is no
real window classes in wayland. This way, we avoid null titles as much
as possible.
When workspace_auto_back_and_forth is enabled, workspaces get switched
twice with previously mentioned command, which is not the expected
behavior.
Removes one redundant creation of previous workspace.
Focus the container on the output (not the output itself) when an output is
focused.
This is intended to fix a bug where borders are not updated correctly when
switching the vt away/back to sway.
When switching back to a workspace after new window creation, it is now
necessary to descend the focus stack into the focused container of the
workspace to determine which container should get the focus. This is because
the `set_focused_container()` function no longer automatically descends into
the focus stack to find the correct view to focus.
Replace `update_view_border()` with `update_container_border()`. The latter
should handle both the case where the container is a view or if the container
has children.
The previous implementation of focus handling assumed that only views can be
focused. Containers can also be focused with a command like `focus parent` or
`focus child`.
Change `set_focused_container()` to handle the case of the given container
being a container with children and update borders accordingly.
Deeply nested containers which had their layouts changed didn't update
their actual_geometry, this messed up their child containers. Those got
width and height of 0, which was then decreased for stacked/tabbed
containers by title height. Underflow ensued, these containers suddenly
had height 4294967273. In short, not updating actual_geometry didn't
play nicely with nested containers.
When titlebar is hidden, top border of the topmost view inside
tabbed/stacked container will not be drawn. This is changed in layout.c
On the other hand, top border should be drawn sometimes, for example
when titlebar is hidden on a view that is not the topmost inside
tabbed/stacked container. This is changed in border.c
Previously, cmd_kill only closed a focused view, while containers were
not affected. Now it closes all views that are children of the focused
container.
Whenever a stacked or tabbed container has focused, paint the titlebars of all
its child windows to be focused as well to indicate the parent stack/tab
container has the focus.
