Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for teleportation of elements #6730

Open
Enyium opened this issue Nov 6, 2024 · 0 comments
Open

Support for teleportation of elements #6730

Enyium opened this issue Nov 6, 2024 · 0 comments
Labels
a:language-slint Compiler for the .slint language (mO,bF) enhancement New feature or request need triaging Issue that the owner of the area still need to triage

Comments

@Enyium
Copy link
Contributor

Enyium commented Nov 6, 2024

Vue.js has <Teleport>:

<Teleport> is a built-in component that allows us to "teleport" a part of a component's template into a DOM node that exists outside the DOM hierarchy of that component.

...

Sometimes we may run into the following scenario: a part of a component's template belongs to it logically, but from a visual standpoint, it should be displayed somewhere else in the DOM

The following SlintPad example demonstrates how such functionality would be useful to prevent undesired overlaps of spacial component extensions (sometimes also seen in the form of a glow effect to indicate focus):

component HoverHighlightText {
    in property <string> text;
    //in property <component-ref> teleport-highlight-to: parent;

    Rectangle {
        // Every element gets this new property, which only
        // affects the z-order and possible clipping.
        // Teleported elements should probably be placed on top of
        // regular elements inside their container.
        // It could also be named `teleportation-target`, which
        // would be quite verbose, though.
        //teleport-to: root.teleport-highlight-to;

        property <length> extension: 6px;
        x: t.x - self.extension;
        y: t.y - self.extension;
        width: t.width + 2 * self.extension;
        height: t.height + 2 * self.extension;
        border-radius: self.extension / 1.6;

        background: ta.has-hover ? lightgray : transparent;
    }

    ta := TouchArea {
        t := Text {
            text: root.text;
        }
    }
}

export component Demo {
    width: 200px;
    height: 200px;

    VerticalLayout {
        alignment: start;

        HoverHighlightText {
            text: "Foo";
            //teleport-highlight-to: root;
        }

        HoverHighlightText {
            text: "Bar";
            //teleport-highlight-to: root;
        }

        HoverHighlightText {
            text: "Baz";
            //teleport-highlight-to: root;
        }

        HoverHighlightText {
            text: "Qux";
            //teleport-highlight-to: root;
        }
    }
}

This video demonstrates the problem. Pay attention to the highlight overlapping some text, although these highlights should always be in the background surface:

overlaps.mp4

Of course, you can flatten your component hierarchy to work around this. But good encapsulation and separation of concerns should be possible.


I had to use the non-existent type component-ref. Related issues regarding this: #5082, #2390.

@hunger hunger added enhancement New feature or request a:language-slint Compiler for the .slint language (mO,bF) need triaging Issue that the owner of the area still need to triage labels Nov 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a:language-slint Compiler for the .slint language (mO,bF) enhancement New feature or request need triaging Issue that the owner of the area still need to triage
Projects
None yet
Development

No branches or pull requests

2 participants