Re: [lmi] Grid-bases census view editor UI questions

[Greg Chicares]

On 2019-06-25 14:40, Vadim Zeitlin wrote:
> On Tue, 25 Jun 2019 14:04:46 +0000 Greg Chicares <address@hidden> wrote:
> 
> [speaking of a run-time switch between wxDVC and wxGrid]
> GC> Although a switchable PDF implementation was pretty easy, perhaps that
> GC> was because it was just a matter of calling a single non-GUI function.
> GC> It looks like making CensusView switchable would be much harder.
> 
>  Yes, exactly. Do I understand correctly that this constitutes a
> sufficiently strong excuse to avoid doing it?

Yes, agreed.

> GC> End users would call that a "life": a census contains various "lives",
> GC> and each one is a "life". (That's insurance jargon, not normal English.)
> 
>  Just a question, why doesn't lmi UI use this term then?

Originally, we used "life", because that's the term end users
would most naturally use.

Then we allowed such records to represent more than one life.
For very large cases, it's common to "condense" a census, e.g.,
so that there are {male,female} X ages{25,35,45,55,65} only:
ten "cells" instead of ten thousand. We needed a name for the
concept of a "life" of cardinality potentially greater than one.
Unfortunately, we chose "cell".

> I'm afraid that
> (contrary to what I wrote in the last message because I just love
> contradicting myself) the use of the word "cell" could result in a
> confusion when we have real, actual cells in a grid. I.e. people could
> reasonably think that selecting some cells and choosing "Delete cell(s)"
> should delete just these cells and not the lives that these cells belong
> to.
> 
> GC> A COBOL programmer would call it a "record".
> 
>  This would work better than "cell" too, IMHO.

I think that's best. "Cell" will become terribly ambiguous, and
"life or lives" is absurd, while "record" has a well established
meaning even if it's perhaps somewhat dated.

Of course, changing this is a Very Big Deal, which we should
postpone.

> GC>  - otherwise, treat the highlighted cell as selecting a single row
> 
>  OK, we can do this and postpone the column selection for later.

Agreed.

> GC> Phase One is replacing the underlying control, only for the
> GC> reasons cited earlier.
> GC> 
> GC> Phase Two will involve...extra improvements that we can't yet
> GC> even imagine.
> GC> 
> GC> What I'm saying is that we should do Phase One now, and postpone
> GC> thinking about Phase Two.
> 
>  OK, so the answer to the original question is:
> 
> 1. Use the current cell for all operations on an individual life, such
>    as "Edit cell".

Yes, I think that's the obvious way, and probably the only one
that makes sense. And it's simple.

> 2. Only allow row-based selection in wxGrid and use the selected rows,
>    if any, or the current row, as determined by the current cell,
>    otherwise, for the operations on multiple lives, such as "Delete".

Okay.

>  Incidentally, another question arose during the discussion, but I
> tentatively conclude that
> 
> 3. We can skip implementing a run-time switch between wxDVC and wxGrid
>    implementations of CensusView because adding it would make the code
>    quite a bit more complicated.

Agreed.