[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
pgp0gvdk0az6K.pgp
Description: PGP signature
Re: [lmi] Grid-bases census view editor UI questions, Greg Chicares, 2019/06/27