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.
Drew DeVault
Calvin Lee
Scott Anderson
JerziKaminsky
Jarkko Oranen
Zandr Martin
Jaanus Torp
Sebastian Noack
John Chen