Commit graph

381 commits

Author SHA1 Message Date
Guido Cella 1024928c15 deactivate focused client when spawning a new one
Because maprequest immediately calls wl_list_insert(&fstack, &c->flink),
in the following call to setmon(), the selclient() which is passed to
focusclient() as the old client is actually the newly mapped client, and
the real old one is never deactivated. You can see this by, for example,
opening Chromium's devtools, then spawning a terminal. The background of
the focused line in the devtools doesn't change from light blue to grey.

We can't just remove wl_list_insert(&fstack, &c->flink) from maprequest,
because calling wl_list_remove in focusclient() with a client that has
not been added to the list causes a segmentation fault.
Therefore we fix the focusclient call by not passing it the old client
every time, but instead using the wlroots function that gets the focused
surface and deactivate that, like in TinyWL.
This also avoids getting the selected client and passing it to
focusclient() on every call unnecessarily, and will allow removing
shouldfocusclients in a future commit by checking if old is a layer
surface instead.
2020-12-19 12:34:31 +01:00
Guido Cella 64faad7cb6 implement the wlr-data-transfer protocol
It makes wl-clipboard work properly in neovim, without having to create
a transparent surface that steals focus and causes flickering. It's also
required for clipman.
2020-12-19 12:26:31 +01:00
Guido Cella ee5bd9a643 fix temporarily disabling a single monitor
The code in this else completely freezes my system when I run the
swayidle command to replicate xset dpms force off. No idea if it works
on multiple monitors, but for now avoid running when there's 1 monitor.

Also remove the comment with the function name in sway.
2020-12-19 12:26:14 +01:00
Stivvo d9ab75721a Don't switch to another disabled monitors
Since wlr_output_enable doesn't have any effect before finishing all the
procedure, a little hack allows to make use of focusmon(), which must
know the latest in about which output is currently disabled

Also improve performance in focusmon() and cleaner code in
outputmgrapplyortest()
2020-10-31 18:29:33 +01:00
Stivvo 80a685ee51 Fix crash with no monitors left
When there's no monitors left, prevent the while in cleanupmon() to
become an infinite loop

Also switch to the left monitors instead of the right
2020-10-31 17:11:16 +01:00
Stivvo 5221a329e2 closemon() has now only 1 parameter 2020-10-31 16:25:46 +01:00
Stivvo 934ce085b6 Don't switch to disabled mons after unplug 2020-10-31 16:25:29 +01:00
Stivvo 38606a1d23 Merge branch 'handleUnplug' into output-management 2020-10-31 16:16:22 +01:00
Stivvo 9f0b16868a Back to closemon() with one parameter
With the recent changes in output-management, the extra argument in
closemon() would be needed only when unplugging the monitor, so it isn't
worth it anymore. Also now is more efficient.
2020-10-31 13:19:31 +01:00
Stivvo 9f3f15b467 Disable mon faster
Since focusmon() now never focuses disabled monitors, there's no need to
focus the disabled monitor first
2020-10-31 13:00:55 +01:00
Stivvo 25671d7905 Fix crash when disabling focused mon
m->link.next leads to errors if the monitor to disable doesn't have a
"next" (right) monitor and is currently focused. dirtmon() does more
checks.

In some previous commits m->link.next is told to be left monitor, which
is wrong

Also focusclient() explicitly checks for disabled monitors (this fixes
in case of more than one disabled monitor)
2020-10-31 12:52:22 +01:00
Stivvo 60a63b637c Merge branch 'handleUnplug' into output-management 2020-10-31 11:25:05 +01:00
Stivvo 5622dbdaf3 Fix crash unplugging focused mon 2
Focus the top client on newmon, which we know for sure that it isn't
going to be unplugged or disabled and actually set that as the focused
monitor to move the focus. This is necessary to prevent crash when
disabling monitors with the output-management patch.
2020-10-31 11:17:57 +01:00
Stivvo 0a0e61e58d Merge branch 'handleUnplug' into output-management 2020-10-31 11:04:04 +01:00
Stivvo fab42e7c41 Fix crash unplugging a focused mon
Focus newmon, which we know for sure that it isn't be unplugged or
disabled
2020-10-31 11:03:00 +01:00
Stivvo dbd665c862 Merge branch 'handleUnplug' into output-management 2020-10-31 00:03:40 +01:00
Stivvo a4d42ea798 Focus client on a new monitor before closing 2020-10-31 00:01:59 +01:00
Stivvo 62fb4c086e Block access to disabled monitor
Before this, pressing mod+comma or mod+period (focusmon function) moved
the focus to disabed monitors. Now, all disabled monitors are skipped
2020-10-30 23:49:01 +01:00
Stivvo 388ab9df2f Move disabled clients to the left
To the nearest monitor to the left of the disabled one
2020-10-30 23:34:26 +01:00
Stivvo 806ebffe7d Merge branch 'handleUnplug' into output-management 2020-10-30 23:31:46 +01:00
Stivvo fbbc1fd656 Merge branch 'handleUnplug' of http://olidata.stivvo01.com:3000/Stivvo01/dwl into handleUnplug 2020-10-30 23:30:00 +01:00
Stivvo d4178b9d2a Closemon(), newmon as parameter
This allows to fix output-management: move clients to the monitor on the
left of the disabled one, instead of the leftmost (which might happen to
be the disabled one)

Also using wl_list_foreach() and then brake after the first iteration is
ugly and inefficient
2020-10-30 23:22:55 +01:00
Stivvo 4deeddceff Actually move clients away from a disabled mon
When using wlr-randr every monitor's configuration is reevaluated, so it
must check which monitors are actually being disabled. The only way to
correctly do that is to compare the names.
2020-10-30 22:35:05 +01:00
Stivvo 874a4df389 Merge branch 'handleUnplug' into output-management 2020-10-30 19:56:14 +01:00
Stivvo 618972696d Fix crash when unplugging a focused monitor
Just focus a "safe" monitor before trying to to anything risky
2020-10-30 19:52:20 +01:00
Stivvo 7d67b77a96 Cleaner if statement 2020-10-30 16:21:00 +01:00
Stivvo e64259abf5 Merge branch 'output-management' of http://olidata.stivvo01.com:3000/Stivvo01/dwl into output-management 2020-10-25 13:40:48 +01:00
Stivvo 42aea0b17d Handle monitor enable 2020-10-25 12:37:05 +01:00
Stivvo 3c3714aac0 Handle monitor enable 2020-10-25 11:56:21 +01:00
Stivvo 4c0d59c1a7 Move clients away from a disabled monitor
When a monitor is disabled with wlr_randr, all clients on that monitor
aren't lost but they are moved to the leftmost monitor with the same
method that handles monitor hot unplug
2020-10-25 11:22:58 +01:00
Stivvo 927352865c Merge branch 'handleUnplug' into output-management 2020-10-25 11:08:08 +01:00
Stivvo ef7043e4d1 closemon()
Separate oputput movement from cleanupmon
2020-10-24 23:40:19 +02:00
Stivvo db95024211 Merge branch 'handleUnplug' into output-management 2020-10-24 22:51:26 +02:00
Stivvo 7017a0c64d fix compile error mixed declaration 2020-10-18 18:37:55 +02:00
Stivvo 96d9f010de
Merge pull request #2 from guidocella/handleUnplug
Move sgeom assignment
2020-10-18 18:20:13 +02:00
Guido Cella f21d3796b8 Move sgeom assignment
There is no need to repeat this. This needs to be reculalculated in my
output-management implementation too, and since I'm already calling
updatemons, this patch avoids having to repeat the assignment again.
2020-10-17 20:33:53 +02:00
Guido Cella b30e18fa20 Implement the output management protocol
It allows clients such as wlr-randr to configure the display.
2020-10-17 20:11:31 +02:00
Stivvo d8f752c9b4 Keep client tags on unplug
When unplugging a monitor, each client is moved to the same tag number
as before on the new monitor
2020-09-15 12:28:58 +02:00
Stivvo bece225934 Handle monitor unplug
Floating widndows with "x < removed monitor's width" aren't resized
(they used to disappear in negative coordinates).

Actually delete monitors when they are unplugged, recalculate sgeom and
give a new monitor to clients that were on the removed one with setmon()

arrangefloat() funcion has been exploded to save iterations in
cleanupmon().

Also if a monitor that supports auto suspension is turned off, dwl will
count it as unplugged (it will become unreachable and all clients will
be moved to the leftmost monitor). However, if at least one monitor
isn't plugged in, dwl will still crash the same as before.

Unlike sway, when the output configuration is changed and restored,
(unplug + plug the same monitor for example) previous application
positions aren't kept. This is due to the fact that on sway every
workspace is unique among all monitors.
2020-09-15 12:28:49 +02:00
Stivvo 537ad7e3fd Restore floating win position after mon add
Compensate the coordinate changes when adding a new monitor.

Every test so far confirms that monitors are always added to the left,
on top of the list, so every floating window's x coordinate has to be
incremented by the width of the new monitor.
2020-09-12 00:21:58 +02:00
Guido Cella 0bb25a73ec extract function and comment it 2020-09-11 14:52:59 +02:00
Guido Cella e4d58c39e0 remove braces 2020-09-11 13:15:31 +02:00
Guido Cella fbd905155a fix multi monitors even more
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).
2020-09-11 13:09:18 +02:00
Guido Cella 8f0ce672d3 simplify 2020-09-10 06:01:18 +02:00
Guido Cella 143dce094c fix multi monitors further
Fix layer surfaces without an exculsive area by using the right x and y
for the current monitor (by Stivvo).
2020-09-09 17:13:30 +02:00
Guido Cella 62250661cf remove unneeded line
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.
2020-09-08 13:36:46 +02:00
Guido Cella 68412d8957 try to fix again
Calculate x and y of usable_area, not just width and heigth.
2020-09-08 12:49:05 +02:00
Guido Cella 69847872bb fix multi monitors
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.
2020-09-08 10:28:29 +02:00
Guido Cella 79f3bbaf38 remove variable 2020-09-06 19:59:58 +02:00
Guido Cella 52a4d3a1e5 use size_t for lengths 2020-09-05 18:29:39 +02:00