Be able to hide a window from all views, or to manage a special view

[Chadehoc]

I find that temporarily hiding a window can still be handy even in a tiled WM (where is it anyway a lot less necessary than in the standard WM). Hiding a managed window is currently a bit awkward:

• Since you cannot remove a window from its last view (ToggleWindowTag), if you want to hide it without closing it, you have to send it to another wiew.
• But fetching it again it not handy: switch to this view, make sure the window is focused, send if back, go back. Another drawback is that it also had left the taskbar of the initial view (I run bug.n with the taskbar shown).
• If the taskbar is shown, hiding a window through it just makes a hole in the tiled pattern, instead of reclaiming this space.

I propose two ways for managing hidden windows (I suspect the second is simpler to implement):

• On the model of Xmonad's BoringWindows extension, manage a "hidden stack" per view. For example, #v would hide the current window, #+v would pop back the most recently hidden. This would also make it possible in the future to manage windows that are hidden by their application (as bug.n will currently not hide those windows, this is for me a case for configuring them as not managed).
• Or more globally just consider one of the existing view as the "attic". Hiding a window would just be sending it to the attic (nothing new here), then it would just need a command to "fetch the next window in the attic view and send it to the current view", plus a variant that would exchange it with the focused window instead, allowing to cycle between windows in the attic until you get the one you wanted.

[joten]

With commit 058467de8ad4bfb7dff6721d6e8c5ab5e71f14ec it should be possible to hide windows; I tested with "ProcessExplorer" and "KeePass".

[Chadehoc]

With commit 058467d it should be possible to hide windows;
I tested with "ProcessExplorer" and "KeePass".

How so?

I just tested that with commit 67ab68343664e601547411869ea5380136515393 (feb. 21) and hiding windows "the windows way" (showing the window bar and minimising, or via the task bar) still just leaves a hole. View_activateWindow just lets it unhide back. For example the Explorer, or Foxit Reader work that way.

But for example let WinMerge be on monitor 2. Hide it the windows way: it leaves a hole, but now activating it again brings it back to... the other monitor. If I try to send it back to monitor 2 (Manager_setWindowMonitor(2)), it does so, but still managing the hole; the window AND the hole it left are tiled as two windows.

So, nothing seems changed for me since 8.3.1, hiding is not usable, very dependent on apps, and any app that works by showing and hiding windows (instead of creating and destroying them) must be configured as not managed (not tiled is not enough).

[joten]

Ah, there was a misunderstanding. By "hiding" I meant, also hiding it from the Taskbar, like "minimizing to tray", not minimizing, as you say, "the windows way".

But for example let WinMerge be on monitor 2. Hide it the windows way: it leaves a hole, but now activating it again brings it back to... the other monitor.

This may be the multi-monitor-bug #14

I see there a clash of paradigms. Minimizing windows is suitable for a stacking window manager; but for a tiling one? The provided way of hiding windows in bug.n is to tag them, i. e. move them to another view.

Why do you want the windows not to be visible, while their Taskbar icons are? Personally, I don't like the Taskbar to be cluttered. Which applications are there, that you want to temporarily hide and be able to quickly bring back into focus? -- I am just curious.

[Chadehoc]

Why do you want the windows not to be visible, while their Taskbar icons are?

The taskbar is actually not important, it's just a reminder. At home on Xmonad I have no taskbar at all. At work on Windows, even after discovering bug.n, I kept it... I may leave it entirely in some times depending on how my habits will change.

Personally, I don't like the Taskbar to be cluttered.

Bug.n does a great job de-cluttering the taskbar! I now leave much more apps running than before. It is because my taskbar is not cluttered that I would like hidden windows to be here, as reminder, showable with the mouse if I need. (I use a vertical toolbar, these is room.)

I see there a clash of paradigms. Minimizing windows is suitable for a stacking window manager; but for a tiling one? The provided way of hiding windows in bug.n is to tag them, i. e. move them to another view.

This is fine and I currently use that, but I find fetching back the window a bit awkward. I use a "garbage" view to send those windows to, then to get it them back I have to go to the view, make sure the window is focused (I usually have only one such window, but it may be unfocused anyway), then send it back, and go back to the initial view.

Which applications are there, that you want to temporarily hide and be able to quickly bring back into focus? -- I am just curious.

• When an application hides a window, bug.n keeps it shown. It would be ok if I was 1 key away to insisting to hide it. But then, when the application needs it again, I'd like to show it in just 1 key, too. For example, after sending a mail, Outlook just hides the message window. With bug.n, you keep a cleared message window... Fortunately, Manager_closeWindow next works in that particular case, but if it didn't (if the closed window was instantly recreated, as some apps do), hiding would be the solution.
• A log window. I don't want to close it because it would clear it. I like to have it tiled when I need it, but not cluttering my tiling pattern when not. Hiding and showing back is the most handy.
• Some windows (as a calculator) have almost no state and can be popped up and closed at will, without hurting. For others (editor, shell, file explorer....) I like Xmonad's notion of "scratchpad". You configure a shortcut to bring the window in your current view, whatever view it was before. When you're done, the same shortcut puts it back. Very handy.
• Some apps, as for example the window explorer, when called, will switch to any existing instance, possibly changing the current view! I would like it to be brought to the current view instead. If I could leave the app by hiding it, I hope that calling it from elsewhere (any view become current) will fetch it rather than switching to its view.

[Chadehoc]

Expliciting my needs lets me think of another solution:

• allow tagless windows. You just can remove a tag anytime.
• allow to fetch a tagless window into the current view. Re-issuing the command would cycle through tagless windows, until you find the one you want. "no tag" would be a kind of special tag that allows to pull windows out, rather than the usual "push to another tag". The most recently untagged window would be the first fetched.

Maybe I can try to contribute, if you give me some clues. The problem is, I use Windows only at work, so I would have little time for it...

[joten]

For example, after sending a mail, Outlook just hides the message window.

That is the bug from issue #21, which should be solved anyway.

I would like it to be brought to the current view instead.

That would be Config_onActiveHiddenWnds=tag, if the called Explorer window really would be an existing one; but as far as I know, it isn't. The setting would affect all existing windows, which are hidden and re-called by the shell.

allow tagless windows

In bug.n tag-less is the same as all-tags, i. e. Monitor_setWindowTag(10), if you do not want the windows to be really hidden but the Taskbar icon still visible.

I like Xmonad's notion of "scratchpad". Allow to fetch a tagless window into the current view. Re-issuing the command would cycle through tagless windows, until you find the one you want.

That sounds interesting. I will look into it.

[joten]

I gave it try with commit ff3e5ead3927993a60741a43996e49e050825a4f. You can minimize windows the bug.n way (They need to be made floating.) with Win+Ctrl+M and bring them back with either Alt+Tab or clicking on the icon in the Taskbar.

It is not like the "scratchpad" from Xmonad, but an implementation, which fits more into bug.n. Any comment is appreciated.

[Chadehoc]

I gave it try with commit ff3e5ea. You can minimize windows the bug.n way (They need to be made floating.) with Win+Ctrl+M and bring them back with either Alt+Tab or clicking on the icon in the Taskbar.

Nice, it's simple and suits me. Thanks.

Some strange unrelated behaviours when trying it:

• #t cannot be rebound, and doesn't work the initial way either. Other variants (like #+t) can. When I switch back to 8.3.1 branch, it works, so it doesn't seem to be external to bug.n.
• The command window is unusable with #y because it pops up under the window. I can bring it by clicking on the bar only, but only on monitor 1. And in 8.3.1 I could use it to test commands that apply to the current window (even if it seemed to have lost focus, it took the command). In master it doesn't seem to work.

[joten]

#t cannot be rebound

Hm, on my machine it works. I tested Config_hotkey=#t:: (disabling the hotkey in bug.n), Config_hotkey=#t::Manager_minimizeWindow() and Config_hotkey=#t::Run, explorer.exe.

The command window is unusable with #y

Again I had no luck reproducing the problem; but I am currently working in a single-monitor-configuration.