search

slint-ui / slint

Slint is a declarative GUI toolkit to build native user interfaces for Rust, C++, or JavaScript apps.
https://slint.dev
Other
17.05k stars 572 forks source link

Provide information on close button placement #6310

Open Enyium opened 4 days ago

Enyium commented 4 days ago

On Windows and Linux, buttons like the close button are on the top right of windows; on macOS, they're on the top left. When implementing modal overlays like on websites (with dimmed background etc.), the close button should be on the same side as in the non-client area of the window. To be able to imitate this, Slint should provide the information what side applies.

ogoffart commented 4 days ago

Indeed, we should have this information somehow to make custom title bar Related https://github.com/slint-ui/slint/issues/2521

Also related is that we had the need for other platform specific info. Eg this code to check whether control maps to ctrl or command: https://github.com/slint-ui/slint/blob/32dd94973235ab4dcfb44ee1f4309f180a0d4ca9/tools/lsp/preview/ui.rs#L85-L93

I think we need to make platform available to Slint in a builtin way. And then maybe some such metadata like placement of the close button or name of the ctrl key.

tronical commented 4 days ago

Maybe we can have two enums?

enum OperatingSystem {
    Unknown,
    None,
    Linux,
    Windows,
    MacOS,
    Redox,
    /// more 
}

enum WindowingSystem {
    None, // linuxkms, mcu
    Unknown, // not mapped yet, like HarmonyOS
    Windows,
    MacOS,
    Wayland,
    X11,
    /// I guess not, since that's being phased out: Orbital
}

and then perhaps exposed as Slint.operating-system and Slint.windowing-system.

The windowing system should be supplied by the backend IMO (function in trait that defaults to None).

ogoffart commented 4 days ago

@tronical I mostly agree. Not sure if it makes sense to have a difference between Unkown and None. (I'd call it "Other") For all the Unix that are neither Linux nor MacOS, we could have a "Unix" variant (or "OtherUnix"?) (or do we need a "Linux") I guess Wasm goes in WindowingSystem enum and we would try to get the OperatingSystem from the browser user agent?

Not sure about Slint. prefix. We currently don't have that. We have top level function such as debug() and animation-frame() An alternative would be to have a global namespace Platform and functions such as

Since several of them can be true at the same time (eg, wasm on a browser running on mac)

tronical commented 3 days ago

@tronical I mostly agree. Not sure if it makes sense to have a difference between Unkown and None. (I'd call it "Other") For all the Unix that are neither Linux nor MacOS, we could have a "Unix" variant (or "OtherUnix"?) (or do we need a "Linux")

I'd think that Onknown is one we don't know yet, while None is bare-metal (no_std/freestanding).

I guess Wasm goes in WindowingSystem enum and we would try to get the OperatingSystem from the browser user agent?

Good point, yes. I guess then it's also not WASM but HTMLCanvas.

Not sure about Slint. prefix. We currently don't have that. We have top level function such as debug() and animation-frame() An alternative would be to have a global namespace Platform and functions such as

  • Platform.is-wasm()
  • Platform.is-wayland()
  • Platform.is-x11()
  • Platform.is-macOS()
  • Platform.is-windows()
  • Platform.is-unix() // does that include mac, android?
  • Platform.is-linux() // does that include android?
  • Platform.is-android()

Since several of them can be true at the same time (eg, wasm on a browser running on mac)

Good point, maybe that's cleaner.

One thing I think we should start doing is to not pollute the global namespace anymore but place Platform into an import, i.e. import { Platform } from "@slint/platform"; or so.

Enyium commented 3 days ago

(BTW, since standards are set: I'd plead to establish proper camel/Pascal/kebab casing instead of the JavaScript-style casings. So, not is-macOS()/HTMLCanvas, but is-mac-os()/is-macos()/HtmlCanvas. The JavaScript-style casings are inconsistent: If they had upheld their own casing standards, they would have defined it as XMLHTTPRequest, which is suboptimal (but it inconsistently became XMLHttpRequest). But even though they wanted to prevent lowercase letters in acronyms, when lowering the identifier, you get a lowercase acronym anyways: xmlHTTPRequest.)