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

Allow to cycle windows in native maximize/native fullscreen mode #75

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

Originally created by @JSamir on GitHub (Jan 17, 2022).

Originally assigned to: @LGUG2Z on GitHub.

Hi,

as someone coming from dwm, I miss one "feature" very much: being able to cycle through open windows even if they are maximized/fullscreen.

I got used to having the "regular" layout (vertical-stack) only for getting an "overview" over all the open windows on this workspace (so called tag in dwm), usually having only one window on the screen.

To accomplish this in dwm, I used to

  • either switch to the monocle layout to have only the window and the bar visible
  • or switch to the monocle layout and toggle off the bar to have only this window visible

With komorebi, to accomplish the same, I use

  • toggle-maximize to have only the window and the task bar visible
  • Send {F11} to use native fullscreen which "removes" the task bar

For both of those, I would like to be able to use cycle-focus to switch between windows on this workspace but keeping the focused (switched-to) window maximized/native-fullscreened.

Not sure if possible, but this would be a great enhancement for me.

ps: right now, if I try to cycle-focues while the current window is maximized, this just "shows" the next window at it's place in the vertical-stack. If I cycle often enough, then the maximized window is shown maximized in the background and all of the windows from the stack are shown "above" it and from that point on I can only cycle with the windows from the stack and cannot return to the maximized window. If this had some kind of konsisten behavior with the option to come back to the maximized window or immeadeately make the current window from the stack maximized, I think I could also arrange with this.

Originally created by @JSamir on GitHub (Jan 17, 2022). Originally assigned to: @LGUG2Z on GitHub. Hi, as someone coming from dwm, I miss one "feature" very much: being able to cycle through open windows even if they are maximized/fullscreen. I got used to having the "regular" layout (vertical-stack) only for getting an "overview" over all the open windows on this workspace (so called tag in dwm), usually having only one window on the screen. To accomplish this in dwm, I used to - either switch to the monocle layout to have only the window and the bar visible - or switch to the monocle layout and toggle off the bar to have only this window visible With komorebi, to accomplish the same, I use - `toggle-maximize` to have only the window and the task bar visible - `Send {F11}` to use native fullscreen which "removes" the task bar For both of those, I would like to be able to use `cycle-focus` to switch between windows on this workspace but keeping the focused (switched-to) window maximized/native-fullscreened. Not sure if possible, but this would be a great enhancement for me. ps: right now, if I try to `cycle-focues` while the current window is maximized, this just "shows" the next window at it's place in the `vertical-stack`. If I cycle often enough, then the maximized window is shown maximized in the background and all of the windows from the stack are shown "above" it and from that point on I can only cycle with the windows from the stack and cannot return to the maximized window. If this had some kind of konsisten behavior with the option to come back to the maximized window or immeadeately make the current window from the stack maximized, I think I could also arrange with this.
adam added the enhancement label 2026-01-05 14:48:08 +01:00
adam closed this issue 2026-01-05 14:48:08 +01:00
adam commented 2026-01-05 14:48:08 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Feb 1, 2022):

@JSamir check out this branch, I think it achieves the desired behaviour with regards to cycling window container focus when a window container is maximized or set in monocle mode on a workspace. 🤞

@LGUG2Z commented on GitHub (Feb 1, 2022): @JSamir check out [this branch](https://github.com/LGUG2Z/komorebi/compare/feature/cycle-focus-monocle-maximized), I think it achieves the desired behaviour with regards to cycling window container focus when a window container is maximized or set in monocle mode on a workspace. 🤞
adam commented 2026-01-05 14:48:08 +01:00
Author
Owner
Copy Link

@JSamir commented on GitHub (Feb 3, 2022):

@LGUG2Z Thanks!

In general, it works 👍

But, there is a lot of flickering involved. It flickers "so much" that I could make the following observation ( :-D ):
It seems that in order to switch to the other window, the windows are first tiled again. And this intermediary step makes the windows appear to flicker. Not sure if flickering would entirely be gone without this step, but I guess it would be a huge improvement at least.

Do you think something can be done about that?

@JSamir commented on GitHub (Feb 3, 2022): @LGUG2Z Thanks! In general, it works 👍 But, there is a lot of flickering involved. It flickers "so much" that I could make the following observation ( :-D ): It seems that in order to switch to the other window, the windows are first tiled again. And this intermediary step makes the windows appear to flicker. Not sure if flickering would entirely be gone without this step, but I guess it would be a huge improvement at least. Do you think something can be done about that?
adam commented 2026-01-05 14:48:08 +01:00
Author
Owner
Copy Link

@JSamir commented on GitHub (Feb 3, 2022):

Btw: I disabled animations in windows hoping to lessen the flickering, but that did not really help significantly.

@JSamir commented on GitHub (Feb 3, 2022): Btw: I disabled animations in windows hoping to lessen the flickering, but that did not really help significantly.
adam commented 2026-01-05 14:48:08 +01:00
Author
Owner
Copy Link

@ericreeves commented on GitHub (Mar 29, 2022):

I just merged master into this branch to bring the latest changes in and built it locally, and everything seems to be working fine. This is a bit of functionality I was missing from "monocole" / "fullscreen" mode.

@JSamir I see the behavior you described with the re-tiling leading to "flickering". It only happens with windows in "monocle" mode via komorebi or maximized. Native full-screen apps (F11) switch perfectly with no artifacts.

@ericreeves commented on GitHub (Mar 29, 2022): I just merged master into this branch to bring the latest changes in and built it locally, and everything seems to be working fine. This is a bit of functionality I was missing from "monocole" / "fullscreen" mode. @JSamir I see the behavior you described with the re-tiling leading to "flickering". It only happens with windows in "monocle" mode via komorebi or maximized. Native full-screen apps (F11) switch perfectly with no artifacts.
adam commented 2026-01-05 14:48:08 +01:00
Author
Owner
Copy Link

@ericreeves commented on GitHub (Mar 29, 2022):

I made my terminal, Alacritty, about 60% transparent, and what is happening in monocle/maximized is clear to me now. It seems that whichever window is not focused is still sitting behind the focused window in the original position. The behavior is the same with more than 2 windows present as well.

I wonder if the "flickering" might be minimized if all non-focused windows were minimized/hidden when monocle/maximize was engaged? That is simply a guess...

I took a few screenshots and posted them here for reference.

https://imgur.com/a/Zx63iuH

@ericreeves commented on GitHub (Mar 29, 2022): I made my terminal, Alacritty, about 60% transparent, and what is happening in monocle/maximized is clear to me now. It seems that whichever window is not focused is still sitting behind the focused window in the original position. The behavior is the same with more than 2 windows present as well. I wonder if the "flickering" might be minimized if all non-focused windows were minimized/hidden when monocle/maximize was engaged? That is simply a guess... I took a few screenshots and posted them here for reference. https://imgur.com/a/Zx63iuH
adam commented 2026-01-05 14:48:09 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Mar 29, 2022):

@ericreeves @JSamir Can you try pulling a fresh copy of this branch? I ended up screwing up the branch so I cut a new one and pushed over the top of what was already on GitHub (to get a fresh copy- git checkout master, git branch -D feature/cycle-focus-monocle-maximized, git checkout feature/cycle-focus-monocle-maximized)

I've made a couple of changes which have reduced the flickering for me for native applications (though some flickering still persists with Electron applications; this is an issue for the upstream Electron and/or Chromium repos).

Instead of calling the toggle_maximize and toggle_monocle convenience functions twice, which causes the updates to be drawn on the screen twice, I've replaced the first calls with the slightly lower-level unmaximize_window and monocle_off fns which update the underlying state without redrawing the layout on the workspace.

@LGUG2Z commented on GitHub (Mar 29, 2022): @ericreeves @JSamir Can you try pulling a fresh copy of this branch? I ended up screwing up the branch so I cut a new one and pushed over the top of what was already on GitHub (to get a fresh copy- `git checkout master`, `git branch -D feature/cycle-focus-monocle-maximized`, `git checkout feature/cycle-focus-monocle-maximized`) I've made a couple of changes which have reduced the flickering for me for native applications (though some flickering still persists with Electron applications; this is an issue for the upstream Electron and/or Chromium repos). Instead of calling the `toggle_maximize` and `toggle_monocle` convenience functions twice, which causes the updates to be drawn on the screen twice, I've replaced the first calls with the slightly lower-level `unmaximize_window` and `monocle_off` fns which update the underlying state without redrawing the layout on the workspace.
adam commented 2026-01-05 14:48:09 +01:00
Author
Owner
Copy Link

@ericreeves commented on GitHub (Mar 29, 2022):

HUGE improvement! Night and day difference! Well done.

I do still think it would be cool if the non-focused windows were hidden/minimized, so that I could clearly see my fancy wallpaper through my semi-transparent monocle/maximized windows, but that's a bit more subjective. :)

Cheers, and thank you.

@ericreeves commented on GitHub (Mar 29, 2022): HUGE improvement! Night and day difference! Well done. I do still think it would be cool if the non-focused windows were hidden/minimized, so that I could clearly see my fancy wallpaper through my semi-transparent monocle/maximized windows, but that's a bit more subjective. :) Cheers, and thank you.
adam commented 2026-01-05 14:48:09 +01:00
Author
Owner
Copy Link

@LGUG2Z commented on GitHub (Mar 29, 2022):

I do still think it would be cool if the non-focused windows were hidden/minimized, so that I could clearly see my fancy wallpaper through my semi-transparent monocle/maximized windows, but that's a bit more subjective. :)

This is actually possible, you can replace the contents of monocle_on and monocle_off in window_manager.rs with the following snippets, but the flickering is even worse than it was originally. 😞

#[tracing::instrument(skip(self))]
pub fn monocle_on(&mut self) -> Result<()> {
    tracing::info!("enabling monocle");

    let workspace = self.focused_workspace_mut()?;
    workspace.new_monocle_container()?;

    let windows = workspace.visible_windows_mut();
    for window in windows.into_iter().flatten() {
        window.hide();
    }

    Ok(())
}

#[tracing::instrument(skip(self))]
pub fn monocle_off(&mut self) -> Result<()> {
    tracing::info!("disabling monocle");

    let workspace = self.focused_workspace_mut()?;
    workspace.reintegrate_monocle_container()?;
    workspace.restore(false)
}

On the other hand, ensuring that all windows are drawn behind the monocle window at the same size reduces the flickering when cycling focus in monocle mode even further.

pub fn update(
    &mut self,
    work_area: &Rect,
    offset: Option<Rect>,
    invisible_borders: &Rect,
) -> Result<()> {
    // ...

    if *self.tile() {
      // ...
    }

    if self.monocle_container().is_some() {
        let windows = self.visible_windows_mut();
        for window in windows.into_iter().flatten() {
            window.set_position(&adjusted_work_area, invisible_borders, false)?;
        }
    }

    // ...

    Ok(())
}

However, the trade off with this is that it introduces significant flickering when disabling monocle mode. 🤔

I think this is something that should be behind an opt-in configuration option that defaults to the current behaviour to minimize disruption to existing users. I will track this in a separate ticket and add it in the next couple of days.

@LGUG2Z commented on GitHub (Mar 29, 2022): > I do still think it would be cool if the non-focused windows were hidden/minimized, so that I could clearly see my fancy wallpaper through my semi-transparent monocle/maximized windows, but that's a bit more subjective. :) This is actually possible, you can replace the contents of `monocle_on` and `monocle_off` in `window_manager.rs` with the following snippets, but the flickering is even worse than it was originally. 😞 ```rust #[tracing::instrument(skip(self))] pub fn monocle_on(&mut self) -> Result<()> { tracing::info!("enabling monocle"); let workspace = self.focused_workspace_mut()?; workspace.new_monocle_container()?; let windows = workspace.visible_windows_mut(); for window in windows.into_iter().flatten() { window.hide(); } Ok(()) } #[tracing::instrument(skip(self))] pub fn monocle_off(&mut self) -> Result<()> { tracing::info!("disabling monocle"); let workspace = self.focused_workspace_mut()?; workspace.reintegrate_monocle_container()?; workspace.restore(false) } ``` On the other hand, ensuring that all windows are drawn behind the monocle window at the same size reduces the flickering when cycling focus in monocle mode even further. ```rust pub fn update( &mut self, work_area: &Rect, offset: Option<Rect>, invisible_borders: &Rect, ) -> Result<()> { // ... if *self.tile() { // ... } if self.monocle_container().is_some() { let windows = self.visible_windows_mut(); for window in windows.into_iter().flatten() { window.set_position(&adjusted_work_area, invisible_borders, false)?; } } // ... Ok(()) } ``` However, the trade off with this is that it introduces significant flickering when disabling monocle mode. 🤔 I think this is something that should be behind an opt-in configuration option that defaults to the current behaviour to minimize disruption to existing users. I will track this in a separate ticket and add it in the next couple of days.
adam commented 2026-01-05 14:48:09 +01:00
Author
Owner
Copy Link

@ericreeves commented on GitHub (Mar 29, 2022):

I tried it out, and I see exactly what you mean. And clearly this quick patch only effects monocle windows, not maximized.

If it was behavior you could toggle with a komorebic command, either on demand or through assigning each workspace a "mode", I might toggle it strictly on the workspace that houses my pretty transparent terminals. This may be over-complicating the code base for an edge case, though.

In reality, very few applications in Windows support proper transparency anyway. If certainly feels like the default behavior should be as flicker-free as possible!

Thanks again for the work.

@ericreeves commented on GitHub (Mar 29, 2022): I tried it out, and I see exactly what you mean. And clearly this quick patch only effects monocle windows, not maximized. If it was behavior you could toggle with a komorebic command, either on demand or through assigning each workspace a "mode", I might toggle it strictly on the workspace that houses my pretty transparent terminals. This may be over-complicating the code base for an edge case, though. In reality, very few applications in Windows support proper transparency anyway. If certainly feels like the default behavior should be as flicker-free as possible! Thanks again for the work.
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#75
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?