| Age | Commit message (Collapse) | Author |
|---|
|
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).
|
|
|
|
|
|
Also, fix a small typo.
|
|
Adds support for bindings like:
bindsym button3 floating toggle
bindsym $mod+button3 floating toggle
|
|
|
|
|
|
|
|
This doesn't work, I'm not sure why. The color structs definitely get
changed but if you specify fewer than 5, it renders with the defaults.
|
|
|
|
|
|
Ref #2
|
|
|
|
|
|
fixes issue#1182
|
|
Use i3's dimensions for initial scratchpad views
|
|
Prevent sway from duplicating on a failed fork
|
|
See https://github.com/i3/i3/blob/master/src/scratchpad.c#L196-L197
|
|
Also remove a useless `sway_log` and replace it with a pipe
|
|
|
|
- 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add libcap check to CMake
|
|
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.
|
|
ordering
|
|
|
|
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
|
|
|
|
If stdout is a tty, it will pretty print unless -r (--raw) is given.
Sample outputs:
```
~/s/s/build > ./bin/swaymsg fullscreen toggle
Error: Permission denied for fullscreen toggle via IPC
~/s/s/build > ./bin/swaymsg -t get_workspaces
Workspace 3:三
Output: DVI-I-1
Layout: splith
Workspace 1:一 (off-screen)
Output: HDMI-A-1
Layout: splith
Workspace 5:五 (focused)
Output: HDMI-A-1
Layout: splith
~/s/s/build > ./bin/swaymsg -t get_inputs
Input device Metadot - Das Keyboard Das Keyboard
Type: Keyboard
Sway ID: 9456:320:Metadot_-_Das_Keyboard_Das_Keyb
Input device Wacom Intuos S 2 Pen
Type: Tablet tool
Sway ID: 1386:827:Wacom_Intuos_S_2
Input device Wacom Intuos S 2 Pad
Type: Tablet pad
Sway ID: 1386:827:Wacom_Intuos_S_2
Input device Logitech Gaming Mouse G502
Type: Keyboard, Mouse
Sway ID: 1133:49277:Logitech_Gaming_Mous
~/s/s/build > ./bin/swaymsg -t get_outputs
Output DVI-I-1
Geometry: 1920x1080 @ 3840,0
Scale factor: 1x
Workspace: 3:三
Output DVI-D-1
Geometry: 1920x1080 @ 0,0
Scale factor: 1x
Workspace: 4:四
Output HDMI-A-1
Geometry: 1920x1080 @ 1920,0
Scale factor: 1x
Workspace: 5:五
```
|
|
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.
|
|
I believe this fixes #1102
|
|
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.
|
|
|
|
|
|
|
|
as title
|
|
|
