Understanding the mess regarding screen.focused

[aroig]

Currently there is a bit of a mess in awesome regarding what screen.focused() means. From my perspective the issue is that there are 3 closely related concepts for "focused screen":

1. screen where the mouse is.
2. screen that will contain a newly spawned client by default (i.e. not affected by any custom rules).
3. screen with a focused client (if any).

As far as I understand, the current state is the following:

1. Awesome historically has collapsed 1 and 2 above into the same thing, which is what the old screen.focused() returned. That was convenient, but hacky.
2. Awesome made assumptions about it all over the place (or at least in client moving / navigating functions). Changing screen.focused() default behaviour breaks things in awesome. Also it couples or relies on totally distinct functionality like focus_follows_mouse, etc.
3. Some people want that screen.focused() behaves as 3 above, and it has been made configurable via args or a default configuration.

Now, I do not understand why some people (I assume @Elv13 is one of them) want screen.focused() to behave as 3. Can you clarify why do you want that? I currently see no way to make awesome usable on multi-screen setups with screen.focused() behaving as 3 above, due to the problems with empty tags, etc.

I'd argue that making the default behaviour of screen.focused() configurable is also wrong, since awesome makes assumtions on this default behaviour, and changing it will break things in awesome itself (not user configs). Eg. client navigation / movement across screens. The core problem there is that behaviour 3 above, implies that screens with empty tags are not focusable, and this breaks things.

Using behaviour 1 (mouse dictates focused screen) for screen.focused() is a bit ugly. You can work mouse-less with that behaviour, but you still rely on the mouse for dictating where new clients will appear.

I suggest decoupling the 3 concepts above, to clean-up this mess, as follows:

• Add a new global state variable screen.focused or similar. It contains the screen that will receive newly spawned clients by default (behaviour 2 above), and is non-nil as long as there are screens available. This means that when a screen goes away the screen focus changes to another screen. This is orthogonal to where the mouse is.
• A screen_focus_follows_mouse behaviour can be enabled by hooking onto a new mouse:screen_enter signal or such, the same way as client_focus_follows_mouse behaviour is provided by mouse:enter signals. Enabling this recovers current behaviour.
• behaviour 3 above where the focused client decides the focused screen can be enabled by hooking on focus signals for clients, and enforcing screen.focused to be c.screen. But still allowing navigation functions to change screen.focused to a different screen explicitly. This would, I believe, avoid the breakage of navigation functions I mentioned above.
• Replace all uses of screen.focused() with screen.focused. Clean-up the remaining assumptions in awesome about focused_screen = mouse_screen, etc.
• Add new screen_focus signals. This would allow adding visual cues for the focused screen, like dimming the non-focused screen, or changing the wibar color, etc.

I think that doing something along these lines would add a lot of flexibility, because you could add functionality by hooking on screen signals, while avoid the problems I listed above. It also clarifies the meaning of screen.focused in a clean way. @Elv13 what do you think? Would something like this work for your use case?

I can't make promises on devoting time to help with this until I have settled down with my new job by mid september or so.

[MRAAGH]

When this is a problem:

I am using unclutter to hide my mouse cursor. Whenever the invisible cursor and the focused client are on different screens, I find the relative screen controls confusing.

Steps to reproduce:

1. use default awesome configuration
2. use multiple screens
3. open Firefox on screen 2
4. open terminal on screen 1
5. run this command in terminal: firefox github.com
6. this focuses the browser window on screen 2
7. press mod+ctrl+j (focus next screen)

What I expected to happen:

The next screen from the screen with the browser should get focused

What actually happened:

The next screen from the screen with the terminal gets focused instead. If you imagine the mouse cursor invisible, this is unexpected.

About empty screens:

The core problem there is that behaviour 3 above, implies that screens with empty tags are not focusable, and this breaks things.

I propose this solution: when focusing an empty screen, the previously focused client gets unfocused. Then, since no client is focused, the mouse cursor is used for picking the "focused screen". This (unfocusing client when focusing empty screen) is the behavior I've wanted for a long time, but I was unable to get it working using the existing api. After reading @aroig's issue, I understand why.