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

[Greg Chicares]

On 2019-06-25 12:07, Vadim Zeitlin wrote:
>  Thanks a lot for your immediate reply!
> 
> On Tue, 25 Jun 2019 00:57:30 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2019-06-24 21:29, Vadim Zeitlin wrote:
> GC> > 
> GC> >  Trying to implement a wxGrid-based UI for the census view editor, I've
> GC> > realized that I'm not really sure how is it supposed to work, from the 
> user
> GC> > point of view. The main question I have is about selection: in the 
> current
> GC> > UI, the selection unit is a row, and at least one (but possibly more) 
> row
> GC> > is always selected. However I'm not sure if the census behaves like this
> GC> > because this is what we really need or because this is all that the
> GC> > currently used control supports and, in particular, because the 
> currently
> GC> > used wxDataViewCtrl doesn't really have any notion of the "cursor cell",
> GC> > it's always part of the "currently selected row".
> GC> 
> GC> At some time in the past, we had the old list-view census manager, and
> GC> the current data-view one, both in lmi simultaneously. (You can probably
> GC> find the relevant commit pretty easily, but let me know if you can't.)
> 
>  Sorry, I do have trouble finding anything like this: AFAICS the
> wxDVC-based editor was added in b74c4a444fcac3e0cc1e4c00b7ee9658b1a28cfe,
> then reverted in e5e5477a20b6251aa219615a4e05240cd78b3a60 and readded back
> in f595871df3a05bb98195b6f18a0035fed26a9034 in a different form. However I
> don't see any commit in which we'd have both of them simultaneously.

My mistake--those different versions never did coexist simultaneously
(as the XSL-FO and wxPdfDoc implementations did, for example).

> GC> IIRC, the "old" one had some code that signalled an error if an attempted
> GC> operation required a selected row, but no row was selected. If that old
> GC> selection-checking code wasn't too awful, we might want to revive it.
> 
>  I'm going to look at wxListCtrl-based version in more details, but I'm not
> sure if it's really a good base to build on, as it must have necessarily
> been row-oriented as well (if anything, wxListCtrl is even more
> row-oriented than wxDVC).

Looking at the old IHS implementation would also be an option, but I
wouldn't recommend it--it used a grid control, but in a row-oriented
way only, and IIRC it was straightforwardly ported to wxListView.

Historically, most operations (edit, run, or print a single cell)
were row oriented. (Here, the terminology is confusing: the menus
use "cell" to designate what you might think of as a "record" in a
census, but in spreadsheet terminology that's a "row".) Until we
added drill-down editing a few years ago, a census was nothing more
than a row-addressable set of records. But by that time we had
already evolved from a grid (IHS) to a listview, then a dataview.
That's why going back to the old grid implementation won't help.

> GC> In fact, it might be a good idea to revive the old listview-based code,
> GC> because IIRC there was a listview-dataview runtime switch that will be
> GC> useful for testing a wxGrid reimplementation,
> 
>  I don't think we had such switch and it's not going to be trivial to add
> one because there is no "extra level of indirection" that would allow us to
> have 2 CensusView implementations in parallel and if we really want to do
> this, we'd need to do it inside CensusView, which is not going to be
> pretty.
> 
>  However if you think it's indispensable, please let me know and we'll do
> it nevertheless. But I'd strongly prefer to avoid complicating things by
> supporting more than one control in the editor if possible.

Although a switchable PDF implementation was pretty easy, perhaps that
was because it was just a matter of calling a single non-GUI function.
It looks like making CensusView switchable would be much harder.

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

Indeed. I was wondering, however, whether that 50% was so tightly
bound to wxDataView that it would have be be redone anyway.

> GC> >  By contrast, wxGrid does always have the current cell.
> GC> 
> GC> Then...problem solved? There's always a current cell, and therefore
> GC> there's always a current row, so "Census | Edit cell" always knows
> GC> which cell to edit.
> 
>  This is exactly what I thought initially. But the case of the current cell
> being outside of the selection makes things confusing.
> 
>  Also, please note there is an unfortunate clash of terms: wxGrid contains
> cells, but lmi calls "cell" what wxGrid calls "row". This isn't a problem
> in lmi UI, where the word "cell" is, and will be, always used in lmi sense,
> but it does make this discussion a bit confusing, so I'll try to
> disambiguate them below.

End users would call that a "life": a census contains various "lives",
and each one is a "life". (That's insurance jargon, not normal English.)

A COBOL programmer would call it a "record".

We could use either of those terms for this discussion.

> GC> Even something as simple as "copy selected columns to clipboard" could
> GC> turn out to be very useful.
> 
>  OK, so it seems like we should allow column selections.

It's been years since I worked with wxGrid--decades, maybe. Are there
flags that control what sort of selections are allowed? If there are,
then we might initially do the simplest possible thing:
 - forbid selecting entire rows or columns by clicking their headers
 - forbid disjoint selections
 - allow a contiguous selection across multiple rows only for "delete"
 - otherwise, treat the highlighted cell as selecting a single row

> GC> >  OTOH, partially because of this flexibility, we can't guarantee that 
> there
> GC> > is always non-empty selection in wxGrid. How important is it to always 
> have
> GC> > some selection?
> GC> 
> GC> Options:
> GC>  - Always ensure some row is selected. (I think all current operations
> GC>    that use a selection require only a row selection.)
> 
>  But this is incompatible with allowing to select columns too. I.e. I
> really don't see how could we impose both having a row selection and
> allowing to select one or more columns as well, while it might still be
> technically feasible, it would just look very strange to the users.
> 
> GC>  - Identify all operations that require a selection, and somehow guard
> GC>    against absence of a selection. E.g., "That operation is valid only
> GC>    when a row is selected...".
> 
>  We can do this, of course, but is this really going to be user-friendly?
> I.e. do we have to force the user to select an entire row before performing
> operations on the current cell-in-lmi-sense? I don't think so and believe
> that we should just use the row of the current cell-in-grid-sense if there
> is no selection.
> 
>  The question, for me, remains about what should be done when we do have
> the selection and the current cell is outside it.

And my question is: how can that situation possibly arise?

If it can arise only by clicking one or more column headers, then
can we just not allow such selection, at least for now?

> GC> An empty selection is always possible, at least in concept: select two
> GC> out of five rows and delete them--then nothing is selected.
> 
>  Note that this is not the case in the current version: there always is a
> selected row and the census can't be empty, i.e. we explicitly prevent the
> user from deleting all the cells:
> 
>       [Content]
>       Cannot delete all cells. A census must always contain at least one cell.
>       [census_view.cpp : 1606]

Understood: you cannot delete all cells (lives, records) leaving the
census empty. However, if a census has five lives, you can select
the middle three and "delete" all three in a single operation. When
you do that today, apparently some row (life) becomes "selected"
(maybe the last preceding row, or the first following row). Does
wxGrid do something like that automatically, so that some spreadsheet
cell always has the "highlight"?

> GC> Does using wxGrid really make the situation much more complex? How?
> 
>  Yes, it does, by having both the current cell and the selected cells,
> which are possibly disjoint. With wxDVC we only had the selected rows.
> 
> GC>  - Maybe it lets you select one or more cells, then deselect all of them.
> GC>    But then we could use the get_selected_row() idea above.
> GC>  - Maybe it lets you select many cells; then which represents the
> GC>    "current row"? But we have that problem today: we can select two
> GC>    data-view rows, and attempt "Census | Edit cell"...in which case the
> GC>    command is silently ignored. But whatever we choose to do with wxGrid
> GC>    can't be worse than that, can it?
> 
>  I'm more or less convinced that "Census | Edit cell" should apply to the
> current cell-in-grid-sense. However it's less clear what should happen with
> the other operations, notably "Census | Delete cell(s)".

Didn't you mean "cell" in the (life == record == row) sense? IOW,
in spreadsheet terms, if the highlight cursor is currently in $C$5,
then for now it matters little that column $C is the "current" column,
while it matters greatly that row $5 is the "current" row.

> GC> > And if it is, should we just consider the row containing
> GC> > the current cell as the "active" row in absence of the selection? This 
> is
> GC> 
> GC> Let's formulate the question precisely. In an actual spreadsheet like
> GC> gnumeric, we might say that a row is selected iff...
> GC> 
> GC> (A) One or more of the "1,2,3...BigN" gray row headers is selected.
> GC> That is rarely the case. It's useful for setting a single format for
> GC> all cells in the row; I can't immediately think of other uses.
> GC> 
> GC> (B) That row contains the "highlight cursor" or whatever it's called:
> GC> the selection box that can be moved with the arrow keys. (If you select
> GC> something and delete the selection, I think a spreadsheet moves the
> GC> highlight to...some nearby place that makes sense.)
> GC> 
> GC> I'm thinking only of (B).
> 
>  Err, but you can't just ignore (A). First of all, I think we need to
> support it because this is what will allow us to operate on entire columns
> at once. Second, because even if we disable row/column selection (BTW, they
> can also be selected by the de facto standard Ctrl- or Shift-Space key
> combinations and not just by clicking on the corresponding header), we
> still need to have multiple selection, in order to allow deleting several
> rows at once, for example, and as long as we can select multiple cells,
> nothing can prevent the user from selecting all the cells in some row or
> column by going to the first one and pressing Shift-End or something like
> this.
> 
>  So we do need to think about both (A) and (B).

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

Then the only multiple selection method possible consists of moving
the highlight to a cell, anchoring it by pressing Shift, and moving
the highlight somewhere else. In that case:
 - for "delete", all rows in the highlight region are "selected";
 - for all other operations, the row with the current highlight is
   the one "selected".

> GC> > what I wanted to do initially, but then I thought about the situation in
> GC> > which the current cell wouldn't be part of the selection and couldn't
> GC> > decide what should be done in this case.
> GC> 
> GC> I'm not sure I understand. Isn't the current cell always part of
> GC> the selection?
> 
>  It usually is, but this is not necessarily the case. For example, you
> could start with any cell, press Shift-Right and Shift-Down to select a 2x2
> square and then Ctrl-Click on the top-left corner of this square to
> deselect it. This leaves 3 selected cells and the current one, which is not
> selected any longer. Moreover, you can now click on the top-right corner to
> deselect it as well, leaving you in a situation where you have 2 highlighted
> cells in the bottom row and no selected cells in the top row. And my
> question is, what should happen if the user selects "Delete cell(s)" now?
> In the simplistic approach, we would delete both rows, but doesn't this
> seem a bit counterintuitive?

Few end users know how to do what you describe in the preceding
paragraph.

For now at least, I think we should just do something simple.
In the situation you describe, it would be okay to refuse to
perform a deletion because the selection is complex and we can't
unambiguously tell which rows the user wants to delete.

> GC> I.e., even if I select disjoint cells like
> GC>   A$1, B$3, C$4-7
> GC> with something like shift-click, doesn't the "current cell" highlight
> GC> move to the last cell I selected?
> 
>  Yes, it does, but you can deselect it later.
> 
> GC> But you might be a more sophisticated spreadsheet user than I, so
> GC> maybe there's something I'm missing.
> 
>  I'm afraid there is. FWIW you can easily reproduce the scenario above with
> the grid sample from wxWidgets. It also has a "Select | Change selection
> mode" menu item, allowing to change the selection mode to "rows", "columns"
> or "rows or columns", if you'd like to experiment with how these modes
> work.

I don't think we routinely build the samples, and I don't have time
to look into that now. If we can forbid such complex selections for
now, then we don't have to think about this yet. Otherwise, let's
just figure out some simple way to decide which row the end user
has "selected".

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

What's an "H"-shaped selection?

The question is: with a wxGrid in whatever selection state may arise,
which single row is "selected" for the purpose of single-row commands?
Surely there's some reasonable way to decide that--e.g., by treating
the row containing the grid-cell highlight as the "selected row". If
there's some way to manipulate wxGrid such that no grid-cell highlight
exists, it's okay to refuse to perform single-row commands: few if any
end users would be able to enter such a state anyway.

> GC> >  Please let me know how should the selection behave, if possible, 
> because
> GC> > I'm really not sure about what we're trying to achieve here.
> GC> 
> GC> Today, the dataview-based census manager's row-centricity constrains us
> GC> uncomfortably. If I'm editing a census with a "Specified amount" column,
> GC> I want to be able to type "100000" in that column (for the current row),
> GC> and then move down that column to the next row, just by hitting Enter.
> 
>  This will work by default in wxGrid.
> 
> GC> And I want a clearly visible single-row, single-column highlight box to
> GC> move when the selection changes--when I hit Enter as above, or when I
> GC> move around with the arrow keys. That's what we're trying to achieve.
> 
>  This will work too and is not a problem.
> 
>  The question -- so far, I still have some other ones for later -- is
> solely about the selection. Right now I think that we're really going to
> use a mixed column/row selection model without allowing selecting the
> individual cells, as this would avoid the problem with the current cell not
> being part of the selection (because you can't deselect an individual cell
> in this mode). The problem with this is that the selection will look a bit
> weirdly when selecting columns, as we'll still have a row selection as
> well, but I guess we'll just have to live with this.
> 
>  Do you agree with this approach? To repeat myself, I think it would be
> useful if you tested it yourself in the grid sample, to better see how this
> works in practice.

I think your concerns pertain to exotic selection states that are
beyond the ken of our end users. If we can forbid such states, for
now at least, then replacing wxDataView with wxGrid will seem to
end users to be just a cosmetic and usability improvement. If we
can't forbid such states, then we should gracefully ignore them
and do something simple and sensible.

Phase One is replacing the underlying control, only for the
reasons cited earlier.

Phase Two will involve...extra improvements that we can't yet
even imagine.

What I'm saying is that we should do Phase One now, and postpone
thinking about Phase Two.