-
-
Notifications
You must be signed in to change notification settings - Fork 201
Commit
This commit adds a new komorebi command "cycle-stack-index" which allows the user to manipulate the index position of the focused window in the focused stack by swapping it with either the previous or the next window until the desired index position has been found.
- Loading branch information
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2022,6 +2022,39 @@ impl WindowManager { | |
self.update_focused_workspace(self.mouse_follows_focus, true) | ||
} | ||
|
||
#[tracing::instrument(skip(self))] | ||
pub fn cycle_container_window_index_in_direction( | ||
&mut self, | ||
direction: CycleDirection, | ||
) -> Result<()> { | ||
self.handle_unmanaged_window_behaviour()?; | ||
|
||
tracing::info!("cycling container window index"); | ||
|
||
let container = | ||
if let Some(container) = self.focused_workspace_mut()?.monocle_container_mut() { | ||
container | ||
} else { | ||
self.focused_container_mut()? | ||
}; | ||
|
||
let len = NonZeroUsize::new(container.windows().len()) | ||
.ok_or_else(|| anyhow!("there must be at least one window in a container"))?; | ||
|
||
if len.get() == 1 { | ||
bail!("there is only one window in this container"); | ||
} | ||
|
||
let current_idx = container.focused_window_idx(); | ||
let next_idx = direction.next_idx(current_idx, len); | ||
container.windows_mut().swap(current_idx, next_idx); | ||
|
||
container.focus_window(next_idx); | ||
container.load_focused_window(); | ||
|
||
self.update_focused_workspace(self.mouse_follows_focus, true) | ||
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong.
LGUG2Z
Author
Owner
|
||
} | ||
|
||
#[tracing::instrument(skip(self))] | ||
pub fn focus_container_window(&mut self, idx: usize) -> Result<()> { | ||
self.handle_unmanaged_window_behaviour()?; | ||
|
@LGUG2Z It seems to me that there is a misunderstanding about the parameters of the function
update_focused_workspace
. From looking at the function itself it seems to me that the first parameterfollow_focus
should be true if we want the "actual" focus, as in the foreground window, to be "triggered" (if the second parametertrigger_focus
is true) on the currently focused window (which looks in priority atmaximized -> monocle -> containers -> desktop window
, ignoring floating windows). Iffollow_focus
is false then it only triggers the focus ondesktop window
if the workspace is empty (no matter whattrigger_focus
is), or it "triggers" focus (dependent on second parameter) on a stack container if it has no window that should show be above (likemaximized -> monocle -> floating_windows
), lastly it will also "trigger" focus (dependent on second parameter) on a maximized window if it exists.This function is already somewhat confusing to me, it seems that there were some bugs that people tried to fix on this function even though it had nothing to do with it. To me this function was meant to be used to update the focused workspace (as in retile it correctly in case a container was added/removed for instace) and to update the foreground focus of the focused workspace. (maybe this second use shouldn't be here, since most times this "focus" is done after this function runs anyway...)
For situations like moving a container we would want
follow_focus
andtrigger_focus
to be true and in the case of sending a container we would wantfollow_focus
to be false, I guess!Even though that also doesn't make much sense since this function always applies to the focused workspace, so it is probably the other way around, when sending a container we want
follow_focus
andtrigger_focus
to be true to focus the window which should now be the focused one (since we moved the previous focused one away) and when moving a container we shouldn't need that since the container we moved had the focus and should still have it, however we would probably want to do it any way in case some other operation in between had changed the foreground focus.TLDR: In summary, what I meant with this is there is nothing on this function that has to do with the
mouse_follows_focus
so that should not be set on the first parameter, however this is done in more than one place throughout the base code, I believe this might be the reason for some of the frustrations with themouse_follows_focus
not working that well... Also on this specific case of this commit, it doesn't matter what you set it to since there will be a stacked container, which means that it will always "trigger" focus (if the second parameter is true) on the stack container... However, after all this function runs, you still end up calling thewindow.focus()
any way again on the line 252 ofprocess_command
.TLDR of the TLDR: The
update_focused_workspace
function is currently confusing and might be the cause and also the fix of some weird issues. I might go and look for all its use cases to inspect if it is being used correctly or not since I suspect that sometimes it is not, but for that it should be better clarified what its use really is meant to be! And for that I need your help first!PS.: Sorry for the long, long text! 😅