| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |/ / / / / / / |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
mod+e allows to toggle fullscreen any client, even those who don't
support it themselves
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Windows lose fullscreen state when a new window is created in the same
tag
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Store position and size of windows before going fullscreen. This is more
efficient than arrange() and also works with floating windows
All the clients keep their original position because arrange() isn't
used after quitting fullscreen
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Some code has been borrowed from the smartBorders patch
|
| | | | | | | | |
|
| | |_|/ / / /
| |/| | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
|\ \ \ \ \ \ \
| | |_|_|_|_|/
| |/| | | | | |
Layer shell
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
When a monitor is created or removed, the geometries of the old ones
must be updated. This is also more efficient than before since we
calculate the monitor geometries only when creating and destroying
monitors. arrangelayers() is needed to recalculate m->w. arrange() is so
clients don't move to the left monitor when plugging or unplugging
monitors (clients keep the same coordinates but the field below them
changes).
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Fix layer surfaces without an exculsive area by using the right x and y
for the current monitor (by Stivvo).
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The bug was caused by usable_area's x and y not being set in
arrangelayers. For example if on a 2nd HD monitor, x should be 1920
while the first one ends at 1919. So I don't see why m->m should be
recalculated after creating the monitor.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Calculate x and y of usable_area, not just width and heigth.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
If you don't recalculate the monitor's geometry before arranging,
clients get arranged in the first monitor. I don't understand why this
fixes the bug since tile() uses m->w rather than m->m, nor why it needs
to be recalculated after creating the monitor but sway does it too.
Although not necessary to fix the bug I also made arrangelayer() do like
sway again and recalculate usable_area instead of reusing m->m, since
m->m seems to be incorrect until it gets recalculated shortly after in
arrange(), so I suspect that leaving usable_area = m->m will cause
issues under certain circumstances.
Someone with a multi-monitor setup or better knowledge of Wayland may be
able to figure out the cause of the bug. For now, this makes layer shell
work.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
if you open a new window while an overlay is mapped, the overlay should
stay focused
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
I don't know why I thought it was working before. Maybe I should go do
something else.
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
I don't know why it wasn't working before but now it does ¯\(ツ)/¯
(it wasn't caused by the just removed code either)
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Why would a surface that's not keyboard interactive get focused? Let's
remove this for now and see if issues arise.
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
When a layer surface is destroyed focus should be returned to the last
client. Luckily if there are multiple overlays the previous overlay
still gets focused.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
needs refactoring and testing
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
be consistent with the rest of the code
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
wlr_output_layout_get_box internally calls
wlr_output_effective_resolution
|