Raising windows in "Click to focus" mode

[humdinger]

This is hrev37437.

• Choose "Click to focus" mode in Mouse prefs.
• Arrange one window below another.
• Click on the lower window to give it focus.

Now, one expects to raise that lower window to the top by left-clicking the tab/border (or anywhere while holding ALT+OPT) just like in "Focus follows mouse" and "Click to activate".
Instead, currently you'll have to use a right-click in "Click to focus" mode.

[axeld]

Even worse, the left click doesn't do anything. I think this cripples this mode unnecessarily, and that should be fixed by making it consistent with how the other modes work in this regard.

[stippi]

If this ticket is about that the lower window should raise on a second left-click on the decor (when it's already focused), then I believe this used to work. Perhaps a regression after the recent refactoring?

[stippi]

Sorry, I am running an older revision and should have checked before making stupid comments... Indeed the behavior is weird and not a regression after refactoring. I expect it has been implemented this way to make it possible to move windows without raising them. But this is already avoided in FFM: Windows are raised on mouse-up, and if the mouse did not move far enough after a click on the decor (there is even a tolerance), then the window is raised. I believe the same should work for "Click to focus". What I find even worse in that mode is that right-clicking a window that is not currently focused will first raise the window. This is all very inconsistent with the other modes. IMHO this mode should work just like FFM with regards to what buttons raise and lower windows and how, with the only exception that the focus does not follow the mouse.

[axeld]

I've implemented the suggested behaviour in hrev37894.

However, I'm not sure if works as one would expect, as the actual "click to focus" now only works on the window contents. Maybe the first click should not raise the window, but only focus it, and only focussed windows would raise when clicking on their border?

Adrien, Brecht, I think you two are actually using this mode, right? What do you think about the changes, as well as the suggested further changes?

[tangobravo]

Stippi said this on the commit list in response to hrev37894:

I suppose it does not raise when you click inside the window and it does raise when you click the decorator now? Haven't checked it out, but it sounds like the window should not ever raise at all if it wasn't focused before.

That's different to my intuition. I think the "click to x" things are referring to clicks inside the window. I expect the tab to be different (and to raise on click). Maybe that's just me.

[humdinger]

I agree with tangobravo. In "Click to focus" mode, clicking inside should just focus, clicking on the tab/border should raise if the window has focus or not. (On mouse up, like in FFM, so you can move a window without raising it.)
The reason is, that if I see enough of the window to interact with it, I'll click inside the window to make it active (or operate a widget). Only if I can't see what I need, I grab the tab/border to move the window until I see it or raise the window to see everything.

In this context, don't forget that CTRL+ALT and clicking inside the window has to behave like a click to the tab/border.

[axeld]

So in other words your fine with how it works now? :-)

[brecht]

I haven't been following the latest developments, so I don't know if the behaviour has been changed before. Personally, I find the "click to focus" mode comfortable to use (obviously, having implemented it). I don't agree that it should be changed to act more like the other mouse modes, as that kind of defeats the purpose.

The way the mode was initially implemented allowed the user to raise/lower a window while dragging it. I guess that is no longer possible now?

As for the naming of the modes, I agree it could be improved upon. It was already dicussed in this thread, where some more descriptive names have been proposed: ​http://www.freelists.org/post/haiku/Mouse-Click-to-focus-mode-what-is-it-for,25

[axeld]

I wasn't aware of the dragging feature, I can see that this is useful. I would just implement it by alternating the behaviour of the right click when you click it a second time, and that would then be possible in all mouse modes.

In any case, the emulation of how the Amiga used the depth button using the right mouse button is crippling the user experience, and gives you actually less control over it, so I see no reason why this behaviour should be copied.

As I said, I would understand if the only the focussed windows could be raised via the left mouse button, because that's what makes this mode more different from the others, and would IMO fit its spirit.

[bonefish]

Replying to brecht:

I haven't been following the latest developments, so I don't know if the behaviour has been changed before. Personally, I find the "click to focus" mode comfortable to use (obviously, having implemented it). I don't agree that it should be changed to act more like the other mouse modes, as that kind of defeats the purpose.

I agree with tangobravo that the focus and Z order can be considered orthogonal, so I don't quite see why "click to focus" and FFM should work differently regarding Z order manipulation.

[humdinger]

I now tried Axel's changes and I think it fits very well in with the other focus modes. I wonder if others speaking of "drastic changes" have tried it yet. You can still move windows without raising them. Only if you click tab/border without moving it, i.e. just to focus, the window is raised. To avoid that, just click inside the window instead.

Changing z-order while dragging is still possible: A right click will send the window to back.
The one thing missing (from the FFM mode as well): If a window was sent to back, another right-click should raise it again to the top. That way you can send-to-back and raise windows with the RMB even while dragging.
(Only for "Click to activate" this isn't needed, because when right-clicking a window it loses its focus anyway.)

[axeld]

I've now implemented the right click Z order toggling during dragging in hrev37922.

[humdinger]

The reported issue of this ticket has been resolved. I'm very happy how it works now. Thanks!