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.
If each nested grid were added to a separate tab then each widget could grow indefinitely without requiring the complication of growing/shrinking each region.
We have 4 table widgets to control the properties on this reader. If now each is a separate tab, I can’t imagine how convoluted it gets for the user to set up the properties on this reader.
Where there is a pre-determined number of table widgets I would have thought a tab control would be the ideal solution. I don’t see what the problem is here. Is it the need to click between tabs?
In my opinion the alternative should be a tree view with nested tables at the nodes.
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.
For table with thousands of rows, how about fix height + a button to expand the widget to a seperate window, just like Programmable Source:
In the panel
I +1 Utkarsh’s design so far, except for the grow/shrink placement. However I +100 the idea
imo we could have a 3-state button in the header and the footer, where the 3 states are :
fully collapsed : we only see the header with the label (for example Block Arrays <72 arrays>).
fixed size : last row is ... if not enough space
full fitted size
if full size < fixed size then we may want to make it a 2-state button, but I’m not sure if this is a good idea to dynamically change the behavior of a button …
