Column/row selection/attributes are odd #68

New Issue

glen · 2019-08-29T20:58:02Z

glen commented

2019-08-29 20:58:02 +00:00

It seems as though if I select a row, and then set an attribute, that the attribute is set on something like every column from 0 up to the largest visible column or the largest column already in the sheet, whichever is larger. So (a) the size of the sheet is extended to everything visible, and (b) if the sheet then extends more later, the new cells in the row do not have the attribute. Both of these seem a bit odd. It would seem to be good to have attributes attached at the row & column levels (and maybe for symmetry at the "stack" level for a fixed x&y and varying z). Possibly also attributes at the "layer" level (and perhaps also at the "column stack" and "row stack level") in which just one coordinate is fixed, and maybe at the entire sheet level. In fact, one could even think about having the contents of the cell back off by dimension in this way; i.e. if you set the row content to a totaling function, then every entry in the row would display a total... that's kind of a wild idea.

glen added the

enhancement

label 2019-08-29 20:58:02 +00:00

glen commented

2019-08-30 23:24:46 +00:00

For this we would need a merge of at least styles, if not content as well:

Adding two styles merges them; the non-default components of each are taken, colors are averaged, and the max precision is taken. Outright conflicting values, such as decimal and scientific notation, revert to default values.

But it should be a different operator, so that it can work on other types as well possibly.

For this we would need a merge of at least styles, if not content as well: Adding two styles merges them; the non-default components of each are taken, colors are averaged, and the max precision is taken. Outright conflicting values, such as decimal and scientific notation, revert to default values. But it should be a different operator, so that it can work on other types as well possibly.

glen commented

2019-09-10 12:55:26 +00:00

Should conflicting values in merging styles be an error rather than diverting to default values? In either case, if overridden at the common point, then the conflict should be irrelevant.

Actually, thinking about it further, I think that conflict should back off to unset, so that perhaps the more general value (for the layer/row slice/column slice, or then the entire sheet) could come into play if the higher-priority values conflict.

Should conflicting values in merging styles be an error rather than diverting to default values? In either case, if overridden at the common point, then the conflict should be irrelevant. Actually, thinking about it further, I think that conflict should back off to unset, so that perhaps the more general value (for the layer/row slice/column slice, or then the entire sheet) could come into play if the higher-priority values conflict.

Sign in to join this conversation.