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

Resizing breaks if workspace-layout param is used for monitor #89

New Issue
Closed
opened 2026-01-05 14:48:13 +01:00 by adam · 2 comments
adam commented 2026-01-05 14:48:13 +01:00
Owner
Copy Link

Originally created by @labuut on GitHub (Jun 1, 2022).

OS: Windows 10
komorebi: 0.1.9-x86_64-pc-windows-msvc

Hello.
I have two-monitor setup and I noticed a strange behaviour:

  • if I use workspace-layout param for monitor 0 I can't resize layout on monitor 0;
  • if I use workspace-layout param for monitor 1 I can't resize layout on monitor 1;
  • If I don't use this param at all resizing works as expected for both 0 and 1 monitors;
Originally created by @labuut on GitHub (Jun 1, 2022). OS: Windows 10 komorebi: 0.1.9-x86_64-pc-windows-msvc Hello. I have two-monitor setup and I noticed a strange behaviour: - if I use `workspace-layout` param for monitor `0` I can't resize layout on monitor `0`; - if I use `workspace-layout` param for monitor `1` I can't resize layout on monitor `1`; - If I don't use this param at all resizing works as expected for both `0` and `1` monitors;
adam added the enhancement label 2026-01-05 14:48:13 +01:00
adam closed this issue 2026-01-05 14:48:14 +01:00
adam commented 2026-01-05 14:48:14 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Jun 2, 2022):

I think this is a case of requiring clearer documentation- the resize-edge and resize-axis commands (and by extension, drag-to-resize) only apply to the bsp layout currently. resize-axis can also be used with custom layouts to increase and reduce the size of the Primary column, but drag-to-resize is only implemented for the bsp layout.

The layout engine is probably the biggest piece of technical debt in this project, and it comes down to the choice of data structure used to hold the windows (a Ring instead of a Tree). Because of this data structure choice, resizing has to be implemented separately for different layout.

I'd welcome a PR to migrate to a data structure that would allow for resizing to be implemented once for any layout (like a tree) from anyone braver than I when it comes to implementing data structures with cyclic references in Rust, but this is not something that I would have any interest in undertaking for myself.

@LGUG2Z commented on GitHub (Jun 2, 2022): I think this is a case of requiring clearer documentation- the `resize-edge` and `resize-axis` commands (and by extension, drag-to-resize) only apply to the `bsp` layout currently. `resize-axis` can _also_ be used with custom layouts to increase and reduce the size of the `Primary` column, but drag-to-resize is only implemented for the `bsp` layout. The layout engine is probably the biggest piece of technical debt in this project, and it comes down to the choice of data structure used to hold the windows (a Ring instead of a Tree). Because of this data structure choice, resizing has to be implemented separately for different layout. I'd welcome a PR to migrate to a data structure that would allow for resizing to be implemented once for any layout (like a tree) from anyone braver than I when it comes to implementing data structures with cyclic references in Rust, but this is not something that I would have any interest in undertaking for myself.
adam commented 2026-01-05 14:48:14 +01:00
Author
Owner
Copy Link

@labuut commented on GitHub (Jun 6, 2022):

Ok, I got it, thank you. I'll try to help you If I have enough time to understand rust)

@labuut commented on GitHub (Jun 6, 2022): Ok, I got it, thank you. I'll try to help you If I have enough time to understand rust)
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 enhancement
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#89
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?