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

Don't instanciate ListView items that are just above the viewport when scrolling down #7424

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

DataTriny
Copy link
Contributor

Fixes #7381

If an item can just fit above the viewport while scrolling, it is now not instanciated anymore as it is fully hidden. The issue occurs frequently when using the arrow keys to jump through the items, since the scroll delta will usually be the height of exactly one item. This previously meant that an extra node would be added at the start of ListViews accessibility tree.

@tronical tronical requested a review from ogoffart January 21, 2025 22:12
@ogoffart
Copy link
Member

ogoffart commented Jan 22, 2025

Thanks for the patch.
This might workaround the issue #7381 for the case of ListView, so i'm going to include it.
But I think this won't work for the general case with the Flickable.

For example, consider this:

import { AboutSlint, Button, VerticalBox } from "std-widgets.slint";

export component Demo {
    height: 300px;
    width: 300px;
    Flickable {
        VerticalBox {
            AboutSlint { }
            for i in 50 : Text {
                text: "Hello " + i;
            }
        }
    }
}

Then all the Text are going to be instantiated regardless if they are visible or not.
I believe the right fix would be somehow to exclude the clipped item from the accessible tree when we visit the tree. @tronical: opinions?

I think it might make sense to not generate the item if it is out even if it is by one pixel.
Although it might have implication for the computation of the average height of items if item have different height, and the more item we have the better. But we can still merge this patch.

@tronical
Copy link
Member

Thanks for the patch. This might workaround the issue #7381 for the case of ListView, so i'm going to include it. But I think this won't work for the general case with the Flickable.

For example, consider this:

import { AboutSlint, Button, VerticalBox } from "std-widgets.slint";

export component Demo {
    height: 300px;
    width: 300px;
    Flickable {
        VerticalBox {
            AboutSlint { }
            for i in 50 : Text {
                text: "Hello " + i;
            }
        }
    }
}

Then all the Text are going to be instantiated regardless if they are visible or not. I believe the right fix would be somehow to exclude the clipped item from the accessible tree when we visit the tree. @tronical: opinions?

I agree, I think we need to perform a visibility check. We do this for the testing backend as well, perhaps accessible_descendants() needs to be changed and perform a visibility check like here ?

@DataTriny
Copy link
Contributor Author

My initial change was indeed very specific. I've implemented a general fix but we're now back to the point where listviews are excluded from the focus chain, even if no scrolling is performed. My understanding is that it is due to this hack used throughout the codebase:

FocusScope {
    x: 0;
    width: 0;  // Do not react on clicks
}

Shouldn't there be another property on FocusScope to ignore mouse clicks?

@DataTriny DataTriny force-pushed the fix-listview-item-scrolling branch from d024198 to 829ea6f Compare January 22, 2025 20:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Children of Flickable widgets are included in the accessibility tree when they shouldn't
3 participants