Interfaces for style

[ogoffart]

Currently, the style must re-implement a lot of components, but there is nothing that checks that these component have the same interface/properties.

The idea would be to build interfaces like so:
(based on the current interface of Button https://docs.rs/slint/latest/slint/docs/widgets/index.html#button)

interface Button {
   in property <string> text;
   in property <bool> checkable;
   in-out property <string> checked;
   out property <bool> pressed;
   in property <image> icon;
   callback clicked();
}

Then, the style would have to implement this interface:

// FIXME should we import that? from where, should it be bluit-in
import { Button } from "std.slint"; 

component MyStyleButton implements Button {
   pressed: ta.pressed; // can set output properties
   Text { text: root.text } // can access property
   ta := TouchArea { clicked => { root.clicked() } } // call callbacks
   
   in property <int> extra_prop; // ERROR!  not allowed to add public properties
}

// re-export the MyStyleButton as the Button of our style
export MyStyleButton as Button;

It is a bit akward to have to go through MyStyleButton as a separate name, maybe we could allow component Button implements Button {...} and have different namespace for components and for interface.

Unresolved question:

• How do we make sure that the style implements all the widgets?
• How do we make sure that a style don't export more than the required widget?
• Is it a breaking change, in Slint, to add more widgets? Should we add some sort of versioning?
• Should the interface allow to also have some logic in them?
• What about widgets like TabWidget or ListView that needs compiler support?
• Should we even allow users to declare new interface, or are these just be builtin?

[tronical]

// FIXME should we import that? from where, should it be bluit-in
import { Button } from "std.slint";

Perhaps a dedicated file makes sense. For example std-widget-interfaces.slint

Regarding the names, we could also do something like this:

import * as Interfaces from "std-widget-interfaces.slint";

component Button implements Interfaces.Button {
}

[tronical]

How do we make sure that a style don't export more than the required widget?

We could say that once a component implements an interface, only that interface is visible. Only components that don't implement an interface implicitly define an interface (with the same name).

[Enyium]

interface reminds me of Java's interfaces and Rust's traits, where you can implement multiple for a given blueprint (class/struct), and where you need to redundantly repeat the interface content again to make it concrete. I'm not so sure this would be fitting. Alternative terms: connector, bond.

I think what you currectly call interface would be included in the public API of the component, right? Then, even if you wanted to implement a widget in multiple subparts and then present it as a whole, it would make sense to only allow one interface. But to accommodate this kind of region-wise internal implementation, it could be useful, if there was something like the possibility to spread out (or flatten) an interface in another interface:

export interface WidgetInterface {
    spread interface <AInterface> a-interface;
    spread interface <BInterface> b-interface;
}

interface AInterface {
    in-out property <int> foo;
}

interface BInterface {
    in-out property <string> bar;
}

export component Widget implements WidgetInterface {
    a-interface <=> a.interface;
    b-interface <=> b.interface;

    a := A {}
    b := B {}
}

component A implements AInterface {
    foo: 123;
}

component B implements BInterface {
    bar: "abc";
}

[jwtocadero]

@tronical I think that not allowing extra public properties is a mistake. Sometimes we don't want to add just style, but also behavior. Like an on off button which has a cancelling state. this state might be set from the outside world. I think interfaces should be implemented like Go does it. You define a set of callbacks, properties etc and whatever object has them does is qualified as implementation of the interface. No need to limit the implementation to do more in a context which is aware of the actual type and not just the interface.

[0x6e]

How do we make sure that a style don't export more than the required widget?

We could say that once a component implements an interface, only that interface is visible. Only components that don't implement an interface implicitly define an interface (with the same name).

I don't think it is useful to enforce that only the interface API is exposed. I can see why it might be desirable from a std-widgets point of view: we don't want someone implementing a std-widgets style to add extra API that isn't compatible with other existing styles.

On the other hand I might want to use e.g. the LineEdit interface to produce my own SearchLineEdit. This wouldn't be part of a std-widgets style, but I want to re-use the line edit interface and then maybe also add my own additional API.

Perhaps for the std-widgets use case what we actually need is to enforce/warn about additional API at the compiler/internal library level.

In the case where I might be able to use the interface as a property type I wouldn't expect to be able to access the non-interface API anyway:

component Foo {
    in property<MyInterface> my-interface;
}

[tronical]

Further discussion between @ogoffart, me, and @0x6e brought up the following idea to permit composition for sharing functionality, but re-use the interface concept to conveniently define the API:

interface LineEditInterface {
    in-out property <string> text;
    ...
}

component LineEditBase implements LineEditInterface {
    // business logic here
}

// The final widget

export component LineEdit
    uses { LineEditInterface from base }
    inherits Something // optional
{
    base := LineEditBase { ... }

    accessibility-delegate: base;
    forward-focus: base;
}

[0x6e]

I assume that we also want to be able to do:

component LineEditBase
    implements LineEditInterface
    inherits Something // optional
{
    // business logic here
}