Scroll bar transitions trigger when minimizing/restoring the application window.

[Greatness7]

Scroll bars that are using the :checked state to control animations seem to be triggering when the window is minimized/restored.

Here's a short video showing the problem:

2023-07-14_22-23-23.mp4

And the code used:

use vizia::prelude::*;

const STYLE: &str = r#"
    scrollview {
        background-color: black;
    }

    label {
        color: white;
    }

    scrollbar {
        background-color: red;
    }

    scrollbar .thumb {
        background-color: blue;
    }

    scrollview scrollbar {
        opacity: 0.0;
        transition: opacity 20ms;
    }

    scrollview:checked scrollbar {
        opacity: 1.0;
        transition: opacity 20ms;
    }
"#;

fn main() {
    Application::new(|cx| {
        cx.add_stylesheet(STYLE).unwrap();
        ScrollView::new(cx, 0.0, 0.0, true, true, |cx| {
            for i in 0..10 {
                Label::new(cx, &format!("Label {i}"));
            }
        });
    })
    .inner_size((400, 400))
    .ignore_default_theme()
    .run();
}

[geom3trik]

I've discovered the reason this happens (I think) but not yet come up with a solution. Writing the reason here so I don't forget:

When the tabview is created and undergoes layout for the first time its size and the content size are computed and then the GeoChanged event is called. This then emits events to update the ScrollData, but the scroll data doesn't get updated till the next frame. When the scroll data does get updated it causes the checked modifier binding to recompute and add the checked state if the scrollbar needs to be shown. So for one frame you get the scrollbar showing when it shouldn't.

Note that since this issue was made, 70d9f23 reverses the initial state so that the scrollbar is not visible for the first frame. But this just reverses the problem for when the scrollbar should be visible from the start.

The solution to this problem is not obvious at the moment. Ideally the data needs to be updated with the sizes, and the binding recomputed, all before the drawing phase of the first frame after scrollview creation. However, because currently events are the only way to update data, and events happen before bindings and layout, the data can't be updated until the next frame. Even if we somehow update the data directly after layout the binding system has already run and if we update the checked state manually (without a binding), any layout dependent styling on the scrollbars (like transitioning their width when they should be visible) can't happen until the next frame because layout has already run.

I'll keep thinking about this.

[Greatness7]

When the tabview is created (...)

For the record, this happens with any kind of (scroll?) view. (There is no TabView in the example code.)

[geom3trik]

When the tabview is created (...)

For the record, this happens with any kind of (scroll?) view. (There is no TabView in the example code.)

Ah I mistyped, I meant scrollview.