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

[Greg Chicares]

On 2020-05-27 18:32, Vadim Zeitlin wrote:
> On Wed, 27 May 2020 16:56:46 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
[...]
> GC> Suppose we have a field containing a person's name, say, "John Brown",
> GC> and (pretending this is monospace ASCII) those ten letters are rendered
> GC> in a column of width eleven (pretending that the column separator is a
> GC> single ASCII space). Now the end user changes that one field, in that
> GC> one column, to "Sojourner Truth". If we don't change the column width,
> GC> the screen shows "Sojourner" because that's all that fits, " Truth"
> GC> being truncated; is that truncation your operative definition of
> GC> incorrectness?
> 
>  Yes.
> 
> GC> I'm hoping that's all it is, because I think that truncation is not
> GC> really unreasonable, as it's what spreadsheet programs do. AIUI,
> GC> for spreadsheets, "resize column widths" is a verb--whereas lmi has
> GC> (at least until now) offered such a behavior as a sticky mode, in
> GC> which the verb is called whenever any contents change (in that mode).
> 
>  Yes, exactly. And we have CensusView::autosize_columns_ which stores the
> current mode.

Yes, and the mode is inherent to the control being used:
  int width = autosize_columns_ ? wxCOL_WIDTH_AUTOSIZE : wxCOL_WIDTH_DEFAULT;

> GC> While that "always resize everything whenever anything changes" mode
> GC> does have a certain charm for a tiny census, it seems far too costly
> GC> for a large number of columns and rows.
> 
>  Currently it is indeed far too costly, but there is no intrinsic reason
> for it to be so, at least not when changing a single cell, because all we
> need to do is to measure the length of a single string and increase the
> column width if the new string doesn't fit into it.

My impression is that spreadsheet programs might do that sometimes,
but certainly not always--e.g., they might adjust the width of only
the current column when a new cell value is typed in, but not when
a cell or a block of cells is pasted. In general, though, they seem
not to auto-re-size.

>  Now there are other complications, e.g. the operation would still be O(N),
> where N is the number of rows, if we wanted to also reduce the column
> width, but IMO this is much less important and we could avoid doing this.

I don't think it's very important to treat narrowing as a special case,
differentiating it from widening. That's the kind of refinement that
might make sense at the library level (wx), but not the application (lmi)
level.

> There are also operations affecting all cells, such as "Edit class/case",
> but those are presumably less frequent than editing individual cells, so
> perhaps it's not as annoying that they take so long.

Instead of restricting the annoyance to certain cases, we should
eliminate it globally.

> GC> AFAICS lmi's GUI presents it as a verb. IOW, there are separate toolbar
> GC> buttons for "fixed" and "variable", rather than a single button that's
> GC> either depressed or not. Thus, the stickiness of the notional mode is
> GC> just an internal artifact that we can and should eradicate.
> 
>  This is a huge surprise to me because I was absolutely convinced that this
> was a conscious decision and took it for granted that we wanted to keep it.
> I don't know why exactly did I believe this, I'd like to think there was
> some reason for it, but it's probably not really important to spend time on
> finding the exact reason in the list archives or the commit messages if
> you're sure that we don't want to do this anyhow... (and perhaps I'm
> misremembering things again and there never was any such reason).

The current behavior may date from the 1990s, and might have been chosen
merely because auto-re-sizing was available with the "VBX" control that
was originally used for the grid. But auto-re-sizing is simply a misfeature,
and that's all we need to know.

It's curious that lmi today offers this choice:
 - change all column widths to fit
 - change all column widths to a fixed, hardcoded number
but not this one, which seems obviously desirable:
 - leave columns widths as they are
I.e., you can toggle from auto-re-size-always to reset-to-fixed-width,
but you can't toggle from auto-re-size-always to stop-auto-resizing.

> GC> Does that answer all your questions?
> 
>  It almost does. But, to be sure that I understood correctly, let me
> confirm which UI operations precisely will still need to auto-size the
> columns:
> 
> - Toolbar/menu command "Varying column widths" will do it, of course.

Yes. And autosize_columns_ is false by default, so the speed penalty
never arises unless the end user explicitly changes it.

It's a desirable optional behavior. But if it's painfully slow,
we should either make it fast enough, or remove the option.

> - Editing/adding/deleting cells will not do it, according to your answer,
>   so there is no need to optimize doing it.

Agreed.

Unless, of course, you find a way to make it fast as lightning.

> - But what about the operations affecting all cells (and so already
>   taking O(N) time), such as editing class/case or pasting census
>   from clipboard, should they still resize the columns to fit their
>   contents?

No.

If you perform one of those options, and then decide that you
want the column widths resized, you can click a toolbar button.
The misfeature is behaving as if that button had been clicked
after a modification to the data.

>  Personally I think these operations should still honour auto-size mode if
> it's enabled, both to avoid changing the current behaviour without a good
> reason, and to keep the changes in the code to the minimum, because if we
> don't do this neither, we would need to get rid of the previously mentioned
> CensusView::autosize_columns_ when using wxGrid too (while keeping it for
> wxDVC-based version, whose behaviour shouldn't change).

AFAICS, CensusView::autosize_columns_ is just a handle for the
wxDVC control's wxCOL_WIDTH_AUTOSIZE flag. A brand-new wxGrid-based
census manager could do something different.

> But then I also
> think we should do it for editing cells as well, just in a smart -- and
> fast -- way, so I wouldn't be really surprised if you think differently.

In theory at least, a powerful-enough library could implement fancy
behaviors efficiently, in which case we might want to use them in lmi.
But it's never wrong for this spreadsheet-like control to do what a
good spreadsheet program does, and most of them just leave column
widths as they are most of the time, unless you issue a command to
change them.