Overall focusing problem on Desktop

[Karvjorm]

This can be a duplicate, but focus and focusing are a bit noisy search keys.

When using Haiku Desktop, focus do not follow automatically from Desktop to application window. For example. I can click the Blank_BFS icon to open a disk. Then I click some file to open it in the editor. When then start to edit the file, focus is there and it is the active window with yellow title. But Blank_BFS icon text is still black and focus was not cancelled in the Desktop (could hrev6074 (https://dev.haiku-os.org/changeset/6074) have tried to fix this problem?).

There can be some symptoms that may depend on the same problem. I have seen some error messages in syslog complaining mouse data errors. Also, when I tried to save some patch in trac ticket in WebPositive tab window, the result was several copies of the same patch. My guess was that it was because during the work I looked at another tab or some other Desktop document and WebPositive did not notice that focus was changed.

[stippi]

In Haiku (and BeOS), each individual BWindow has a BView that has the current focus. However there is only one active BWindow at any time, too. Most applications listen for the activation state change of a window and change the visual appearance of the (still focused) BView accordingly. For example Tracker will render selected items gray in inactive windows, and black in active windows. This is the intentional behavior. One of the reasons why it works this way is that when a window becomes active again, the control that was last focused in that window should have the focus again, which automatically works this way. All the application has to do is watch for the activation event of a window and cause the focused view to repaint.

I am not quite sure what happened at your end that caused you to log this ticket, but maybe you can watch the behavior again with what I have written and decide whether there is indeed a bug somewhere or not.

[Karvjorm]

OK, when I tested desktop after your explanation, it works obviously as it should. I just was waiting for something like howering from icon to icon on the empty (not open applications) Windows Desktop. If you move mouse cursor on the Home icon (for example) and click it once, focus is moving from Blank_BFS icon (for example) to Home icon, so this is not really a bug. Only different behaviour. And reason for those other sympton is something else. I will change this ticket invalid. Thanks.

[diver]

When I use keyboard to navigate and open some file on the desktop (e.g. in StyledEdit) and then close it's window via alt+w that file is still selected (has black background) but I'm not able to open it anymore using enter key, nor can I select other icons using arrow keys. Looks like some other application is stealing focus or Tracker looses it itself. I think it works only when ffm is turned on.

[jonas.kirilla]

Replying to diver:

When I use keyboard to navigate and open some file on the desktop (e.g. in StyledEdit) and then close it's window via alt+w that file is still selected (has black background) but I'm not able to open it anymore using enter key, nor can I select other icons using arrow keys. Looks like some other application is stealing focus or Tracker looses it itself. I think it works only when ffm is turned on.

What you're seeing is a result of two things. 1. Deskbar receives focus when you close StyleEdit. (If there are no other non-desktop windows around.) You can verify that Deskbar has focus by pressing e.g. Alt-Escape. And 2. the desktop does not color the icon labels gray when it loses focus, as do the other Tracker windows. They stay black.

FFM likely mitigates this if the pointer often ends up on the desktop, in your usage pattern.

[diver]

Confirmed, Deskbar indeed receives focus, but I would expect it to return to Tracker (Desktop window) instead.

[axeld]

I think the app_server even specifically contains code to prefer other windows than the Desktop when focusing. I can't really think of a good reason on why it should do that, though, and I don't remember why I implemented it that way -- probably because BeOS does the same.

[bonefish]

Replying to axeld:

I think the app_server even specifically contains code to prefer other windows than the Desktop when focusing. I can't really think of a good reason on why it should do that, though, and I don't remember why I implemented it that way -- probably because BeOS does the same.

It does and I found it annoying there already. Using FFM solves the issue. :-)

[jonas.kirilla]

Some people find FFM simply unpalatable. :P

[axeld]

I've looked into the issue, and the reason is quite simple: the focus is always given to the front window, and since the desktop cannot ever become the front window, it only gets focus if you ask for it, or it's the only window around.

The app_server already maintains a list that contains the focus order (for FFM), I could let it use it always, and see how it goes. Opinions?

[jonas.kirilla]

Would be interesting to try.

[stippi]

Definitely sounds worth trying. I am wondering whether that might also fix some issues I couldn't quite put my finger on before, like when you have a non-front-most window in FFM open up another window where you need to type something, then the new window closes and the focus is sometimes not back to the other window. Not sure if that really happens, but it sounds like something I was irritated by before...

[axeld]

Enabled in hrev41264 - if this should be kept, the commented out parts can be cleaned up.

[diver]

Finally, Desktop is much more usable with keyboard. Thanks a lot!

[diver]

The only issue I've found so far is that once I switch from desktop to another team using twitcher (opt+tab) I'm not able to get focus on desktop back.

[axeld]

Replying to diver:

The only issue I've found so far is that once I switch from desktop to another team using twitcher (opt+tab) I'm not able to get focus on desktop back.

What do you mean not able to get focus back to the desktop? Without using the mouse, I guess? Twitcher hides the desktop as potential focus candidate. What are your exact steps to reproduce the problem?

[diver]

Yes, without using the mouse. For instance if I open and close Deskbar menu I can't set focus to the desktop (e.g. to select desktop icons using arrow keys) using twitcher when I select Tracker in twitcher window using keyboard.

[anevilyak]

With these changes, if one uses right click to send a window to back, it can be somewhat annoying because AFAICT you can no longer just click the window to bring it back the front, you have to explicitly defocus it by clicking somewhere else and then clicking the window again (click to focus mode).

[axeld]

Finally implemented in hrev45252. Seems to work nicely now.