Provide the ability to set a flag to enable the first click going to the application rather than just setting focus on MacOS

[tilladam]

Feature Description

On macOS, by default the first click on a window only sets the focus but does not pass the event through to Slint. This can be configured on the native NSView ("acceptsFirstMouse"), which would have to happen in winit. The suggestion is to introduce a flag that makes this configurable at the Slint level. API docs are here:

https://developer.apple.com/documentation/appkit/nsview/acceptsfirstmouse(for:)

Product Impact

I'm building a desktop application with a node editor and the first click is often on a node, so users expect the node to be selected.

[anlumo]

The OS-level API allows to decide this behavior per event, the question is whether Slint should have a static flag or expose this ability.

This is not applicable to other operating systems though, since they always respond on first mouse (to use Apple's nomenclature).

[anlumo]

I actually just realized that winit does implement that ability as a boolean flag: https://docs.rs/winit/0.30.12/x86_64-apple-darwin/winit/platform/macos/trait.WindowAttributesExtMacOS.html#tymethod.with_accepts_first_mouse

[tilladam]

Should we maybe just default to this on macos?

[anlumo]

I don't have my Mac with me, but can you try this solution?

use slint::winit_030::winit::platform::macos::WindowAttributesExtMacOS;

slint::slint! {
    export component HelloWorld inherits Window {
        Text {
            text: "hello world";
            color: green;
        }
    }
}

fn main() -> Result<(), Box<dyn std::error::Error>> {
    slint::BackendSelector::new()
        .backend_name("winit".into())
        .with_winit_window_attributes_hook(|attrs| attrs.with_accepts_first_mouse(true))
        .select()?;

    let app = HelloWorld::new()?;
    app.run()?;

    Ok(())
}

[tronical]

Should we maybe just default to this on macos?

I don't have a strong feeling here, but I'm curious: Which of the two behaviours is "native" for macOS applications?

[anlumo]

ChatGPT response, which sounds good to me:

When a view should accept first mouse

Accept first mouse when the click is low-risk and primarily about positioning / selection / focus, not “doing” something irreversible.

Typical good candidates:

1. Selection in a list/grid/canvas

   • Clicking a row in an outline/table to select it.
   • Clicking an item in a collection/grid to select it.
   • Clicking on a canvas to move the caret/selection, place an insertion point, select an object.

2. Scrolling / panning

   • Scroll views and content where the user expects the trackpad/mouse wheel to work immediately.
   • (This is especially important on macOS: people routinely scroll inactive windows.)

3. Focus that doesn’t commit

   • Clicking into a text view to set the insertion point (generally ok).
   • Clicking to give keyboard focus, show selection handles, etc.

A good mental model: “If the user mis-clicked while switching apps, would this cause damage?” If the answer is basically “no, it just changes selection/focus,” accept first mouse.

This is why standard “browsing” surfaces (tables, outlines, icon views, many document views) often accept first mouse: requiring a “wasted” activation click feels bad, and the consequences are minor.

When a view should NOT accept first mouse

Don’t accept first mouse when the click would trigger an immediate command or something the user might do accidentally while just trying to activate the app.

Common examples:

1. Buttons and button-like things

   • Toolbar buttons, in-content buttons, “Run”, “Send”, “Delete”, “Buy”, etc.
   • Toggle buttons / checkboxes / switches (state change is an action).

2. Destructive or expensive operations

   • Delete, move, format disk, start recording, launch external processes, submit forms, etc.

3. Controls that “commit” as you drag

   • Sliders/knobs that change system/app state continuously.
   • Anything where a stray click changes a value immediately.

The intention here is safety: on macOS, users often click a window only to bring it forward. If that click also “presses OK”, that’s a classic footgun.

[anlumo]

I just checked the winit source code, it's currently not possible to determine this flag based on the mouse click location with winit. However, this would be necessary to hit test into the slint view to determine whether the click is non-destructive.

So, this would need a winit PR to implement correctly first.