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 #1093] [MERGED] fix(borders): update borders location when moving with altsnap #1200

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

📋 Pull Request Information

Original PR: https://github.com/LGUG2Z/komorebi/pull/1093
Author: @alex-ds13
Created: 10/29/2024
Status: ✅ Merged
Merged: 10/31/2024
Merged by: @LGUG2Z

Base: master ← Head: fix/borders-move-with-altsnap

📝 Commits (1)

  • 3af1a13 fix(borders): update borders location when moving with altsnap

📊 Changes

4 files changed (+29 additions, -10 deletions)

View changed files

📝 komorebi/src/border_manager/mod.rs (+21 -3)
📝 komorebi/src/process_event.rs (+5 -4)
📝 komorebi/src/static_config.rs (+1 -1)
📝 komorebi/src/window_manager.rs (+2 -2)

📄 Description

Don't know if you've noticed but I created a PR on AltSnap to allow compatibility with komorebi. I'm still waiting for that PR to be merged though. There is however a slight issue on that PR which is that when moving with altsnap the borders don't update in real time, only update when the move finishes.

This happens because currently, komorebi checks if a move is happening by checking if the left mouse is pressed and updates the borders when there is a move while the left mouse button is pressed (BTW this is why when moving with the keyboard using the system move it only updates after pressing enter). However, for some reason I AltSnap somehow steals this left button information and komorebi thinks the button is not pressed.

This PR makes it so it checks for the state of the pending_move_op and keeps updating the borders while this is_some(). This fixes both that issue with AltSnap and the issue with system move, as well as any other situations that might allow moving a window with anything else that doesn't use a left mouse button press.

I'm making this PR as a draft since this will have no apparent change to anyone except the people using that AltSnap PR or someone using the system move.

If you think we should wait until the AltSnap PR is merged then we'll wait. If you think we can merge this PR already anyway since there's no harm in doing so and makes it ready for when the AltSnap PR is merged, tell me and I can change it from draft to an actual PR since it is actually ready.

🔄 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/1093 **Author:** [@alex-ds13](https://github.com/alex-ds13) **Created:** 10/29/2024 **Status:** ✅ Merged **Merged:** 10/31/2024 **Merged by:** [@LGUG2Z](https://github.com/LGUG2Z) **Base:** `master` ← **Head:** `fix/borders-move-with-altsnap` --- ### 📝 Commits (1) - [`3af1a13`](https://github.com/LGUG2Z/komorebi/commit/3af1a138a1e12910f5cb7f051c0dd56565a74221) fix(borders): update borders location when moving with altsnap ### 📊 Changes **4 files changed** (+29 additions, -10 deletions) <details> <summary>View changed files</summary> 📝 `komorebi/src/border_manager/mod.rs` (+21 -3) 📝 `komorebi/src/process_event.rs` (+5 -4) 📝 `komorebi/src/static_config.rs` (+1 -1) 📝 `komorebi/src/window_manager.rs` (+2 -2) </details> ### 📄 Description Don't know if you've noticed but I created a [PR](https://github.com/RamonUnch/AltSnap/pull/564) on AltSnap to allow compatibility with komorebi. I'm still waiting for that PR to be merged though. There is however a slight issue on that PR which is that when moving with altsnap the borders don't update in real time, only update when the move finishes. This happens because currently, komorebi checks if a move is happening by checking if the left mouse is pressed and updates the borders when there is a move while the left mouse button is pressed (BTW this is why when moving with the keyboard using the system move it only updates after pressing enter). However, for some reason I AltSnap somehow steals this left button information and komorebi thinks the button is not pressed. This PR makes it so it checks for the state of the `pending_move_op` and keeps updating the borders while this `is_some()`. This fixes both that issue with AltSnap and the issue with system move, as well as any other situations that might allow moving a window with anything else that doesn't use a left mouse button press. I'm making this PR as a draft since this will have no apparent change to anyone except the people using that AltSnap PR or someone using the system move. If you think we should wait until the AltSnap PR is merged then we'll wait. If you think we can merge this PR already anyway since there's no harm in doing so and makes it ready for when the AltSnap PR is merged, tell me and I can change it from draft to an actual PR since it is actually ready. --- <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:54:26 +01:00
adam closed this issue 2026-01-05 14:54:26 +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#1200
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?