lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Vadim Zeitlin
Subject: Re: [lmi] Grid-bases census view editor UI questions
Date: Tue, 25 Jun 2019 21:24:36 +0200

On Tue, 25 Jun 2019 16:43:24 +0000 Greg Chicares <address@hidden> wrote:

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

 Thanks for the confirmation.

GC> > GC> End users would call that a "life": a census contains various "lives",
GC> > GC> and each one is a "life". (That's insurance jargon, not normal 
English.)
GC> > 
GC> >  Just a question, why doesn't lmi UI use this term then?
GC> 
GC> Originally, we used "life", because that's the term end users
GC> would most naturally use.
GC> 
GC> Then we allowed such records to represent more than one life.
GC> For very large cases, it's common to "condense" a census, e.g.,
GC> so that there are {male,female} X ages{25,35,45,55,65} only:
GC> ten "cells" instead of ten thousand. We needed a name for the
GC> concept of a "life" of cardinality potentially greater than one.

 Unfortunately English doesn't seem to have a suitably quirky collective
noun for a multitude of lives and I don't feel confident enough to invent
one.

GC> I think that's best. "Cell" will become terribly ambiguous, and
GC> "life or lives" is absurd, while "record" has a well established
GC> meaning even if it's perhaps somewhat dated.
GC> 
GC> Of course, changing this is a Very Big Deal, which we should
GC> postpone.

 Yes, absolutely, I didn't propose to change this right now, but it might
be a good idea to do it after the grid changes are integrated.

GC> > 1. Use the current cell for all operations on an individual life, such
GC> >    as "Edit cell".
GC> 
GC> Yes, I think that's the obvious way, and probably the only one
GC> that makes sense. And it's simple.
GC> 
GC> > 2. Only allow row-based selection in wxGrid and use the selected rows,
GC> >    if any, or the current row, as determined by the current cell,
GC> >    otherwise, for the operations on multiple lives, such as "Delete".
GC> 
GC> Okay.
GC> 
GC> >  Incidentally, another question arose during the discussion, but I
GC> > tentatively conclude that
GC> > 
GC> > 3. We can skip implementing a run-time switch between wxDVC and wxGrid
GC> >    implementations of CensusView because adding it would make the code
GC> >    quite a bit more complicated.
GC> 
GC> Agreed.

 Excellent, now I'll think a bit more about the remaining questions in the
light of these decisions, but we can already advance now.

 Thanks again!
VZ

Attachment: pgp0gvdk0az6K.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]