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

[Greg Chicares]

On 2019-06-24 21:29, Vadim Zeitlin wrote:
> 
>  Trying to implement a wxGrid-based UI for the census view editor, I've
> realized that I'm not really sure how is it supposed to work, from the user
> point of view. The main question I have is about selection: in the current
> UI, the selection unit is a row, and at least one (but possibly more) row
> is always selected. However I'm not sure if the census behaves like this
> because this is what we really need or because this is all that the
> currently used control supports and, in particular, because the currently
> used wxDataViewCtrl doesn't really have any notion of the "cursor cell",
> it's always part of the "currently selected row".

At some time in the past, we had the old list-view census manager, and
the current data-view one, both in lmi simultaneously. (You can probably
find the relevant commit pretty easily, but let me know if you can't.)
IIRC, the "old" one had some code that signalled an error if an attempted
operation required a selected row, but no row was selected. If that old
selection-checking code wasn't too awful, we might want to revive it.

In fact, it might be a good idea to revive the old listview-based code,
because IIRC there was a listview-dataview runtime switch that will be
useful for testing a wxGrid reimplementation, and also because perhaps
it will be easier to adapt listview code to wxGrid.

>  By contrast, wxGrid does always have the current cell.

Then...problem solved? There's always a current cell, and therefore
there's always a current row, so "Census | Edit cell" always knows
which cell to edit.

> Additionally,
> wxGrid selection handling is quite flexible and by default allows all of
> row, column, cell and rectangular blocks selections (and all of them can be
> combined by using Ctrl/Shift keys when extending the selection). I don't
> really see why would we need individual cell or block selection (but please
> correct me if I'm wrong), but could it perhaps be useful to allow column
> selection, in addition to row selection? Of course, for this to be really
> useful, we'd have to have some operations that can be usefully applied to
> the columns. AFAIR from the previous discussions almost 10 years ago, you
> did want to allow users to operate on columns, but currently we don't see
> to have any such operations (which is, of course, a Catch-22 problem
> because we can't define them with the current UI).

Exactly so. For example, it might be useful to highlight a column (say,
"Gender"), and change all cells to "Unisex" in a single operation. But
we won't know until we have a wxGrid-based census manager.

Even something as simple as "copy selected columns to clipboard" could
turn out to be very useful.

>  OTOH, partially because of this flexibility, we can't guarantee that there
> is always non-empty selection in wxGrid. How important is it to always have
> some selection?

Options:
 - Always ensure some row is selected. (I think all current operations
   that use a selection require only a row selection.)
 - Identify all operations that require a selection, and somehow guard
   against absence of a selection. E.g., "That operation is valid only
   when a row is selected...".
The first of those two seems better. We could accomplish it, e.g., with:

  int get_selected_row()
    if selection exists then use it
    else select first row and use it

An empty selection is always possible, at least in concept: select two
out of five rows and delete them--then nothing is selected. Does using
wxGrid really make the situation much more complex? How?
 - Maybe it lets you select one or more cells, then deselect all of them.
   But then we could use the get_selected_row() idea above.
 - Maybe it lets you select many cells; then which represents the
   "current row"? But we have that problem today: we can select two
   data-view rows, and attempt "Census | Edit cell"...in which case the
   command is silently ignored. But whatever we choose to do with wxGrid
   can't be worse than that, can it?

> And if it is, should we just consider the row containing
> the current cell as the "active" row in absence of the selection? This is

Let's formulate the question precisely. In an actual spreadsheet like
gnumeric, we might say that a row is selected iff...

(A) One or more of the "1,2,3...BigN" gray row headers is selected.
That is rarely the case. It's useful for setting a single format for
all cells in the row; I can't immediately think of other uses.

(B) That row contains the "highlight cursor" or whatever it's called:
the selection box that can be moved with the arrow keys. (If you select
something and delete the selection, I think a spreadsheet moves the
highlight to...some nearby place that makes sense.)

I'm thinking only of (B).

> what I wanted to do initially, but then I thought about the situation in
> which the current cell wouldn't be part of the selection and couldn't
> decide what should be done in this case.

I'm not sure I understand. Isn't the current cell always part of
the selection? I.e., even if I select disjoint cells like
  A$1, B$3, C$4-7
with something like shift-click, doesn't the "current cell" highlight
move to the last cell I selected?

To make the example more concrete, perhaps I select some range in
spreadsheet tab #2, then specify an operation like "copy"; and then
move to tab #4, select a cell, and perform a "paste" operation. At
each step, AFAIK, some cell is the "current" cell.

But you might be a more sophisticated spreadsheet user than I, so
maybe there's something I'm missing.

> Perhaps we should try to reproduce
> the current UI behaviour and ensure that there is "real" selection
> available at all time and that it always includes the current cell? This
> should be doable (although I'm not 100% sure about this), but considering
> that we wanted to move away from wxDataViewCtrl row-centric behaviour,
> might not be what we actually want to do.

That sounds good.

Turning away from dataview row-centric behavior opens new possibilities,
but we can't know today what we might do with those new possibilities.

We do know that some operations like "Census | Edit cell" pertain to a
single row, and can't be used in any other way. So we do need a current
row selection at all times.

>  Please let me know how should the selection behave, if possible, because
> I'm really not sure about what we're trying to achieve here.

Today, the dataview-based census manager's row-centricity constrains us
uncomfortably. If I'm editing a census with a "Specified amount" column,
I want to be able to type "100000" in that column (for the current row),
and then move down that column to the next row, just by hitting Enter.
And I want a clearly visible single-row, single-column highlight box to
move when the selection changes--when I hit Enter as above, or when I
move around with the arrow keys. That's what we're trying to achieve.