Fix monitor preferences #1241
Draft
Fix monitor preferences #1241
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously, when caching a workspace config for a monitor it would simply store the `DefaultLayout` on `layout` even if the original workspace config had the `layout` as `None` which makes komorebi create a workspace with the `layout` as default `BSP` and the `tile` set at `false`. However this wasn't being taken into consideration, so floating workspaces would becoming tiling `BSP` workspaces after a monitor disconnect and reconnect. This commit fixes this by turning the `layout` to `None` when `tile` is `false`.
Store the `WorkspaceConfig` on the `Workspace` itself so that when we want to cache the workspace as `WorkspaceConfig` on the monitor cache it properly saves things like the workspace rules and the custom layout and custom layout rules.
This commit reworks the way the `postload` and the `reload` functions apply the monitor configs to the monitors. Previously it was looping through the monitor configs and applying them to the monitor with the index corresponding to the config's index. However this isn't correct, since the user might set the preferred indices for 3 monitors (like monitor A, B and C), with the preferred index set to 0 for A, 1 for B and 2 for C, but if only monitors A and C are connected then komorebi would apply config 0 to A and config 1 to C, which is wrong it should be 2 for C. This commit changes the way the configs are applied on those functions. Now it loops through the existing monitors (already in order), then checks if the monitor has a preferred config index, if it does it uses that one, if it doesn't then it uses the first monitor config that isn't a preferred index for some other monitor and that hasn't been used yet. For the situation above it means that it would still apply config 2 to monitor C. And in case there aren't any display_index_preferences set it will still apply the configs in order.
If we have display_index_preferences that set a specific config index for a specific display device, but that device isn't loaded yet, now we store that config with the corresponding `device_id` on the monitor cache so that when the display is connected it can load the correct config from the cache.
When a monitor was disconnected the containers from the removed monitor were being moved to the primary monitor. However they weren't restored so containers that were on an unfocused workspace of the removed monitor would have been cloak and were getting added to the main monitor still cloaked creating ghost tiles. This commit fixes that.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR reworks the way the
postloadand thereloadfunctions apply the monitor configs to the monitors. Previously it was looping through the monitor configs and applying them to the monitor with the index corresponding to the config's index.However this isn't correct, since the user might set the preferred indices for 3 monitors (like monitor A, B and C), with the preferred index set to 0 for A, 1 for B and 2 for C, but if only monitors A and C are connected then komorebi would apply config 0 to A and config 1 to C, which is wrong it should be 2 for C.
This PR changes the way the configs are applied on those functions.
Now it loops through the existing monitors (already in order), then checks if the monitor has a preferred config index, if it does it uses that one, if it doesn't then it uses the first monitor config that isn't a preferred index for some other monitor and that hasn't been used yet.
For the situation above it means that it would still apply config 2 to monitor C. And in case there aren't any display_index_preferences set it will still apply the configs in order.
It also changes the way the layout is stored from the current monitor, by making sure to set it to
Noneif the workspace is not tiling. Previously any floating workspace would be restored from cache with a tiling BSP layout.Related to this discussion on Discord
However this entire code is based on the premise that the
device_idis always the same for the same devices. However there have been comments on discord stating that this isn't true, however I've not been able to confirm this and the users have not given any proof of this happening (they might simply be confusing it since it's a weird string similar between monitors...)I think the changes from this PR should fix most issues that people have been having with multiple monitors (specially with 3 or more monitors). But it's probably better to not merge this until we can get some users to test it.