Re: [lmi] Allow direct drill-down editing in census manager

[Greg Chicares]

On 2010-07-24 14:48Z, Vadim Zeitlin wrote:
> On Tue, 16 Mar 2010 21:06:57 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> > There's tons of fields in cell editor;
> GC> 
> GC> I counted them once; I think their cardinality approaches 2^8,
> GC> which might be a built-in limit on a grid control's columns.
> 
>  FWIW there is no limit for the number of columns in wxGrid.

I'll assume that wxDataViewCtrl also permits many more than 2^8 columns,
so wxGrid has no comparative advantage there.

> There might be
> a limit in the native wxHeaderCtrl which the grid may optionally use and
> that both wxListCtrl and wxDataViewCtrl always use but if there is one I
> can't find it in the Microsoft documentation and it would be easy enough to
> allow to use the generic implementation of wxHeaderCtrl with wxDataViewCtrl
> if needed (the native one looks slightly better but the generic one is
> perfectly functional and in fact wxDataViewCtrl used to use it before the
> native one became available).
> 
>  For me the interesting question is whether we may need to have non-flat
> structure of the rows in this control, i.e. whether it may make sense to
> organize them in tree- or forest-like structure and allow the user to
> collapse the branches that are not relevant.

Is there an easily-accessible program on the web that demonstrates these
capabilities, or even a set of screen shots? I suppose they're trees or
forests in an abstract sense, but in a visual sense I'd guess they're
sets of 2-D planes...like tabbed "worksheets" in a spreadsheet program?

The pre-wx predecessor of lmi used a 2-D grid control here, but all I
had was a 2-D control, so the Sapir-Whorf hypothesis came into play.
If I could see what wxDataViewCtrl offers beyond a 2-D visualization,
I might find good use for it.

> If not, then either wxGrid or
> wxDataViewCtrl would do. wxGrid has the advantage of being completely
> generic and so allow just about anything you may need but it is limited to
> a flat 2D array of cells unlike wxDataViewCtrl. wxDataViewCtrl also looks
> better, especially under non-MSW platforms (it doesn't have native
> implementation for the main part of the control under MSW), but the main
> reason to choose it would be to be able to allow for hierarchical
> structure.

Does wxDataViewCtrl have any disadvantages? For example, is wxGrid more
stable, or does wxDataViewCtrl require building wx in a non-default way
or including an external library (like wxXRC used to, IIRC)?

>  Anyhow, to summarize, I think that wxDataViewCtrl is probably the most
> suitable one for the purpose of the task at hand but wxGrid could
> definitely be also used. wxListCtrl has several big limitations compared to
> these controls, e.g. it only allows to edit the first cell of any row in
> place. But I don't know which, if any, of them really matter so maybe there
> is no need to switch the GUI control used at all.

wxListCtrl is not appropriate: end users want to edit all cells, not
only those in the first column.

> GC> That's what led me to the idea of displaying only columns that
> GC> aren't actually the same across all rows. New users are mystified
> GC> at first, but that only lasts a minute; once they understand it,
> GC> they think it's natural enough that they don't ask us to change it.
> GC> If everyone lives in California, then how could the US-state field
> GC> hold any interest? If people of both genders are included, then
> GC> how could gender not be significant enough to show?
> 
>  I wanted to check how did this work in practice (especially if there was
> any way to see the fixed values of all the not shown columns)

To answer the parenthetical: no, there is no way to do that. Of course,
you could force it, e.g. with this untested one-line change:

 bool CensusView::column_value_varies_across_cells
     (std::string const&                  header
     ,std::vector<Input> const& cells
     ) const
 {
+    return true;

If we added a command to toggle that behavior, end users might try it
once, but I believe they'd recoil from the large and bewildering set
of columns and immediately ask how to un-toggle it.

> but I
> couldn't actually find it. Sorry in advance for the stupid question but

No, it's a very good question, which raises other questions that I
don't have final answers to...see below.

> what exactly should I do to see/edit this grid?

You're already seeing it when you do this:

> Is this the same one I see
> when I do "Open" or "New" "census"?

Yes, exactly.

http://www.nongnu.org/lmi/faq.html#how_census_blank

> If so, I guess I need some more
> complete data files [than sample.cns] to see anything interesting in it.
> But maybe I'm looking in a wrong place?

Try this:
  alt-F N C
  ctrl-shift-E [...all those piano lessons I took as a child...]
  click around and change a bunch of stuff
  OK
  answer "No" to the pop-up dialog
Now you see a whole bunch of columns.

That's okay for the wxListCtrl implementation. But a grid implementation
creates new possibilities, and one question it raises is: how do I add a
grid column for some particular field like "IssueAge"? Ideas:

- Use only the same method as in the present implementation: bring up the
tabbed dialog for some cell, and enter some data that varies across that
column. The "only" part of this idea is no good. Users want to be able to
avoid that dialog. Often, they'll have just a few columns of data, like
  IssueAge Gender SpecifiedAmount
and they want to (1) set up those columns and (2) fill them in.

- A drop-down combobox in the header, from which any available field can
be chosen to add as a column. Is it difficult, or weird, to put comboboxes
in a header? Anyway, this might not be very practical because there are
hundreds of items to choose from. It's bad enough that we have about forty
columns to choose from on the "Reports" tab of the tabbed input dialog.

- A pop-up "Add a column" dialog. Pop-ups IMO are generally to be avoided
where possible, but using one here could enable us to present hundreds of
columns in an accessible way--e.g., as numerous categorized lists. This
could be combined with the good features of the present implementation
like this:

 bool CensusView::column_value_varies_across_cells
     (std::string const&                  header
     ,std::vector<Input> const& cells
     ) const
 {
+    if(ThisColumnWasSelectedInThePopupAbove(header))
+        return true; // ...then always display it

IOW, you "Add" a column for Gender, and it is always imperatively shown.
Then you edit some cells using the tabbed dialog (as you would today),
and any column the varies across cells is conditionally displayed (as it
is today) as long as that column continues actually to vary.

I guess the last of those three ideas is the only appealing one. There
are details to work out (If I can "Add" a column, can I "Remove" it?
Can I "Add" multiple columns at once?), but before working that out in
detail we should try to think of other ideas that may be even better.