allow disabling scratch mode

[KiaraGrouwstra]

I love PaperWM. I don't like Scratch mode. I had the habit of minimizing windows in Gnome using Alt-Space-Space. As PaperWM adds a Scratch option on top, this now defaults to Scratch. Even if a window is properly minimized (using Mod-H or the above-mentioned menu), when focus is restored to it, it returns in Scratch mode. To me, this means that even if I wanna switch to a different window, the Scratch window will still force itself upon me, until by mouse I take it back out of Scratch mode again.

Ideas:

• Don't enable Scratch when restoring from minimize
• Alternatively, allow disabling this behavior, including maybe the added Scratch context menu item

[hedning]

When minimizing a window it's no longer really tiled, which means it's quite natural for it to become floating when restored. It's of course possible to remember the «position» of a minimized window and attempt to restore it when it regains focus, but that seems honestly a bit strange to me.

An alternative would be some form of collapse/expand (which we've thought about adding), but that require some design work to figure out how to best indicate and select collapsed windows. So until someone fleshes that out, minimize will most likely work the way it currently does.

Here's some stuff you can try out in user.js though:

You can add this to the enable function in user.js to disable the context menu item (not guaranteed to work forever though):

let WindowMenu = imports.ui.windowMenu;
let Scratch = Extension.imports.scratch;
WindowMenu.WindowMenu.prototype._buildMenu = Scratch.originalBuildMenu;

And here's an easy keybind action you can try out that pushes the current window to the back of the tiling for something that's akin to a minimize that keeps the window tiled:

    let Keybindings = Extension.imports.keybindings;
    Keybindings.bindkey('<super>d', 'push-window', (metaWindow) => {
        let space = Tiling.spaces.spaceOfWindow(metaWindow);
        Tiling.animateWindow(metaWindow)
        space.removeWindow(metaWindow)
        space.addWindow(metaWindow, space.length)
        Main.activateWindow(space.selectedWindow)
    })

[KiaraGrouwstra]

Thank you for your response! I like these a lot. I think it would be nice if that were to happen automatically when restoring a minimized window. Then we could do without remembering position. As that's a change in behavior though, I wonder how others might feel about it.

[fmoralesc]

I totally agree with @tycho01, I think retiling windows that are restored from minimization would be a nice change of behaviour, or at least something that could be nice to have as an option. I tend to minimize windows to have something like a 'narrowed' workspace: logically, all the windows I have open (in a workspace) belong to the same project or workflow, but in some cases I want to narrow that to a specific set of windows without moving them to a separate workspace (where I would work with a different set of applications).

[hedning]

Yeah, narrow functionality would be nice, and letting minimize «collapse» the tiled window would probably make sense. But I'm not certain how to best «expand» windows, eg. how to indicate there's windows to expand or integrating the overview.

[fmoralesc]

Just tiling unminimized windows would do the trick, I think.

On Fri, Nov 22, 2019, 3:59 PM Tor Hedin Brønner notifications@github.com wrote:

Yeah, narrow functionality would be nice, and letting minimize «collapse» the tiled window would probably make sense. But I'm not certain how to best «expand» windows, eg. how to indicate there's windows to expand or integrating the overview.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/paperwm/PaperWM/issues/162?email_source=notifications&email_token=AABWCGKJL6KK72EJOHX6NULQU7XWZA5CNFSM4IHEXDO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE536YQ#issuecomment-557563746, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABWCGLFG4455AFBF7YDW4LQU7XWZANCNFSM4IHEXDOQ .

[olejorgenb]

Simply inserting them into the tiling again as if they were new windows you mean?

[fmoralesc]

Yes, exactly that. Their position in the stack is not as important as having them tiled.

[fmoralesc]

I missed something before from @hedning's comment. I tend to use dash to dock, so I get an overview of opened windows by default that's easily accessible. That isn't the case in default GNOME, which is something I hadn't considered; and indeed, it would be necessary to indicate that there are minimized/collapsed windows.

[hedning]

Ok, made a quick prototype: https://github.com/paperwm/PaperWM/compare/tile-on-unminimize

[fmoralesc]

Cool! I'll try it out and I'll let you know how it feels.

[fmoralesc]

I've been playing with the prototype, and I like it a lot. I think that would be sufficient, at least for me.

[hedning]

Yeah, trying it out, I think it can be pretty nice. We'll need to fix the alt-tab preview though, it doesn't pop up where it will be inserted currently.

[hoosierEE]

My brain is incompatible with scratch mode, and I'd like to try this prototype, but I know nothing about gnome extensions. I have the repo and can ./install.sh from the develop branch, but if I git checkout bc30cd5509c5ccb387a459487f698e737387bb2b (the commit referenced in https://github.com/paperwm/PaperWM/compare/tile-on-unminimize ) there is no install.sh script, so I don't know how to try this prototype.

Really liking PaperWM, but somehow I keep getting stuck in scratch mode and so this prototype sounds perfect for me.

Thanks in advance if you have time to help! -Alex

[wyrd-code]

Any news on this? Can we have this as an optional behavior perhaps?

I absolutely never use or need the scratch layer. This would remove the last frustrating thing about the OS UI I have left to resolve.

Paper WM is awesome btw, thank you for building it!

[hedning]

If we get time/motivation to implement «minimized tiled windows» we'll probably make it default.

Looking at this again, it might not be that much work to implement. We'll see when we get time/motivation, unfortunately I currently have less time working on paperwm for the foreseeable future.

[wyrd-code]

@hedning Tx for info.

If it doesn't look too bad, perhaps you could just describe what needs to be done in short terms if you find the time, so someone else can perhaps take it over and submit a PR.

Cheers

[hedning]

https://github.com/paperwm/PaperWM/commit/bc30cd5509c5ccb387a459487f698e737387bb2b is a good start.

Here we might want to use meta_window.is_on_all_workspaces() instead of meta_window.minimized to persist the state through X11 restarts (if IIRC this isn't done since it causes problems with workspaces-only-on-primar, but that really doesn't work at all anyways) https://github.com/paperwm/PaperWM/blob/four-finger-swipe/tiling.js#L1275-L1284

The real work is probably fixing up alt-tab here (https://github.com/paperwm/PaperWM/tree/virtual-tiling-playground might be useful here): https://github.com/paperwm/PaperWM/blob/four-finger-swipe/liveAltTab.js#L117-L120