Re: [lmi] Correctness and performance of varying column width mode in the census view

[Greg Chicares]

On 2020-05-28 23:52, Vadim Zeitlin wrote:
> On Thu, 28 May 2020 22:02:04 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
[...]
> GC> Entering strings shouldn't cause the column width to change at all.
> 
>  I understand that truncating (actually, ellipsizing) strings is not as bad
> as doing it for the numbers, but couldn't we still expand the columns width
> for them just for consistency, both of the UI and the implementation? The
> latter shouldn't dictate the former, of course, but it's simpler to do the
> same thing for all cells, so if it's not actively harmful, why not do it
> for the strings too?

Okay. I suppose that if I edit a cell to change a person's name, and the
new name is longer than the old width, then it's natural for lmi to widen
the column.

You mention ellipsizing. I think I like truncating better. And 'excel'
only truncates--it never ellipsizes AFAIK--so ellipsizing is "nonstandard".

> GC> >  More I think about this, more I become sure that we really should put 
> some
> GC> > time limit on auto-sizing wxGrid, whatever else we do, as it just 
> shouldn't
> GC> > be possible for it to take arbitrarily long...
> GC> 
> GC> Rhetorical question: what should it do if the time limit is exceeded?
> 
>  Same thing as wxDVC does: return the max width computed so far.

Interesting. I didn't imagine that any reasonable answer was possible.
Quoting the next paragraph out of order...

>  There is also a question of whether we should still find the best
> approximation of the fitting width even when the user selects this command
> or if we should take as much time as needed to really find the ideal width.
> I suspect you might prefer the latter, but personally I think the former
> works well enough for any non-degenerate (i.e. specifically constructed to
> make it fail) cases that it would be acceptable to do it even here.

...yes, I suspect I might prefer the latter, but that's the kind of
question that's better resolved after experimenting with a testing
or demo version.

> GC> Instead, I think we should adjust columns widths in this way:
> GC>  - if one string cell changes, do nothing: O(0)
> GC>  - if one numeric cell changes, widen its column if needed: O(1)
> GC>    do that whether the new value is typed in or pasted in
> GC>  - census pasting and applying cell or class changes seem to be
> GC>    O(#rows * #columns), so that's the tough case that requires
> GC>    more investigation and thought--a full resize would be nice,
> GC>    but might be too costly

There's another important scenario: pop up the tabbed dialog to edit
a single cell, and press OK after making some changes. That should take
O(# of data changed in tabbed dialog) time. Even for a change to a single
datum, some end users use the tabbed dialog rather than directly editing
the grid cell.

>  BTW, we need to define what exactly do you mean by strings because there
> are several string-like types: we can have just free form strings
> (datum_string), we can have enum elements, or we can have sequences
> (datum_sequence) that are also shown as strings. I suspect you really mean
> only the first kind of strings, but please correct me if I'm wrong.

Indeed we do have those three kinds of strings. I had dismissed the
enumerative ones, figuring that they're too short to matter, but
I had overlooked sequences, which can grow very long.

I guess they should all be treated the same way. But that's the
simplest thing to do, if we automatically widen columns as needed
for string as well as numeric input, because then all datatypes
are treated the same way.

> GC> AFAICT, if you delete an 'excel' column, the widths of the remaining
> GC> columns are unaffected. That sounds just right.
> 
>  Just to be clear, I meant deleting the rows. In this case finding the
> perfectly correct new best width is O(N), as you could have deleted the row
> containing the widest value for this column.

Then either you invest heavily in making it fast, by caching the
width of every cell in the grid, and pruning the cache entries for
deleted rows (but that sounds like overkill); or you let it be
really slow; or you just ignore row deletions, which would be my
suggestion.

If one row had an especially wide datum, and end users really want
to regain the now-blank space left when that row is deleted, then
they can resize the offending column manually, or click the button
that uses the Really Big Hammer to resize all column widths
optimally. Or maybe we make that hammer smaller and faster, by
restricting that button to manually-selected columns, as discussed
in an earlier email.

> GC> > GC> > - But what about the operations affecting all cells (and so 
> already
> GC> > GC> >   taking O(N) time), such as editing class/case or pasting census
> GC> > GC> >   from clipboard, should they still resize the columns to fit 
> their
> GC> > GC> >   contents?
> GC> > GC> 
> GC> > GC> No.
> GC> > 
> GC> >  OK, thanks.
> GC> 
> GC> As mentioned a few paragraphs above, I now think we should probably
> GC> preserve the present widths of previous columns that remain after
> GC> such a change,
> 
>  Yes, ideally we'd do this... Currently the code is so simple that it
> doesn't track the remaining columns and just recreates all of them (this
> was/is also the case for wxDVC).
[...]
> 
>  There is indeed a consideration of time-complexity in the number of
> columns, that I mostly omitted so far, speaking about O(N) with N being the
> number of rows. I suppose that there won't be as many columns as there can
> be rows, but this could still be a problem and we should, of course, avoid
> recalculating the widths of the columns which didn't change. The trouble is
> that this requires more code, hence more complexity.

I haven't looked at the code or tried implementing it myself, but
I'm naively inclined to think this wouldn't introduce much extra
complexity. Probably it should be done at the lmi level, because
this particular operation is pretty lmi-specific, and for lmi we
know that all columns must belong to a relatively small, immutable,
predetermined set; those circumstances make it seem feasible for
lmi, but may not generalize at all on the library level.