Term confusion (`Window` / `component` / `ComponentHandle` / `AppWindow` )

[Enyium]

(I'm using Rust.)

When teaching Slint, you call the exported component inheriting Window a ...Window:

• MainWindow: https://releases.slint.dev/1.7.2/docs/slint/src/quickstart/getting_started#id3
• AppWindow: https://github.com/slint-ui/slint-rust-template/blob/main/src/main.rs

Then, this ...Window is indirectly called a "component" by the name of your SampleComponent (which inherits Window in .slint code), implements ComponentHandle, and, through that, has itself a window() getter, which returns a Window (giving you code like app_window.window()).

Exporting components not inheriting Window to Rust isn't allowed:

warning: slint-test@0.1.0: Exported component 'AppWindow' doesn't inherit Window. This is deprecated

So, a ComponentHandle must always be a component narrowed down to a .slint Window.

The fact that a generated struct like AppWindow really only allows you to interact with the window's client area (disregarding the deeper window() -> Window), and "window" may not even be the most suitable term for the rendering surface of an Android app tops off the confusion.

Is the Window the window() getter returns even a real window on every platform?

Maybe, it would be justified to redefine and here and there switch or rename the terms for more clarity and presenting a more streamlined concept.

---

Possible improvement:

• WindowComponent instead of ComponentHandle, because it can only be one narrow kind of component.
• Establish a convention of never calling a component inheriting Window a ...Window. For single-window apps, the recommendation could be component Main inherits Window. In Rust, this could be let main_component, although = Main::new(); would be rather undesirable. Maybe component MainComponent inherits Window would be acceptable. Or AppComponent. But the user may want to use App as their own struct that holds all of their business data and window components.
  • When an app implements more than a single window, the developer would semantically distinguish them through their names. These names also shouldn't have a Window suffix. If it's a message box window, e.g., it could just be component MessageBox inherits Window.
• window() can be kept, because the struct providing the getter now is more recognizable as the property-based reactive client area of the window.
• Would you like to keep Window in .slint code? Even if this isn't necessarily always the most natural term for the app surface in an Android context, there can be movable windows on Android, like with Samsung DeX when connecting your monitor to your phone. An app on a regular phone could be seen as in a fullscreen window.

Other way:

• Keep using names like AppWindow, which would also be a WindowComponent (trait). This would be in harmony with these components presenting in dedicated associated windows.
• Find a different name for window() and its return type Window. But I don't know what that could be. (Perhaps something with "non-client"?)

[tronical]

(I'm using Rust.)

When teaching Slint, you call the exported component inheriting Window a ...Window:

• MainWindow: https://releases.slint.dev/1.7.2/docs/slint/src/quickstart/getting_started#id3
• AppWindow: https://github.com/slint-ui/slint-rust-template/blob/main/src/main.rs

Then, this ...Window is indirectly called a "component" by the name of your SampleComponent (which inherits Window in .slint code), implements ComponentHandle, and, through that, has itself a window() getter, which returns a Window (giving you code like app_window.window()).

Exporting components not inheriting Window to Rust isn't allowed:

warning: slint-test@0.1.0: Exported component 'AppWindow' doesn't inherit Window. This is deprecated

So, a ComponentHandle must always be a component narrowed down to a .slint Window.

That's correct, although the forced association with Window

The fact that a generated struct like AppWindow really only allows you to interact with the window's client area (disregarding the deeper window() -> Window), and "window" may not even be the most suitable term for the rendering surface of an Android app tops off the confusion.

Is the Window the window() getter returns even a real window on every platform?

Maybe, it would be justified to redefine and here and there switch or rename the terms for more clarity and presenting a more streamlined concept.

Possible improvement:

• WindowComponent instead of ComponentHandle, because it can only be one narrow kind of component.

That's a nice idea.

• Establish a convention of never calling a component inheriting Window a ...Window. For single-window apps, the recommendation could be component Main inherits Window. In Rust, this could be let main_component, although = Main::new(); would be rather undesirable. Maybe component MainComponent inherits Window would be acceptable. Or AppComponent. But the user may want to use App as their own struct that holds all of their business data and window components.

I'm unsure about this one. component is the term that in say C++, Java, or JavaScript would be called a class. So instances of this component wouldn't necessarily be called "foo_component" again.

I find Window still most appropriate for two reasons:

• Unlike "Component", "Window" makes it clearer that in the context of the surrounding Rust code (business logic), this variable here is about the user interface that in many cases ca be visually associated with a window.
• "Window" also makes it clearer that this is not where the business data will be stored. Although I admit that this is something we might end up changing in the future.

• When an app implements more than a single window, the developer would semantically distinguish them through their names. These names also shouldn't have a Window suffix. If it's a message box window, e.g., it could just be component MessageBox inherits Window.

I agree. If there are multiple windows involved, there is - towards the user - typically one "bigger" window, also known as the "main window". So MainWindow seems most appropriate IMO, but this is a term that we may want to use in the future as a type name for a window that is not just a surface with title bar, but also has a menu bar, tool bar, dock areas, and a status bar. So for me AppWindow is a reasonable compromise at this point.

• window() can be kept, because the struct providing the getter now is more recognizable as the property-based reactive client area of the window.
• Would you like to keep Window in .slint code? Even if this isn't necessarily always the most natural term for the app surface in an Android context, there can be movable windows on Android, like with Samsung DeX when connecting your monitor to your phone. An app on a regular phone could be seen as in a fullscreen window.

I'm also a bit torn on mobile, but on the other hand: On Android there's clearly a concept and type "Window", and on Apple it's the same: The UIWindow is the "backdrop for your app’s user interface and the object that dispatches events to your views". So Window seems still appropriate to me, and more concrete than "Surface" or "Backdrop" :)

Other way:

• Keep using names like AppWindow, which would also be a WindowComponent (trait). This would be in harmony with these components presenting in dedicated associated windows.

👍

[tronical]

I've removed the triaging label here and turned this into an rfc, as there's clearly a discussion with some degree of consensus before we can take action, but the case @Enyium presented is beautifully summarised and perfectly valid. I appreciated the time and thought that went into this :)

[Enyium]

Other way:

• Keep using names like AppWindow, which would also be a WindowComponent (trait). This would be in harmony with these components presenting in dedicated associated windows.

👍

But if you keep app_window.window() -> Window then, this part stays confusing with unclear differentiation. Some brainstormed terms: host()/host_window(), encompassing_window(), enclosing_window(), outer_window(), presenter()/presenting_window()/presenter_window(), master()/master_window(), base()/base_window(), possessing_window().

It's like with window_handle():

    let window = app_window.window();
    let handle = window.window_handle().window_handle()?.as_raw();

This hierarchy would ideally be flattened.

[tronical]

Oh that’s a very good point… Hmm.