The same thing happens on Properties panel too when widgets for array selection for reader, for example, have too many rows.
To avoid showing these inner scrollbars we have added custom code allowing the table widget to grow to fit at least a certain number of rows before it opts to show scrollbars. Of course, we can make the widget grow indefinitely and avoid the scroll bar problem, but then panel can grow quite long and become very cumbersome.
How about at alternative approach:
the inner widgets, like these array or time widgets on the Information panel, will never show a scroll bar.
these widgets keep their height as compact as possible, however they can grow to fit a certain per defined set of rows automatically. This number of row to grow to fit should be specifiable in the settings. For users will tall monitors, one can easily set a higher value. For someone like me who has a fairly short monitor, I’d keep this low.
when the widget has more rows than the limit, instead of showing scrollbar, it adds “grow” button as the last row in the widget. The user can click this button to show all rows. When showing all rows in this mode, the last row gets converted to “shrink” button. The user can click that to shrink the widget back.
The grow state for a particular widget should get saved in settings too so the user doesn’t have to keep changing it. For example, I’d see myself always have the “Data Arrays” widget in the Information panel be fully expanded, but perhaps not the “Time” one.
Don’t think that solves the problem, though. Note, the Properties tab has other properties below the table widget. Now, if the table widget is really long – 1000s – which can happen, a dataset can have 1000s of blocks – then the panel will be incredibly long with user having to scroll a 1000 entries before even seeing what other properties are available.
Ok. So multiple tables is not the main problem but a tab control could still improve the situation.
If a widget has 1000s of entries and the “shrink” button goes to the bottom of the list, after pressing the “grow” button, won’t that require much scrolling to restore the original view size? Perhaps the shrink/grow button should stay at the top of the table widget.
I would have thought a tab control would be the ideal solution.
It is, as you said ideal. But it comes with some practical problems.
In ParaView with a default window arrangement, the properties panel takes up 20% of the application width. Within that 20%, if we place 3 or more horizontal tabs, it would be comfy on a widescreen. Whereas, for the unfortunate ones with a 1280x720 screen or a 14" 1920x1080 ultrabook (more common), it ends up looking crowded.
Considering that the properties panel is ubiquitously the most used in ParaView, taking up minimal width… IMO, it would be fair to limit horizontal expansion.
Isn’t that what scrolling tabs were designed to handle?
Fair enough, it’d be alright to show no more than two tabs given the width of the properties panel. The remaining may be shown after scrolling. With this design, users may have to click on the scroll button or scroll mouse on the tabs to see what properties are available.
Paired with a “grow/shrink” button, this design looks somewhat promising.