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

[Vadim Zeitlin]

 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.

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

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.

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


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.

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.

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.

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:

        [Window Title]
        Warning

        [Content]
        Cannot delete all cells. A census must always contain at least one cell.
        [census_view.cpp : 1606]


        [OK]

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


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

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?

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.

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?


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.

 Thanks again!
VZ

pgphhIocZ_E0a.pgp
Description: PGP signature