Its specially important in scenarios with lots of columns which most of them are not in viewable area.
Yes, as stated on the documentation,
By default the grid uses virtualisation; a technique whereby the grid
draws columns and rows as the user scrolls.
However, if you wish to disable column virtualization, you may choose to set the suppressColumnVirtualisation input property as true. You may refer to the column/row properties over here.
There may be 2 scenarios when you may wish to disable column virtualization.
1) Auto-sizing of all columns. This will ensure that all columns, and not just the columns which are rendered on the screen, will be resized.
2) Support for a11y. This is to prevent any potential issues for keyboard navigation and screen readers.
Related
I'm virtualizing a large Master-Detail AG-Grid for performance. A rowBuffer can be set at the master and detail level. Through experimentation I know these settings can cause my grid to lock up completely or to work. I cannot find any documentation on how they work.
Documentation says:
By default the grid will render 10 rows before the first visible row
and 10 rows after the last visible row, thus 20 additional rows get
rendered. This is to act as a buffer as on some slower machines and
browsers, a blank space can be seen as the user scrolls.
To change the row buffer, set grid property rowBuffer to the number of
rows you would like to render in addition to the visible rows. Set
rowBuffer=0 to turn off row buffering.
How does rowBuffer function on child rows?
Is there a way in chrome or chromium to determine a performance score for scrolling in the tuning process?
In Marks, click Size and there pops a slider where I can adjust the size of a shape. But how to accurately control the size, is there some property with numbers to accurately control it? I have two sheets to show something similar and I want to display exactly the same sized shapes.
If you want to ensure 'sizes' are the same across two worksheets, I'd suggest snapping the 'size' setting to the center on both, as this is the easiest option to select. You can then use a measure to set the size, if this is desirable, and then the difference in size will be relative on both worksheets.
There isn't a numerical value override for the size slider.
Ben is correct, there isn't yet a numerical value override for the slider. You can use parameters with Min/Max/Sum etc. and a variable to somewhat change the sizes but they have to have multiple entries per line. It is unfortunate that Tableau still doesn't get that people want both a 'relative' sizing system that uses numbers from the dataset and a 'static' sizing system that allows for shapes to be set to '11px' or something along those lines. Yes, you can control that kind of in the dashboard with a vertical and fill entire box etc; but that doesn't address the very real scenario where you want a user to be able to re-size on the fly. Just my two cents.
I ran into this today. Very annoying. Need to keep shapes the same size across all worksheets and therefore same on dashboard.
I have a gtk treeview (inside a GtkScrolledWindow) with two columns.
If I set both columns to the default sizing policy, I have a horizontal scrollbar for the treeview but the columns can't be sized down by the user, which is impractical.
If I set both columns to setSizing Fixed, fixed width 120, I get a nice display and the columns can be resized, but there is no horizontal scrollbar in the treeview (since the columns size down to fit in the width of the treeview I guess).
If I set the first column to setSizing fixed, fixed width 120, the second one to automatic, only the second column is displayed (???).
I would like that by default the first column takes let's say at most 60% of the display, the second column can go all the way and I have a horizontal scrollbar. Certainly I want the user to be able to resize them up or down, not as with the default policy, that you can resize them down!
That's why I tried the first column fixed, the second automatic, it was promessing but I don't understand why the first column is not displayed at all in that configuration.
I add the cell renderers with packstart true, I tried false but it didn't change anything, also I tried setting the expand for the columns to true or false, which didn't have any effect.
Note I'm using the gtk2hs haskell bindings but I'm certain it would be the same in any other gtk binding. Just mentioning if people will ask for code samples.
I'm pretty sure this is a common problem... I'd say nautilus is fixing it the way I'd like to fix it, but I think digging in the nautilus source is going to be quite long...
EDIT well i've discovered the cell renderer's ellipsize setting also has an effect. Setting it to end for the first column and none for the second should be what i want but then the first column is very small and cannot be expanded through resize...
EDIT2 well for now i've moved to word wrapping for the cell renderer, that way i don't have to bother with a horizontal scrollbar... Still curious for the solution to that question though.
I have a TreeView whose columns are all expandable with fixed-mode sizing. I would like to restore the widths of the columns when the user restarts the app. It seems that calling set_fixed_size is the way to do this, but:
If I set only the widths of the columns that the user resized, then the actual column widths end up different from what they were before.
If instead I set all column widths explicitly, then all columns behave as though they had been resized by the user, which is not ideal.
Is there a way to restore the column widths that gets around these problems?
It turns out that expand interferes with fixed_width. In my case, the solution was to set fixed_width and expand=false on columns that the user resized, and expand=true on the others.
So it turns out that we'd like to use fixed height mode, because it's faster and it doesn't constantly try to update the treeview — we saw a significant decrease in CPU use with a table that, unfortunately, may contain a few thousand rows and some 20-ish columns.
Oddly enough, merely turning off autosizing on all the columns doesn't help, one needs to set fixed height mode too.
But of course, the cell contents are of varying length (they're text and numbers), and it would be nice to update the column size time to time (ie. when I know they should be updated, and not all the time like autosizing unfortunately does).
So what I need is being able to figure out that the newly inserted row / cell has insufficient size (I guess something to do with the GtkCellRendererText and Pango will come handy), and then resize the affected GtkTreeViewColumn using set_fixed_width. I've looked at the source of GTK+ to see what they do when autosizing, but couldn't really make head or tails of it. My main problem here is getting to the text layout and/or the cell size requirements from a given TreeView/ListStore/iter combination.
I use perl-Gtk2, but answers are welcome in any commonly used language.