aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* | Fix crash when disabling focused monStivvo2020-10-311-4/+14
| | | | | | | | | | | | | | | | | | | | | | | | 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)
* | Merge branch 'handleUnplug' into output-managementStivvo2020-10-310-0/+0
|\|
| * Fix crash unplugging focused mon 2Stivvo2020-10-311-1/+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.
* | Merge branch 'handleUnplug' into output-managementStivvo2020-10-311-1/+2
|\ \
| * | Fix crash unplugging a focused monStivvo2020-10-311-1/+2
| |/ | | | | | | | | Focus newmon, which we know for sure that it isn't be unplugged or disabled
* | Merge branch 'handleUnplug' into output-managementStivvo2020-10-310-0/+0
|\|
| * Focus client on a new monitor before closingStivvo2020-10-311-0/+1
| |\
* | | Block access to disabled monitorStivvo2020-10-301-4/+6
| | | | | | | | | | | | | | | Before this, pressing mod+comma or mod+period (focusmon function) moved the focus to disabed monitors. Now, all disabled monitors are skipped
* | | Move disabled clients to the leftStivvo2020-10-301-2/+2
| | | | | | | | | | | | To the nearest monitor to the left of the disabled one
* | | Merge branch 'handleUnplug' into output-managementStivvo2020-10-301-14/+10
|\ \ \
| * \ \ Merge branch 'handleUnplug' of http://olidata.stivvo01.com:3000/Stivvo01/dwl ↵Stivvo2020-10-301-0/+1
| |\ \ \ | | |/ / | |/| / | | |/ into handleUnplug
| * | Closemon(), newmon as parameterStivvo2020-10-301-15/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | Actually move clients away from a disabled monStivvo2020-10-301-14/+3
| | | | | | | | | | | | | | | | | | 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.
* | | Merge branch 'handleUnplug' into output-managementStivvo2020-10-301-3/+3
|\ \ \ | | |/ | |/|
| * | Fix crash when unplugging a focused monitorStivvo2020-10-301-0/+1
| | | | | | | | | | | | Just focus a "safe" monitor before trying to to anything risky
| * | Cleaner if statementStivvo2020-10-301-3/+2
| |/
* | Merge branch 'output-management' of ↵Stivvo2020-10-251-1/+1
|\ \ | | | | | | | | | http://olidata.stivvo01.com:3000/Stivvo01/dwl into output-management
| * | Handle monitor enableStivvo2020-10-251-2/+9
| | |
* | | Handle monitor enableStivvo2020-10-251-2/+9
|/ /
* | Move clients away from a disabled monitorStivvo2020-10-251-2/+10
| | | | | | | | | | | | 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
* | Merge branch 'handleUnplug' into output-managementStivvo2020-10-251-3/+12
|\|
| * closemon()Stivvo2020-10-241-3/+12
| | | | | | | | Separate oputput movement from cleanupmon
* | Merge branch 'handleUnplug' into output-managementStivvo2020-10-241-4/+29
|\|
| * fix compile error mixed declarationStivvo2020-10-181-1/+1
| |
| * Merge pull request #2 from guidocella/handleUnplugStivvo2020-10-181-2/+1
| |\ | | | | | | Move sgeom assignment
| | * Move sgeom assignmentGuido Cella2020-10-171-2/+1
| |/ | | | | | | | | | | 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.
| * Keep client tags on unplugStivvo2020-09-151-1/+1
| | | | | | | | | | When unplugging a monitor, each client is moved to the same tag number as before on the new monitor
| * Handle monitor unplugStivvo2020-09-151-16/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * Restore floating win position after mon addStivvo2020-09-121-0/+18
| | | | | | | | | | | | | | | | 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.
* | Implement the output management protocolGuido Cella2020-10-171-0/+81
|/ | | | It allows clients such as wlr-randr to configure the display.
* extract function and comment itGuido Cella2020-09-111-11/+18
|
* remove bracesGuido Cella2020-09-111-2/+1
|
* fix multi monitors even moreGuido Cella2020-09-111-6/+15
| | | | | | | | | | 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).
* simplifyGuido Cella2020-09-101-1/+1
|
* fix multi monitors furtherGuido Cella2020-09-091-3/+1
| | | | | Fix layer surfaces without an exculsive area by using the right x and y for the current monitor (by Stivvo).
* remove unneeded lineGuido Cella2020-09-081-1/+0
| | | | | | | 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.
* try to fix againGuido Cella2020-09-081-4/+1
| | | | Calculate x and y of usable_area, not just width and heigth.
* fix multi monitorsGuido Cella2020-09-081-1/+5
| | | | | | | | | | | | | | | | | 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.
* remove variableGuido Cella2020-09-061-4/+3
|
* use size_t for lengthsGuido Cella2020-09-051-4/+4
|
* rename variable and merge 2 linesGuido Cella2020-09-051-3/+2
|
* simplifyGuido Cella2020-09-051-10/+4
|
* use unsigned int for loop indexesGuido Cella2020-09-041-3/+3
|
* Don't let overlays lose focusGuido Cella2020-09-041-2/+20
| | | | | if you open a new window while an overlay is mapped, the overlay should stay focused
* fix restoring pointer focusGuido Cella2020-09-041-1/+6
| | | | | I don't know why I thought it was working before. Maybe I should go do something else.
* improve code styleGuido Cella2020-09-041-4/+4
|
* remove commentGuido Cella2020-09-041-1/+1
| | | | | I don't know why it wasn't working before but now it does ¯\(ツ)/¯ (it wasn't caused by the just removed code either)
* remove mysterious codeGuido Cella2020-09-041-7/+0
| | | | | Why would a surface that's not keyboard interactive get focused? Let's remove this for now and see if issues arise.
* focus the previous client in the similar code tooGuido Cella2020-09-041-2/+1
|
* refocus old clientGuido Cella2020-09-041-3/+1
| | | | | | 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.