Awesome: not-maximized apps go "beneath the maximized app"/"disappear" when clicking on their taskbar item and moving mouse from it when there exists a maximized app

[xor512]

Output of awesome --version:

awesome --version
awesome v4.2-525-g7d097691 (Human after all)
• Compiled against Lua 5.3.5 (running with Lua 5.3)
• D-Bus support: ✔
• execinfo support: ✔
• xcb-randr version: 1.6
• LGI version: 0.9.2

How to reproduce the issue:

1. Launch wicd-tray &. Then minimize it to tray. Then open Firefox (or something else). Make it maximized (mod-m). Then open wicd gui client by clicking on it's tray icon. Move the mouse out of the tray icon and the panel with taskbar, systray and everything to reach wicd manager -> wicd manager "disappears" "beneath" the maximized FIrefox.

2. Another way to reproduce: open something and maximize it (Firefox, QtCreator). Press mod-Enter to bring up a terminal (not maximized). Switch to maximized app. Now click on taskbar item representing a terminal -> it will appear. But once you move mouse out of taskbar it disappears. The only way to to switch to it without shortcuts like mod-j/k is to maximize it right after clicking on the taskbar item of it (with mod-M), otherwise, while I try to "reach it" with mouse, I move the cursor out of taskbar item for this non-maximized app disappears below the maximized app.

I think this started to happening after switching to git version. Should i revert back to a stable one?

This is really annoying and I think I have not seen that before.

Expected result:

No matter if on a tag there exists a maximized application it should not always appear on top of non-maximized when they are brought up by clicking on their taskbar element and then mouse is moved out of taskbar to reach them.

[xor512]

I can confirm that rolling back to an Arch repo version:

[ss@arch ~]$ awesome --version
awesome v4.2 (Human after all)
 • Compiled against Lua 5.3.5 (running with Lua 5.3)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.6
 • LGI version: 0.9.2

fixed the issue. So something bad is happening in recent git version

[Veratil]

1. Another way to reproduce: open something and maximize it (Firefox, QtCreator). Press mod-Enter to bring up a terminal (not maximized). Switch to maximized app. Now click on taskbar item representing a terminal -> it will appear. But once you move mouse out of taskbar it disappears. The only way to to switch to it without shortcuts like mod-j/k is to maximize it right after clicking on the taskbar item of it (with mod-M), otherwise, while I try to "reach it" with mouse, I move the cursor out of taskbar item for this non-maximized app disappears below the maximized app.

Just an FYI for the devs, I cannot reproduce this one on my git-master. I hadn't tried the first since I don't have wicd-tray.

[xor512]

Do you have an "old" config for the stable version? I've took the one in /etc/xdg/awesome and applied my changes and the problem come in with git-master. After reverting to previous version and taking /etc/xdg/awesome and applying my changes the problem go away. Maybe if I'd used awesome from git with the old config everything would've worked? I dont' know (confused)

[Veratil]

Try reproducing with the default config first, if it doesn't reproduce there then it might be a problem with your config. At that point we just have to track down what's causing it.

[blueyed]

Sounds like focus-follows-mouse raises the client, instead of just focusing it.
The default config has this indeed: https://github.com/blueyed/awesome/blob/15635ab9c33e7af4ca24339e8a09db616e8fab35/awesomerc.lua#L595-L597

Via https://github.com/blueyed/awesome/commit/e0d1b404c596ac46674243d9a34ac07c7fb0daf5 - I don't think raise = true is good there, is it?

/cc @Elv13

[xor512]

With the old config and awesome-git everything works. But I've just taken what was in /etc/xdg/awesome/ec.lua from awesome-git and applied my changes to there. I just changed the lines which change in old config to be the lines from the new config. Here's the old one (working for both awesome and awesome-git: https://pastebin.com/raw/B5WYqU2G. Here's the new one with my changes applies (taken from /etc/xdg/awesome/config and appliying my changes: https://raw.githubusercontent.com/xor512/dotfiles/master/home/ss/.config/awesome/rc.lua

As you can see the diff is really only about changes in between awesome and awesome-git. The diff between then looks as follows: https://pastebin.com/JxE0Ejz5. As you can see the changes are mostly about adapting /etc/xdg/awecome/config to mine, nothing more. And I suppose something is wrong with the new config of awesome-git at least for floating layouts, as old one based on old /etc/xdg/rc.lua is working and the same one but based on /etc/xrg/rc.lua from awesome-git screwed up something (and it's definitely not me as I've just applied my changes using meld trying not to break anything

[blueyed]

@xor512
Try removing the raise=true for the sloppy focus (see my previous comment) - it is mentioned in your diff, so I am pretty sure that's the reason for this.
It should not only affect maximized clients, but also two floating overlapping clients.

[xor512]

@blueyed so the mouse while "traversing" from taskbar to not-maximized xfce4-terminal "hits" the maximized "Firefox" or whatever and raises it instead of focusing? That sounds like a solid explanation of what is happening. And this is annoying. I know I should only use hotkeys like in i3 but I love awesome for allowing me using it this way and this way and this other way. So raising a window while mouse hits it is not good since it makes the currently raised one go beneath the "accidentaly" "hitted" one with a mouse (which happens to be the biggest ince (the maximized one). Just cannot get to my not-maximized xfce4-terminal without hitting the maximized Firefox and here is goes, Firefox raises and my xrfce4-terminal is gone.

Thanks for the explanation. I'll watch this and until it is fixed will stay with the Arch version of default config (slightly modified for my needs).

Thanks again for the explanation!

[xor512]

@blueyed I'll try tomorrow. Just didn't want to modify stuff I don't understand. Will confirm tomorrow morning if this helped

[xor512]

@blueyed Removing { raise = true } fixed the issue. Should I close this bug since you will file it with a proper name somewhere else and someone will fix it or should I leave it opened? Or should I create new more concise bug with better description myself?

BTW Thank you!

[xor512]

@blueyed I'm seeing another mess. Not a problem, but it is ugly It is in both places at the top:

0: local hotkeys_popup = require("awful.hotkeys_popup").widget
1: -- skip
2: -- Enable hotkeys help widget for VIM and other apps
4: -- when client with a matching name is opened:
5: require("awful.hotkeys_popup.keys")

0 should be moved in place of 5 which should be removed. Or I might be just wrong because they import different things? But I've remove 5 and it is still working fine (with gvim w/o problems) and the config is readable by awesome w/o errors.

[blueyed]

@xor512
Thanks for confirming. Created https://github.com/awesomeWM/awesome/pull/2595 to fix it.

As for the issue from the previous comment: this was added/changed in cf5b0b51e.
/cc @actionless @Sorky
Code: https://github.com/blueyed/awesome/blob/81a0a8cc48654f3670c377e11ce8ee07366c0de5/awesomerc.lua#L17-L20

[blueyed]

Ah, the quoted code is from before: https://github.com/blueyed/awesome/blame/c20573e6ddf781f272795b0e594747e52cc1d631/awesomerc.lua#L17-L20 - so mainly for @actionless I guess.

[actionless]

But I've remove 5 and it is still working fine (with gvim w/o problems)

that shouldn't happen (it should show only awesome hotkeys without that import)

could you please update to the latest git master and double check?

[xor512]

@actionless @blueyed indded removing the line 5 and pressing mod-s over vim stops showing vim hotkeys. So it was a useful feature. Will fix my dotfiles, thanks.

[xor512]

As a separate bug was created for changing raise from true to false in emitting signal for mouse_enter and for me it doing it in my config helped (#2595), I'm closing this one.

[actionless]

also instead of require-ing all the keys, you could require only specific submodule with the app you need

[actionless]

@Elv13, i remember we were discussing documentation for the thing in the message above about a month ago or so, it seems we need to get back to it :-)

[Sorky]

Looks like I'm too slow to react on this one, but you guys have it licked!

I use a very sloppy focus and can definitely confirm the mentioned behaviour - This is not a solution and not a particularly nice 'workaround', but it works for me...

• Click on taskbar item representing a terminal - DO NOT RELEASE
• it will appear
• move mouse over to it
• then RELEASE

[blueyed]

@Sorky
You should just adjust your config according to the change in #2595 I guess.. :)

You might also be interested in providing feedback on https://github.com/awesomeWM/awesome/pull/183#issuecomment-455785370.

[xor512]

@Sorky it took me ~5 minutes to understand what you are saying (release - means release mouse button) and if I understood that correct and that is supposed to be the default behavior it is very different from any other non-tiling window manager. And if I'm having a floating tag I suppose it will work much like anything non-tiling out there (xfce, lxde, kde, gnome, whatever). Maybe in i3/q-tile/xmonad it is the default behavior on floating tags then I'm sorry for not RTFM.

But IMHO this is counter-intuitive.

[warptozero]

BTW, if anyone's looking for a compromise for sloppy focus with or without raise (it's really handy but you lose so many windows behind bigger ones) then you can raise only on the titlebars (if you have them enabled):

-- Raise only on titlebars
client.connect_signal("request::titlebars", function(c)
    awful.titlebar(c):connect_signal("mouse::enter", function()
        c:emit_signal("request::activate", "titlebar", { raise = true })
    end)
end)

This can be used independent of the normal sloppy focus.

[warptozero]

@blueyed https://github.com/awesomeWM/awesome/pull/183#issuecomment-455785370 Hey this is pretty cool. This only focusses the underlying window when you keep the mouse still for a moment. Works great with raise = true and a timeout of 0.03.

[Sorky]

@Sorky it took me ~5 minutes to understand what you are saying (release - means release mouse button)

Sorry it seemed unclear - Glad you finally understood though

if I understood that correct and that is supposed to be the default behavior

Not sure about if the click and hold then move without releasing is an awesome thing or specific to my config or even how it compares to other WMs. Just a behaviour I have seen and am sharing in case it is of any value

[Sorky]

You should just adjust your config according to the change in #2595 I guess.. :)

I'm used to how it is and I'm not bothered, but I may just look at it!

[blueyed]

@warptozero

@blueyed #183 (comment) Hey this is pretty cool. This only focusses the underlying window when you keep the mouse still for a moment. Works great with raise = true and a timeout of 0.03.

Yes, I think it is a good improvement also.
Just wondered why you would want to use raise=True - I often just change focus by throwing the mouse over to another window, but would not want it to raise then. If needed that's just another click away.

[warptozero]

Well that's a good question. One annoyance I have with click-to-raise is that a click often has consequences inside a window (like moving the cursor in an editor, or clearing/moving the selection, or following a link), so you need to find an empty space where it's safe to click. Now this isn't a huge task but it does require some mental effort that I would prefer to eliminate. And I find myself pretty regularly undoing an unintentional random click (terminals are mostly safe but graphical file managers with single-click-to-open enabled are a minefield).

So far I haven't found an ideal solution. I thought about catching the first click in a background window without sending it to the client and raising on that + sloppy focus, but that will lead to lots of extra clicks and probably start to annoy fast. And being able to scroll or type in a background window without raising it is also nice. I'm using a trackpad so using dedicated mouse buttons for focussing/raising is also not an option. Gestures would be nice but support on linux for that is still rather lacking.

The thing is also that there are multiple use cases. Sometimes it's both hands on keyboard and using only keybindings, other times when reading with multiple windows open it's trackpad only and even switching hands to prevent RSI, and having good control over focussing and raising without having to move back to the keyboard is important.

Anyhow, maybe a separate thread would be a better place for this, but I'm really interested if anyone is using some unorthodox solution for this and handling windows in general. I'm actually back to using a floating layout (+ bindings to manipulate window size and position, and automatically rearranging everything) because most clients don't like being forced too small or too big, especially browser windows with web pages that lose their position or become unreadable and are often sluggish in rerendering.

BTW I'm still amazed with how awesome enables the user to completely shape this interface.

[actionless]

minefield

i have it partially solved by changing cursor when it's hovered on-border: it allows to click on border of a client instead of content area

and generally makes it easier to move/resize windows by using their border

some unorthodox solution for this and handling windows in general.

handling specifically hover on top border allows some extra mouse-specific helpers: https://user-images.githubusercontent.com/1655669/37938375-cfbe484c-315d-11e8-836e-1933cfe1f307.gif

[warptozero]

That's a nice addition, found your config, I'll check it out!