| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
|
|
|
| |
Sway sets a default status_command which runs date every second. This
patch removes this behaviour so the user can have a NULL status bar if
desired.
I had to swap swaybar's event_loop_poll and wl_display_flush so that it
would map the initial surface.
|
| |\
| |
| | |
Reload config using idle event
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch makes it so when you run reload, the actual reloading is
deferred to the next time the event loop becomes idle. This avoids
several use-after-frees and removes the workarounds we have to avoid
them.
When you run reload, we validate the config before creating the idle
event. This is so the reload command will still return an error if there
are validation errors. To allow this, load_main_config has been adjusted
so it doesn't apply the config if validating is true rather than
applying it unconditionally.
This also fixes a memory leak in the reload command where if the config
failed to load, the bar_ids list would not be freed.
|
| |\
| |
| | |
Shim client.background and client.placeholder
|
| |/
|
|
|
|
|
| |
These are not supported by sway, but are valid i3 commands and should not
cause config errors.
Also includes a couple of minor touch-ups.
|
| | |
|
| |\
| |
| | |
swaynag: fix use-after-free in wl_display_dispatch
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When destroying swaynag from within wl_display_dispatch, we cannot
disconnect the display as that will free the queue's event_list.
Free it after running the loop instead.
Fixes this use-after-free:
==7312==ERROR: AddressSanitizer: heap-use-after-free on address 0x612000000110 at pc 0x000000412a9f bp 0x7ffd4e811760 sp 0x7ffd4e811750
READ of size 8 at 0x612000000110 thread T0
#0 0x412a9e in wl_list_empty ../common/list.c:206
#1 0x7f5b58f0d42f in dispatch_queue src/wayland-client.c:1572
#2 0x7f5b58f0d42f in wl_display_dispatch_queue_pending src/wayland-client.c:1815
#3 0x40f465 in swaynag_run ../swaynag/swaynag.c:390
#4 0x407576 in main ../swaynag/main.c:123
#5 0x7f5b58bb9412 in __libc_start_main ../csu/libc-start.c:308
#6 0x404a3d in _start (/opt/wayland/bin/swaynag+0x404a3d)
0x612000000110 is located 208 bytes inside of 320-byte region [0x612000000040,0x612000000180)
freed by thread T0 here:
#0 0x7f5b594ab480 in free (/lib64/libasan.so.5+0xef480)
#1 0x40faff in swaynag_destroy ../swaynag/swaynag.c:454
#2 0x40cbb4 in layer_surface_closed ../swaynag/swaynag.c:82
#3 0x7f5b583e1acd in ffi_call_unix64 (/lib64/libffi.so.6+0x6acd)
previously allocated by thread T0 here:
#0 0x7f5b594aba50 in __interceptor_calloc (/lib64/libasan.so.5+0xefa50)
#1 0x7f5b58f0c902 in wl_display_connect_to_fd src/wayland-private.h:236
(you need a wayland compiled with asan, my wl_list hack, or running
with valgrind to see this trace)
|
| |\
| |
| | |
swaybar: fix binding to wl_pointer multiple times
|
| | | |
|
| |\ \
| |/
|/| |
ipc: set "type" of floating containers to "floating_con"
|
| |/ |
|
| |\
| |
| | |
Fix swaylock w/shadow on glibc, improve security
|
| |/
|
|
|
|
|
|
|
| |
Today I learned that GNU flaunts the POSIX standard in yet another
creative way. Additionally, this adds some security improvements,
namely:
- Zeroing out password buffers in the privileged child process
- setuid/setgid after reading /etc/shadow
|
| | |
|
| |\
| |
| | |
Move sticky containers when switching workspace via criteria
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Create a view on workspace 1
* Switch to workspace 2 (on the same output) and create a floating
sticky view
* Use criteria to focus the view on workspace 1
Previously, we only moved the sticky containers when using
workspace_switch, but the above method of focusing doesn't call it. This
patch relocates the sticky-moving code into seat_set_focus_warp.
A side effect of this patch is that if you have a sticky container
focused and then switch workspaces, the sticky container will no longer
be focused. It would previously retain focus.
In seat_set_focus_warp, new_output_last_ws was only set when changing
outputs, but now it's always set. This means new_output_last_ws and
last_workspace might point to the same workspace, which means we have to
make sure we don't destroy it twice. It now checks to make sure they're
different, and to make this more obvious I've moved both calls to
workspace_consider_destroy to be next to each other.
|
| |\
| |
| | |
swaylock: Support keyboard and pointer disconnects and reconnects
|
| |/ |
|
| |\
| |
| | |
Fix crash when flattening container after moving
|
| |/
|
|
|
|
|
|
|
|
| |
container_flatten removes the container from the tree (via
container_replace) before destroying it. When destroying, the recent
changes to handle_seat_node_destroy incorrectly assumes that the
container has a parent.
This adds a check for destroying a container which is no longer in the
tree. If this is the case, focus does not need to be changed.
|
| |\
| |
| | |
Remove obsolete base64.c file
|
| |/ |
|
| | |
|
| |\
| |
| | |
Give focus to another swaylock surface when output is disconnected
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* Have multiple outputs
* Launch swaylock
* Unplug an output (possibly has to be the last "connected" one)
* The swaylock surface on the remaining output would not respond to key
events
This was happening because when the output destroys, focus was not given
to the other swaylock surface.
This patch makes focus be transferred to another surface owned by the
same Wayland client, but only if input was inhibited by the surface
being destroyed, and only if it's in the overlay layer. I figure it's
best to be overly specific and relax the requirements later if needed.
This patch removes a check in seat_set_focus_surface which was
preventing focus from being passed from a layer surface to any other
surface. I don't know of a use case for this check, but it's possible
that this change could produce issues.
|
| |\ \
| |/
|/| |
Ignore unrelated cursor buttons while doing seat operations
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Click and hold a scrollbar
* Drag the cursor onto another surface
* While still holding the original button, press and release another
cursor button
* Things get weird
There's two ways to fix this. Either cancel the seat operation and do
the other click, or continue the seat operation and ignore the other
click. I opted for the latter (ignoring the click) because it's easier
to implement, and I suspect a second click during a seat operation is
probably unintentional anyway.
|
| |\
| |
| | |
Fix crash if view has no container
|
| | | |
|
| |\ \
| |/
|/| |
raise floating
|
| | |
| |
| |
| |
| | |
This reenables the popup-handling code before the floating-window
focus change.
|
| | |
| |
| |
| |
| | |
Floating containers and their surfaces are ordered in "raised last".
This is used to detect the topmost surface and thus the focus.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Re-focus on the container on which the cursor hovers over. A
special case is, if there are menus or other subsurfaces open
in the focused container. It will prefer the focused container
as long as there are subsurfaces.
This commit starts caching the previous node as well as the
previous x/y cursor position. Re-calculating the previous
focused node by looking at the current state of the cursor
position does not work, if the environment changes.
|
| | | |
|
| | |
| |
| |
| |
| | |
* Factor out raising a floating window into s separate function to
enable reuse.
|
| |/
|
|
|
|
|
| |
* New configuration option: raise_floating
(From the discussion on https://github.com/i3/i3/issues/2990)
* By default, it still raises the window on focus, otherwise it
will raise the window on click.
|
| |\
| |
| | |
Add sanity check for empty focus stack
|
| |/ |
|
| |
|
|
| |
Half of this is outdated and the other half is questionable.
|
| | |
|
| |\
| |
| | |
Add CSD to border modes
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This does the following:
* Removes the xdg-decoration surface_commit listener. I was under the
impression the client could ignore the server's preference and set
whatever decoration they like using this protocol, but I don't think
that's right.
* Adds a listener for the xdg-decoration request_mode signal. The
protocol states that the server should respond to this with its
preference. We'll always respond with SSD here.
* Makes it so tiled views which use CSD will still have sway decorations
rendered. To do this, using_csd had to be added back to the view struct,
and the border is changed when floating or unfloating a view.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This replaces view.using_csd with a new border mode: B_CSD. This also
removes sway_xdg_shell{_v6}_view.deco_mode and
view->has_client_side_decorations as we can now get these from the
border.
You can use `border toggle` to cycle through the modes including CSD, or
use `border csd` to set it directly. The client must support the
xdg-decoration protocol, and the only client I know of that does is the
example in wlroots.
If the client switches from SSD to CSD without us expecting it (via the
server-decoration protocol), we stash the previous border type into
view.saved_border so we can restore it if the client returns to SSD. I
haven't found a way to test this though.
|
Ryan Dwyer
Ian Fan
Drew DeVault
emersion
Dominique Martinet
minus
Jonathan Buch