Capture first mouse event on macOS.

[xStrom]

This PR allows druid to receive the first mouse click when the click also makes the druid window active.

When you open the macOS calculator, switch to another app, then click a calculator button it will register the click even though it wasn't active. This does not work with the druid calculator example. With this PRs change applied, the druid calculator will also receive the click event.

[cmyr]

This is interesting; it's false by default, and I think that's reasonable. I could imagine this being an option, but I'm not totally sure we would want it to be on by default?

[xStrom]

This is true by default for controls like NSButton. It's widely true in Apple developed macOS apps. Safari has it true for buttons, Notes has it true, Calculator has it true etc. Right now druid is the one false example I have.

I think it's completely reasonable to have it as true. What's the downside here? Some non-controller widget getting a click event?

[cmyr]

The downside is clicking in a background window to gain focus, and accidentally initiating some interaction, like deselecting some selected text or applying some edit to an image in an image editor, etc.

Notes does not have this behaviour if you click in the text region; it does not change the selection. (select all in notes, focus another app, click in the selected region; the selection is unchanged).

I agree that there's an annoyance here where we can't set this to be true for specific widgets. I'm not sure what we could do about that.

In any case: my preference for false would probably be that it is least surprising. I won't die on this hill, but my gut says false is the right default. (As recognized by appkit, as well)

[xStrom]

Okay, so there are two scenarios here that should be replicated to achieve a macOS feel.

1. When clicking a background window's button it should work. NSButton works like this, as do a plethora of macOS apps like the calculator.
2. When clicking a background window's edit field, the text selection should not change, although the edit field should probably get focus if I remember correctly.

Just having acceptsFirstMouse be true or false and nothing else won't achieve this goal.

We could however add a new field to MouseEvent like focused. This would be false almost always, but it will be true at minimum on macOS when it's the click that goes through acceptsFirstMouse.

This approach will allow us to modify widgets like TextBox to not change the selection with the focusing click, and this same opportunity would be there for custom widgets like a painting canvas.

[ratmice]

Not sure if other platforms besides macOS need to be taken into account here, but in X11
the first mouse event when clicking on a window is dependent upon whether the window manager forwards that first event to the window or focuses the window while suppressing the event,

at least this is the case when using window manager reparented windows/decorations.
that said I don't see how any problems could arise by platforms not being able to implement the hint and therefore not forwarding first mouse events when they would be allowed.

[xStrom]

I tested Ubuntu 19.04 with the bundled calculator and text editor. It seems to behave exactly like Windows. Which is to say the first focusing mouse click goes to the app and works both as a button press and also changes text selection.

@ratmice are you seeing different behavior? What distro/WM?

[ratmice]

@xStrom Most of this I just know from having written a window manager before, by default my window manager seems to send the event by default.

I know that the windowmaker has settings for this, and tested with that with both settings.
Window focus preferences The "Do not let applications receive the click used to focus windows." near the bottom right,

With that enabled we see the weird behavior that when non-focused we still highlight buttons on MouseMove but the click used to focus doesn't register the button press.

With it disabled we get the highlight on MouseMove and the button press like expected.

Anyhow I just wanted to note that X11 is very hard to pin down any sort of feel in this regard.

[xStrom]

Yeah I think this isn't going to be a problem if the user expects this kind of behavior. Druid matching the X11 feel will depend on what that configuration setting is for them. If the click gets sent, druid handles it and everything works. If the click doesn't get sent due to that X11 setting then that's fine too, because the user doesn't expect it to work, because it doesn't work that way with any other app on their desktop. It's simple because it's a simple boolean setting.

Windows is also simple, because it's a simple boolean that's always true.

However with macOS it's trickier because it's context/widget dependant. Thus I think the solution here is to allow druid apps to also handle the focusing click differently, however each widget wants.

[cmyr]

We could however add a new field to MouseEvent like focused. This would be false almost always, but it will be true at minimum on macOS when it's the click that goes through acceptsFirstMouse.

This approach will allow us to modify widgets like TextBox to not change the selection with the focusing click, and this same opportunity would be there for custom widgets like a painting canvas.

This sounds like an elegant solution to me.

[xStrom]

I pushed a new iteration of this. The information about the click being the focusing one is now made available to users. I also updated the TextBox widget to not change the selection with the focusing click.

[cmyr]

hmm, slightly confused here; with both master and this patch, if I run the calculator and have it not be focused, a click gives it focus but is not handled.

[xStrom]

That's interesting. I just re-tested and the calculator works fine, it registers the click and a new number appears on the calc display.

I'm running macOS Catalina 10.15.4.

Maybe double check that the code you have checked out matches the latest tip here and perhaps also try cargo clean.

[cmyr]

Okay, this is working for me; not sure what was going on.

My gut feeling is that this behaviour should be opt-in, not opt-out, but I'm happy enough to get this in and then see how it feels.