| Age | Commit message (Collapse) | Author |
|---|
|
Ids of children, by order of focus
|
|
Still missing: focus
|
|
Also: fix a small memory leak
|
|
`workspace_next_name` parses workspace commands to find the default
workspace names. It handled " " as a separator, which prevents the use
of workspace names with spaces.
|
|
The command parsing did not handle workspaces with spaces in their name
(like it's done in `cmd_workspace`)
|
|
Fix github links in doc
|
|
|
|
Plugs memory leaks during failure of the output command and in other
circumstances and fixes `bg` option.
Fixes #1381
|
|
All variables without a $ prefix lost their last character due to off by one error
|
|
|
|
|
|
|
|
|
|
Added client write buffer and handler for writable status on client
socket.
|
|
When killing views with `close_views` a use-after-free can sometimes
occur because parent views are killed before their children. This commit
makes `container_map` run functions on child containers before their
parent, fixing the race.
Fixes #1302
|
|
|
|
|
|
|
|
|
|
And remove it from the build
|
|
Policy allocation failure is non-fatal
|
|
|
|
|
|
|
|
|
|
And probably some other stuff too
|
|
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).
|
|
|
|
|
|
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.
|
|
|
