Add default flag toButton

[FloVanGH]

No description provided.

[tronical]

This says it displays it in a highlighted color and that it defines the button as a "default" button. The documentation here needs to say what that means.

IMO such a default attribute should not only configure the visual appearance but also the semantics: If I choose default: true; I want it so that when the user presses "Enter" in a dialog, this button gets activated.

So either the property here configures only the visuals - and then the docs should say just that - or the docs should explain what "default" means and this PR should implement it.

[FloVanGH]

Ok, then maybe it would make more sense to rename the property as primary, to define it as visual setting.

[ogoffart]

There is what the Qt docs say: https://doc.qt.io/qt-6/qpushbutton.html#default-prop

[FloVanGH]

There is what the Qt docs say: https://doc.qt.io/qt-6/qpushbutton.html#default-prop

I'm not sure about that behavior. If we have only the default property and its enable automatically the default` behavior and you cannot use the button in the highlight/default look and feel without that behavior. Therefore e.g. in my former WPF projects, there was mostly a primary style for buttons and the behavior was defined for the specific context e.g. for dialogs, without to integrate it with the button. @tronical @ogoffart, what do you think. Integrate the default behavior or only integrate a flag to show a button as highlighted in the accent color?

[tronical]

you cannot use the button in the highlight/default look and feel without that behavior.

Do you know of an example where you want assign a button to have the primary role but not respond to the return key?

Apple is suggesting the same behavior for primary buttons, btw: https://developer.apple.com/design/human-interface-guidelines/buttons#Role

IMO the best API is a boolean primary property that

1. Helps the style to give the button the appearance that will guide the user to choosing this with highest probability.
2. Helps the compiler / run-time library to connect this to a key fallback handler in our Dialog perhaps to achieve the correct behavior.
3. Makes the developer/designer (reader of the .slint file) that this is a primary button.

We could go for two different properties, one just for the visual appearance and one to additionally enable return-key behavior, but I'd like to understand what the use-case would be for such a styled button that should look like a primary button but not behave like one.

[tronical]

FWIW, we could also have a boolean primary property now that just covers the visual bit and we implement support for central Return handling later. That's kind of what your patch does. What do you think?

I'd be okay with that, as long as the documentation is clear and we track the missing "Return" handling in an issue - so that our conclusion and decision is on record ;)

[FloVanGH]

Yes I know about that it is a recommended use case for default/primary button.

I have no other specific use case in mind. I was only thinking because we support multiple design systems and maybe there could be a use case for a specific design system in the future. But maybe this thought is too theoretically and if there will be such a use case we will find an other way to handle it.

[FloVanGH]

If we implement that feature. Would it make sense to integrate the default/primary property also for TouchArea, then a developer/ designer can also make use of it for the creation of a custom button in Slint.

[tronical]

I'm not sure about TouchArea (that seems unrelated to keyboard handling to me), but you're right: We almost have this with the dialog-button-role, except that it's only for dialogs and only affects the layout.

Okay, I'm getting convinced that we should go with primary as visual-only property for now :)

[FloVanGH]

Okay. I have updated the property name to primary and also adjusted the documentation.

[tronical]

LGTM. Let's see what Olivier says :)