Do these numbers align with anything? Then a comment pointing at where else we use them would be good.

Or maybe use multiples of long/short duration? Or makes no sense?

Same question about the other site in the code.

Is this still the best we can do? The FV code uses some old QQC1 private APIs to get scrollbar width. I thought in QQC2 we have proper ways to do it by accessing the SB instance?

When I wrote my launch feedback port I had some trouble with sizing in kcmshell5. The window came up too small to fit the FormLayout, but the scrollbar was also assuming a content size far larger than the FormLayout - I had to make the window pretty big for the vertical scrollbar to disappear. So it was broken in two ways.

How does this compare? I noticed the hard-coded values here instead of really working with the content.

Same wonderings @ sizing.

ah, no there isn't anywhere anything configured for duration for tooltips. in upstream qqc2 is also one second hardcoded

qqc2 scrollview is almost api-less but maybe i can access somehow the scrollbar with an attached property now that i think about, i'll give a try

this one is a big scrollview of thumbnails and nothing else...
at most i guess we could make it that we want it big as 3x3 cells or something like that but the contents don't really have an implicit size per se

for this i think we could try to get an implicit size of the layout inside the main scrollview, but then limiting it to some hardcoded value anyways.
for instance if started with kcmshell i think it's better if it puts a scrollbar in it rather than making a very narrow and tall window that takes all the vertical space

GridView {

view.model: foo
view.Delegate: Delegate {...}

}

yeah, it does that..
it keeps the qquickwidget small enough so the qwidget scrollbar won't be there.
which isn't optimal, but i think the scrolling should be handed by the qml part.

but i think the scrolling should be handed by the qml part.

Why?

3 reasons:

1. because the long term goal is to get rid of the qwidget version, so even if it's long down the road things should be designed according to that from now.

the design for a pure qml version would be kcms to be kirigami Pages, which get directly inserted in a kirigami PageRow, so they manage their own scrolling

2. also makes it easier for more complicated designs where is not the whole ui scrolling but there is a scrollview and a form layout in the same module, as some mockups have.

3. if we relied on the scrolling by the kcmshell scrollarea, the QQuickWidget height should resize itself based on the contents size, but the contents width should depend from the qquickwidget width, making it a weird hybrid between the two ResizeMode, which from Plasma::Dialog know how much complicated and painful it becomes