starred/komorebi
1
0
Fork 0
mirror of https://github.com/LGUG2Z/komorebi.git synced 2026-01-11 14:40:25 +01:00
Code Issues 87 Packages Projects Releases 10 Wiki Activity

[PR #1598] [MERGED] fix(wm): promoting a container shouldn't change their sizes #1473

New Issue
Closed
opened 2026-01-05 14:55:24 +01:00 by adam · 0 comments
adam commented 2026-01-05 14:55:24 +01:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/LGUG2Z/komorebi/pull/1598
Author: @alex-ds13
Created: 11/20/2025
Status: ✅ Merged
Merged: 11/22/2025
Merged by: @LGUG2Z

Base: master ← Head: fix/promote-should-not-resize

📝 Commits (1)

  • 294b126 fix(wm): promoting a container shouldn't change their sizes

📊 Changes

1 file changed (+7 additions, -5 deletions)

View changed files

📝 komorebi/src/workspace.rs (+7 -5)

📄 Description

  • When promoting a container it is using the remove_focused_container() and insert_container_at_idx functions which will remove the focused container size from resize_dimensions and then add the new container with size None. Then it was adding the previously stored size of the main container back to the first one. However this would result in at least 3 issues:
    1. We were removing the size from index 0, however when inserting it back on the primary_idx we might not add it to index 0, specially now that there could be locked containers so if container 0 is locked we would be adding it to the next container, which would result in the main container having no size information which would result in a recalculation on the next update and it would revert back to default, so if a user had resized their containers that information would be lost.
    2. We were removing the size from index 0. Then on remove_focused_container it would remove the size from the focused container index, but since we had already removed one size from the resize_dimensions that index would no longer match the actual focused container, so once again we would be losing information.
    3. Since we were removing the size of the focused container idx from resize_dimensions (albeit the wrong one as stated above), this would mean that the container that moved to that position would have no resize information so it would show up as if the main container was taking up half width of the area, ignoring any user resize, until the next workspace update was triggered.
  • This commit completely ignores the resize_dimensions since promoting a container simply means moving one container from one position to the main one (usually index 0) and then shift all the rest to the "right". The existing resize_dimensions should be kept untouched. To do this we use the functions remove_respecting_locks and insert_respecting_locks on the containers themselves, which simply move the container and shifts the others which is precisely what we want.

This PR was a result of this conversation on discord: https://discord.com/channels/898554690126630914/1440500893782114455

BTW @LGUG2Z, this left me wondering should the promote_container obey the locked containers?! As far as I understood the main reasoning being the locked containers was so that you could keep some container in place even when adding new containers/windows that would otherwise move it, however when you use the komorebic promote command it is because you want to move the focused container into the "main spot", however if that was locked that won't happen, it will move it to the next one... Is this the intended behavior? I personally am totally fine with leaving it as is, since if you locked the main container it is probably because you really don't want it to be moved, otherwise I don't see the need to lock the main container since new windows should never move that one.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/LGUG2Z/komorebi/pull/1598 **Author:** [@alex-ds13](https://github.com/alex-ds13) **Created:** 11/20/2025 **Status:** ✅ Merged **Merged:** 11/22/2025 **Merged by:** [@LGUG2Z](https://github.com/LGUG2Z) **Base:** `master` ← **Head:** `fix/promote-should-not-resize` --- ### 📝 Commits (1) - [`294b126`](https://github.com/LGUG2Z/komorebi/commit/294b126a477bd695fa7d0b9bd58cfa3c5ce4875c) fix(wm): promoting a container shouldn't change their sizes ### 📊 Changes **1 file changed** (+7 additions, -5 deletions) <details> <summary>View changed files</summary> 📝 `komorebi/src/workspace.rs` (+7 -5) </details> ### 📄 Description - When promoting a container it is using the `remove_focused_container()` and `insert_container_at_idx` functions which will remove the focused container size from `resize_dimensions` and then add the new container with size `None`. Then it was adding the previously stored size of the main container back to the first one. However this would result in at least 3 issues: 1. We were removing the size from index 0, however when inserting it back on the primary_idx we might not add it to index 0, specially now that there could be locked containers so if container 0 is locked we would be adding it to the next container, which would result in the main container having no size information which would result in a recalculation on the next update and it would revert back to default, so if a user had resized their containers that information would be lost. 2. We were removing the size from index 0. Then on `remove_focused_container` it would remove the size from the focused container index, but since we had already removed one size from the `resize_dimensions` that index would no longer match the actual focused container, so once again we would be losing information. 3. Since we were removing the size of the focused container idx from `resize_dimensions` (albeit the wrong one as stated above), this would mean that the container that moved to that position would have no resize information so it would show up as if the main container was taking up half width of the area, ignoring any user resize, until the next workspace update was triggered. - This commit completely ignores the `resize_dimensions` since promoting a container simply means moving one container from one position to the main one (usually index 0) and then shift all the rest to the "right". The existing `resize_dimensions` should be kept untouched. To do this we use the functions `remove_respecting_locks` and `insert_respecting_locks` on the containers themselves, which simply move the container and shifts the others which is precisely what we want. This PR was a result of this conversation on discord: https://discord.com/channels/898554690126630914/1440500893782114455 BTW @LGUG2Z, this left me wondering should the `promote_container` obey the locked containers?! As far as I understood the main reasoning being the locked containers was so that you could keep some container in place even when adding new containers/windows that would otherwise move it, however when you use the `komorebic promote` command it is because you _**want**_ to move the focused container into the "main spot", however if that was locked that won't happen, it will move it to the next one... Is this the intended behavior? I personally am totally fine with leaving it as is, since if you locked the main container it is probably because you _**really**_ don't want it to be moved, otherwise I don't see the need to lock the main container since new windows should never move that one. <!-- Please follow the Conventional Commits specification. If you need to update your PR with changes from `master`, please run `git rebase master`. By opening this PR, you confirm that you have read and understood this project's `CONTRIBUTING.md`. --> --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
adam added the pull-request label 2026-01-05 14:55:24 +01:00
adam closed this issue 2026-01-05 14:55:24 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
0.1.36
apps-behaving-badly
bug
bug
cannot-reproduce
documentation
enhancement
github_actions
i-am-stuck
i-will-definitely-work-on-this
i-will-not-work-on-this
i-will-probably-work-on-this
komorebi
komorebi-bar
komorebic
performance
pull-request
Mirrored from GitHub Pull Request
 translation
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/komorebi#1473
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?