Can't open new window when there is no active container

[way-cooler]

Can't open new window when there is no active container

[Timidger]

Is this bug still present on the latest master (c34f783)?

[Timidger]

Is this still an issue future me?

[valryne]

There is more which does not work without a focused container:
• launch dmenu
• open terminal (probably what you witnessed)
• all move focus keybindings
• all move active container keybindings
• all split containers keybindings
• mouse click (on window) --left/middel/right-- without moving the mouse prior to click
• mouse click (on window) --middle-- with moving the mouse prior to click
• mouse click (on window title) --middle-- with and without moving the mouse prior to click
• mouse click (on window border "resize pointer") --middle-- with and without moving the mouse prior
• all switch to workspace keybindings (for empty workspaces and current)

What works/gives back focus
• switch to non-empty workspace
• switch to empty workspace (does not actually go there) then switch to current workspace →return focus in current workspace
• click on window title --left/right-- (works even without moving the mouse first)
• click on window border (resize pointer) --left/right-- with and without moving the mouse prior
• click on window without moving --left/right-- if window was active before (like when exiting dmenu)
• click on window after moving the mouse --left/right-- right-click closes window and returns focus to upper right window on screen
• quit way-cooler

If there is at leas one floating window, then there is the following exception to the above:
works: click on window without moving the mouse --left/right-- if window is the floating one

Tried this with release version 4.0 and current master (synced yesterday) — 'cargo build' with executable in /way-cooler/target/debug and 'cargo install' with executable in ~/.cargo/bin.

---

I cannot tell, if it all boils down to the same issue, or if some should be listed as separate instances.

[Timidger]

PKGBUILD.txt

You are correct, those all boil down to the same issue. I am looking to address these in 0.4.1, mostly by making there always be some active container.

If you'd like to test it further (as more eyes are always better) feel free to test it out by using the attached modified PKGBUILD to use the branch that has these fixes. If cargo gives you a weird error in graphmap (like it did with me) imake sure you are on the latest version of cargo

[valryne]

Works.
With only tiled containers, when I quit dmenu, the last active container becomes active again.
And so far, I could not recreate the situation where there is no active container at all.

The only strange behavior is with a floating container being active before launching dmenu:
No tiled containers:
• With only one floating container, it correctly becomes active again.
• When I open >1 floating containers, the lowest one becomes active, no matter which one was active before launching dmenu.
With tiled container(s):
• No matter how many floating containers, the tiled container that was last active becomes active, regardless which floating container was active before launching dmenu. (It neither matters how many floating containers were active after the last active tiled container.)

[Timidger]

Hmm...strange I remember explicitly disallowing floating containers to remember their focus, but I don't remember why. I have disabled the artificial limitation in the latest version of #165, as it doesn't seem to break anything.