Allow to cycle windows in native maximize/native fullscreen mode

[JSamir]

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.

[LGUG2Z]

@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. 🤞

[JSamir]

@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]

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

[ericreeves]

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]

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

[LGUG2Z]

@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.

[ericreeves]

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.

[LGUG2Z]

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.

[ericreeves]

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.