Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
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>
|
|
|
|
|
|
|
|
Fixes #875
|
|
|
|
|
|
|
|
This code had some issues. Remove it now so that we can start clean and fix
it later.
|
|
Prior to this commit all windows (e.g. shell surfaces) were handled the same
way in handle_view_created. Since backgrounds and panels have to be treated
differently, they could not be shell surfaces. This changes checks whether
a client is a background or a panel in handle_view_created and exists to
let them be dealt with elsewhere.
|
|
|
|
Fix #659
|
|
desktop_shell.panel_size was only used to determine if sway should
rearrange the output when rendering the panel in the output_pre_render
hook. This is not needed since the output will have been arranged at
that point.
It also caused sway to rearrange all the time when running with two
or more different monitors/resolutions because panel_size kept changing
with every output_pre_render callback.
Should fix #514
|
|
Swaylock spawns and focuses a view for each output in sway. This can
sometimes move the focus to a new output after locking and unlocking the
screens.
This patch makes sure that the output which had focus when swaylock
was invoked, will regain focus once swaylock is closed/unlocked.
Fix #499
|
|
This should be a real fix for #509
This schedules a render when a background or panel is added to sway
through the desktop shell interface, that makes sure the render isn't
scheduled before the bg or panel is ready and you don't end up with a
black screen until the cursor is moved.
|
|
Fix #498
|
|
|
|
This avoids calling swayc_active_workspace.
|
|
Fix #481
|
|
|
|
Track each panel separately via its wl_resource. `set_panel_position`
might be called before `set_panel`, so reuse panel config.
Place the position in panel_config so that each panel has its own
position.
|
|
Change the name to something less ambigious.
|
|
This makes swaylock more or less work.
|
|
|
|
|
|
This prevents sway crashing if swaybg or swaybar dies.
|
|
|
|
This fixes a compiler warning:
../sway/extensions.c: In function ‘set_background’:
../sway/extensions.c:16:37: warning: implicit declaration of function ‘malloc’ [-Wimplicit-function-declaration]
struct background_config *config = malloc(sizeof(struct background_config));
^
../sway/extensions.c:16:37: warning: incompatible implicit declaration of built-in function ‘malloc’
../sway/extensions.c:16:37: note: include ‘<stdlib.h>’ or provide a declaration of ‘malloc’
|
|
Thanks @Cloudef, it works great
|
|
This does not work as expected. I think the problem is on the wlc side.
Please review, @Cloudef. To reproduce the issues:
1. Run sway
2. Open terminal in sway
3. Run swaybg
swaybg will create a surface and ask to have it set as the background,
but wlc_handle_from_wl_surface_resource will return 0. If the swaybg
surface is a shell surface, then it works - but wlc complains about the
pointer type and segfaults as soon as the pre-render hook tries to draw
the background.
|
|
|