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

[Vadim Zeitlin]

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?


GC> > GC> and also because perhaps it will be easier to adapt listview code to
GC> > GC> wxGrid.
GC> > 
GC> >  I don't really have any reason to think this and CensusView code has
GC> > changed quite a bit since 2011 and is much more advanced now (notably 50%
GC> > of the code is support for custom editors, which didn't exist at all in
GC> > wxListCtrl-based version).
GC> 
GC> Indeed. I was wondering, however, whether that 50% was so tightly
GC> bound to wxDataView that it would have be be redone anyway.

 Yes, it will need to be redone. But it's simpler to redo it starting from
the version in which it's already done rather than starting from a very old
version in which this code hadn't existed at all.

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? 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.


GC> It's been years since I worked with wxGrid--decades, maybe. Are there
GC> flags that control what sort of selections are allowed?

 Yes, and they're documented here:

https://github.com/wxWidgets/wxWidgets/blob/v3.1.2/interface/wx/grid.h#L2109

GC> If there are, then we might initially do the simplest possible thing:
GC>  - forbid selecting entire rows or columns by clicking their headers

 I don't think it's correct to fixate on selecting entire rows or columns
by clicking their headers because they can be selected in other ways (using
the previously mentioned keyboard combinations or just by selecting all the
cells in them using Shift-arrow/drag). Besides, why would we even want to
forbid this when the item below allows selecting them? I feel like I'm
missing something fundamental here.

GC>  - forbid disjoint selections

 This is not supported by wxGrid and, I think, would be quite non-trivial
to implement. Just think about what happens if you delete some cells which
are part of contiguous selection. Besides, again, I struggle to understand
the motivation: why would we want to forbid disjoint row selection? This
works currently, so it would be a loss of functionality and I just don't
see what do we gain.

GC>  - allow a contiguous selection across multiple rows only for "delete"

 This basically means "use wxGridSelectRows selection mode", except for the
"contiguous" part, which is, IMO, needless anyhow.

GC>  - otherwise, treat the highlighted cell as selecting a single row

 OK, we can do this and postpone the column selection for later.

GC> >  The question, for me, remains about what should be done when we do have
GC> > the selection and the current cell is outside it.
GC> 
GC> And my question is: how can that situation possibly arise?
GC> 
GC> If it can arise only by clicking one or more column headers, then
GC> can we just not allow such selection, at least for now?

 I've already answered the first question above but I'd just like to
reiterate that there is nothing special about selecting rows or columns by
clicking on their headers, they can be selected in plenty of other ways
too. The question is whether we should allow individual cells selection or
not and the answer seems to be "no". And if we allow only row selection,
then columns can't be selected in any way, neither by clicking their header
nor using any other keys/mouse actions.

GC> > GC> An empty selection is always possible, at least in concept: select two
GC> > GC> out of five rows and delete them--then nothing is selected.
GC> > 
GC> >  Note that this is not the case in the current version: there always is a
GC> > selected row and the census can't be empty, i.e. we explicitly prevent the
GC> > user from deleting all the cells:
GC> > 
GC> >   [Content]
GC> >   Cannot delete all cells. A census must always contain at least one cell.
GC> >   [census_view.cpp : 1606]
GC> 
GC> Understood: you cannot delete all cells (lives, records) leaving the
GC> census empty. However, if a census has five lives, you can select
GC> the middle three and "delete" all three in a single operation. When
GC> you do that today, apparently some row (life) becomes "selected"
GC> (maybe the last preceding row, or the first following row). Does
GC> wxGrid do something like that automatically, so that some spreadsheet
GC> cell always has the "highlight"?

 There is always a current cell in a non-empty wxGrid, yes.

GC> >  I'm more or less convinced that "Census | Edit cell" should apply to the
GC> > current cell-in-grid-sense. However it's less clear what should happen 
with
GC> > the other operations, notably "Census | Delete cell(s)".
GC> 
GC> Didn't you mean "cell" in the (life == record == row) sense?

 No, what I meant was that if there is no selection, then this menu item
should apply to the current cell of wxGrid.

GC> IOW, in spreadsheet terms, if the highlight cursor is currently in
GC> $C$5, then for now it matters little that column $C is the "current"
GC> column, while it matters greatly that row $5 is the "current" row.

 Yes, this is equivalent to what I wrote above, just worded differently.

GC> Could we, temporarily at least, tell wxGrid not to allow any selecting
GC> whole columns as such? And likewise not to allow disjoint selections?

 Yes to the former question, no to the latter.

GC> I don't think we routinely build the samples, and I don't have time
GC> to look into that now.

 Normally you just need to go to your wxWidgets build directory (i.e.
$exec_prefix/wx-ad_hoc/lmi-$LMI_COMPILER-$gcc_version in your case) and do
"make -C samples/grid". In our case we explicitly passed --without-subdirs
option to configure to avoid generating the samples makefiles, so there is
one small extra step: assuming you're in wx build directory, you need to
run

        $ /cache_for_lmi/vcs/wxWidgets/regen samples/grid/Makefile

first to generate this makefile, before doing

        $ make -C samples/grid && ./samples/grid/grid

to run the sample.

GC> > GC> We do know that some operations like "Census | Edit cell" pertain to a
GC> > GC> single row, and can't be used in any other way. So we do need a 
current
GC> > GC> row selection at all times.
GC> > 
GC> >  Again, this seems incompatible with having a column selection. In
GC> > principle, wxGrid supports it, but forcing the user into "H"-shaped
GC> > selection for no reason doesn't look ideal. But perhaps this is indeed how
GC> > you would like it to work?
GC> 
GC> What's an "H"-shaped selection?

 This won't arise if we forbid the column selection, but just to explain
what I meant: if we allowed selecting columns but always had at least one
selected row, we'd end up with a cross-like selection shape as soon as a
single column were selected and if you wanted to select a couple of
columns, you'd end up with 2 vertical lines and a horizontal one being
selected, resulting in "H"-like shape. IMHO this would look rather strange
and definitely unusual, so I'd prefer to avoid surprising the users with
such appearance and allow selecting only the columns if we wanted to allow
selecting them at all.

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".

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".

 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.

 Please let me know if you disagree with any of these points, thanks in
advance,
VZ

pgp1SjgJzFql2.pgp
Description: PGP signature