Window Button Styles #6675

TheColorRed · 2024-10-28T15:21:56Z

Adds three types of window button styles naming was taken from here.

There are a few winit restrictions.

Wayland / X11 / Orbital: Not implemented.
Web / iOS / Android: Unsupported.

Usage

let app = AppWindow::new()?;
app.window().set_window_button_style(slint::WindowButtonStyle::All); // Default
app.window().set_window_button_style(slint::WindowButtonStyle::None);
app.window().set_window_button_style(slint::WindowButtonStyle::Close);
app.window().set_window_button_style(slint::WindowButtonStyle::Minimize);
app.window().set_window_button_style(slint::WindowButtonStyle::Maximize);
app.window().set_window_button_style(slint::WindowButtonStyle::MinimizeClose);
app.window().set_window_button_style(slint::WindowButtonStyle::MaximizeClose);
app.window().set_window_button_style(slint::WindowButtonStyle::MinimizeMaximize);

Output

Full

Close

None

Note: On windows the x is still there just not clickable (not sure about on a different OS)

MinimizeMaximize

ogoffart · 2024-10-29T23:05:28Z

Thanks for the PR.

I'm just wondering if an enum is really appropriate vs 3 boolean to hide specific buttons. Would it not be simpler?

TheColorRed · 2024-10-29T23:15:44Z

@ogoffart You mean something like this? I didn't think of booleans, I think this look better than my implementation.

let min = false;
let max = false;
let close = true;
app.window().set_window_buttons(min, max, close);

ogoffart · 2024-10-30T07:03:58Z

No, I meant something like
app.window().set_button_maximize_visible(true); and so on.
But that's not really great.

A function with 3 boolean is quite confusing because people will write set_window_buttons(true, false, true); and that's unreadable and also easy to mix arguments.(boolean trap)

Another possibility:
app.window().set_button_visible(WindowButton::Maximize, true)
I think I like that.

There is also the choice to take she same API as winit with Flags.

I think your choice with an enum with 8 state is not that bad if there is only 3 buttons, but we have to think about extensibility. What if we want to add another button in the future without breaking the API? There is some WM with extra button. (Help, Menu, ...)

So I don't know exactly which API is the best that combine simplicity and extensibility. Perhaps the winit API with flags is the nicest. But flags in rust are a bit awkward to do.

Enyium · 2024-10-30T08:51:09Z

Shouldn't these be component properties?

export component AppWindow inherits Window {
    has-minimize-button: false;
    has-maximize-button: false;
    has-close-button: false;
}

Dialog should also make them available, but use different defaults (only close-button).

Why should you have to do this in the backend language?

TheColorRed · 2024-10-30T14:10:13Z

@ogoffart I have updated the implementation:

app.window().set_window_button_enabled(WindowButton::Minimize, true);
app.window().set_window_button_enabled(WindowButton::Maximize, true);
app.window().set_window_button_enabled(WindowButton::Close, true);

@Enyium

I am not sure that would fall in line with the current structure of the library, as you cannot make the window maximized from slint either, so this follows the current implementation of how setting a window to maximized works:

app.window().set_maximized(true);

Enyium · 2024-10-30T22:15:33Z

I am not sure that would fall in line with the current structure of the library, as you cannot make the window maximized from slint either

It's about what the user should be allowed to do! This is similar to the initial-size and resizing topic: You use Slint properties to define whether the user should be allowed to resize the window. (Docs: "Setting the width will result in a fixed width... The initial width can be controlled with the preferred-width property.")

You can't compare something like Window::set_window_button_enabled(WindowButton::Maximize, ...) to Window::set_size() and Window::set_maximize()! The latter are for immediate acions, not to manifest a framework of allowed user actions.

Do you want to disable the minimize- and maximize-button for the Window of every new Dialog component instance? It belongs to the design. It shares in defining the kind of dialog presented, and is unlikely to change during the lifetime of a window.

ogoffart · 2024-10-31T15:22:36Z

It is not always easy to figure out if this should be part of the native API vs. what should be part of the slint code API.
The rule of thumbs is that if it is part of the design, then it should be in .slint, but if it is part of the logic, then it should be in the native code.
Maximizing or Minimizing a window, when not done by the user is done by the programmer as a result of something.
But maybe the appearance of the title bar is indeed something that should be described in the .slint file, it seems.
So i tend to agree with @Enyium

TheColorRed · 2024-10-31T17:05:09Z

@ogoffart, @Enyium I have moved the code out of the API and into .slint. I wasn't sure on the name, so I went no-**-button as the default of a property seems to be false which when the value isn't set in the .slint, it automatically turns the button off which is why I didn't go with has-**-button .

Enyium · 2024-11-01T02:32:55Z

no-**-button

Please "Avoid Negative...Names". I also recommended this regarding the existing no-frame in #5882 - although built-in has-... properties always seem to be out-properties. Perhaps this would be a good time to think of whether has-... should also be used for properties that aren't exclusively out-properties, or whether Slint could use another positive phrasing for properties that are at least partly in-properties.

the default of a property seems to be false which when the value isn't set in the .slint, it automatically turns the button off

I don't think there's a problem defining true as the default. If it's not overwritten and not part of a two-way binding, the default of true should be kept.

According to GPT-4o, dialogs with hidden minimize- and maximize-button are more common and Dialog should hide them by default.

ogoffart

Sorry to take so long to react to your PR.
It may seem picky, but we really should try hard to get the right API and naming, and this is something that can take several iteration.
Thank you so much for contributing. I think the feature is valuable. And the implementation looks good.

I've added some comments especially regarding naming.
We should use consistently either something like "visible" or "enabled" for these buttons. Winit uses "enabled", but I wonder if these shouldn't be "visible" instead. I'm a bit unsure about that.

(Also, the implementation in the Qt backend is missing. That can be done with QWidget::setWindowFlags. But this can be done in a followup)

ogoffart · 2024-11-07T08:53:41Z

internal/core/window.rs

@@ -407,6 +413,17 @@ struct WindowPinnedFields {
    text_input_focused: Property<bool>,
 }

+#[derive(Debug, Copy, Clone, PartialEq)]
+/// The state of each window button
+pub struct WindowButtonState {


should we consider marking this struct as #[non_exhaustive]?

Naming-wise, i believe the struct should probably be called WindowButtonVisibility as it is about the visibility of these buttons rather than their state. Or the value should say minimize_button_visible or has_minimize_button

ogoffart · 2024-11-07T08:57:51Z

internal/backends/winit/winitwindowadapter.rs

+                window.set_enabled_buttons(enabled_buttons);
+            }
+            Self::None(attributes) => {
+                attributes.borrow_mut().enabled_buttons = WindowButtons::all()


Why set all buttons here?

ogoffart · 2024-11-07T09:09:00Z

internal/core/window.rs

+
+    /// The widow style
+    /// Returns a tuple of three booleans: (minimize, maximize, close)
+    pub fn window_buttons_enabled(&self) -> WindowButtonState {


Is it maybe visibility rather than enabled

ogoffart · 2024-11-07T09:10:41Z

docs/reference/src/language/builtins/elements.md

+-   **`no-minimize-button`** (_in_ _bool_): Whether the window should have a minimize button in the title bar. Default is `false` to show the minimize button.
+-   **`no-maximize-button`** (_in_ _bool_): Whether the window should have a maximize button in the title bar. Default is `false` to show the maximize button.
+-   **`no-close-button`** (_in_ _bool_): Whether the window should have a close button in the title bar. Default is `false` to show the close button.


I think Enyium has a point. It probably should be has-maximize-button or maximize-button-visible or maximize-button-enabled (and default to true which can be done in the builtins.slint)

Enyium · 2024-11-07T12:43:25Z

We should use consistently either something like "visible" or "enabled" for these buttons. Winit uses "enabled", but I wonder if these shouldn't be "visible" instead. I'm a bit unsure about that. [@ogoffart]

Note that this is already inconsistent under Windows. StackOverflow:

CS_NOCLOSE disables the close button (and [system] menu entry), but it will not remove it.

...

The only way to remove the button is to give up on the system menu completely. You have to omit the WS_SYSMENU style flag in your CreateWindowEx() call.

In contrast, other styles like WS_MAXIMIZEBOX and WS_MINIMIZEBOX can really set the button visibility. But this is also dependent on the configuration: The minimize- or the maximize-button may also be just disabled.

But I don't know whether winit even uses a window class per window at all, or reuses OS-level window classes. (CS_NOCLOSE is a class style, not a window style.)

TheColorRed added 5 commits October 27, 2024 12:02

Allow for percent in ternary

d2e4f06

Added window button styles

7b9b57b

removed some changes

99d8cda

Merge branch 'master' of github.com:slint-ui/slint into window-buttons

a45ad8e

renamed functions

6467fb3

TheColorRed marked this pull request as ready for review October 28, 2024 16:34

TheColorRed added 4 commits October 28, 2024 11:38

orginization

6909d43

modified how it works

609bae2

modified how it works

6525654

modified how it works

65cbdbc

TheColorRed added 2 commits October 30, 2024 09:05

Updated the windows buttons implementation

feac7dc

Merge branch 'master' of github.com:slint-ui/slint into window-buttons

0bca313

TheColorRed added 3 commits October 31, 2024 11:05

Merge branch 'master' of github.com:slint-ui/slint into window-buttons

02f2943

Removed from api and placed in .slint

4286819

Removed from api and placed in .slint

9710748

TheColorRed mentioned this pull request Oct 31, 2024

Adds the ability to disable/enable window interactions #6694

Open

TheColorRed added 2 commits October 31, 2024 17:58

fixed conflicts

67cc10d

fixed conflicts

9a818a7

ogoffart reviewed Nov 7, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Window Button Styles #6675

Window Button Styles #6675

TheColorRed commented Oct 28, 2024 •

edited

Loading

ogoffart commented Oct 29, 2024

TheColorRed commented Oct 29, 2024 •

edited

Loading

ogoffart commented Oct 30, 2024

Enyium commented Oct 30, 2024

TheColorRed commented Oct 30, 2024 •

edited

Loading

Enyium commented Oct 30, 2024

ogoffart commented Oct 31, 2024

TheColorRed commented Oct 31, 2024

Enyium commented Nov 1, 2024

ogoffart left a comment •

edited

Loading

ogoffart Nov 7, 2024

ogoffart Nov 7, 2024

ogoffart Nov 7, 2024

ogoffart Nov 7, 2024

Enyium commented Nov 7, 2024 •

edited

Loading

Window Button Styles #6675

Are you sure you want to change the base?

Window Button Styles #6675

Conversation

TheColorRed commented Oct 28, 2024 • edited Loading

Usage

Output

Full

Close

None

MinimizeMaximize

ogoffart commented Oct 29, 2024

TheColorRed commented Oct 29, 2024 • edited Loading

ogoffart commented Oct 30, 2024

Enyium commented Oct 30, 2024

TheColorRed commented Oct 30, 2024 • edited Loading

Enyium commented Oct 30, 2024

ogoffart commented Oct 31, 2024

TheColorRed commented Oct 31, 2024

Enyium commented Nov 1, 2024

ogoffart left a comment • edited Loading

Choose a reason for hiding this comment

ogoffart Nov 7, 2024

Choose a reason for hiding this comment

ogoffart Nov 7, 2024

Choose a reason for hiding this comment

ogoffart Nov 7, 2024

Choose a reason for hiding this comment

ogoffart Nov 7, 2024

Choose a reason for hiding this comment

Enyium commented Nov 7, 2024 • edited Loading

TheColorRed commented Oct 28, 2024 •

edited

Loading

TheColorRed commented Oct 29, 2024 •

edited

Loading

TheColorRed commented Oct 30, 2024 •

edited

Loading

ogoffart left a comment •

edited

Loading

Enyium commented Nov 7, 2024 •

edited

Loading