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

[Vadim Zeitlin]

On Sat, 24 Jul 2010 23:57:29 +0000 Greg Chicares <address@hidden> wrote:

GC> Does wxDataViewCtrl have any disadvantages?

 It is not infinitely flexible in theory, unlike wxGrid where we could do
anything we wanted because it's implemented entirely in wx itself. wxDVC is
implemented using native controls under Unix/GTK and OS X and so is limited
to the "normal" stuff you usually do with such controls.

 wxGrid has support for some more spreadsheet-like stuff, e.g. it can show
cells contents in the next cell to it if it overflows and it supports
merging several cells into one. But I don't think this is relevant here,
AFAICS the census view is really more table-like than spreadsheet-like and
so wxDVC should be enough.

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

 No.

 To finish with this, I think that we should go with wxDataViewCtrl unless
you foresee the need to do something really unusual.


GC> >  I wanted to check how did this work in practice (especially if there was
GC> > any way to see the fixed values of all the not shown columns)
GC> 
GC> To answer the parenthetical: no, there is no way to do that. Of course,
GC> you could force it, e.g. with this untested one-line change:
GC> 
GC>  bool CensusView::column_value_varies_across_cells
GC>      (std::string const&                  header
GC>      ,std::vector<Input> const& cells
GC>      ) const
GC>  {
GC> +    return true;
GC> 
GC> If we added a command to toggle that behavior, end users might try it
GC> once, but I believe they'd recoil from the large and bewildering set
GC> of columns and immediately ask how to un-toggle it.

 I agree. I thought about some other way to see this information, outside
of the main control itself. I don't know if this is really useful (if
nobody asked for it, probably not) and I don't have any strikingly great
way to present it anyhow (I thought about having a combobox allowing to
select a column among those not shown in the main control), mainly I was
just curious.

GC> > If so, I guess I need some more complete data files [than sample.cns]
GC> > to see anything interesting in it. But maybe I'm looking in a wrong
GC> > place?
GC> 
GC> Try this:
GC>   alt-F N C
GC>   ctrl-shift-E [...all those piano lessons I took as a child...]
GC>   click around and change a bunch of stuff
GC>   OK
GC>   answer "No" to the pop-up dialog
GC> Now you see a whole bunch of columns.

 Thank you very much, I see it now. I was looking for a way to enter these
columns directly, i.e. I definitely expected some of the possibilities
discussed below to be available.

GC> That's okay for the wxListCtrl implementation. But a grid implementation
GC> creates new possibilities, and one question it raises is: how do I add a
GC> grid column for some particular field like "IssueAge"? Ideas:
GC> 
GC> - Use only the same method as in the present implementation: bring up the
GC> tabbed dialog for some cell, and enter some data that varies across that
GC> column. The "only" part of this idea is no good. Users want to be able to
GC> avoid that dialog. Often, they'll have just a few columns of data, like
GC>   IssueAge Gender SpecifiedAmount
GC> and they want to (1) set up those columns and (2) fill them in.
GC> 
GC> - A drop-down combobox in the header, from which any available field can
GC> be chosen to add as a column. Is it difficult, or weird, to put comboboxes
GC> in a header?

 It's a bit weird but I think it's not such a bad idea, the main problem I
see is that you'd always need to have an unused rightmost column. This
problem is avoided if the combobox is outside the header but then it might
be a bit less obvious to find.

GC> Anyway, this might not be very practical because there are hundreds of
GC> items to choose from.

 Is it possible to organize them hierarchically? We can have a combobox
with a tree control as a pop down.

GC> - A pop-up "Add a column" dialog. Pop-ups IMO are generally to be avoided
GC> where possible,

 Exactly my feelings.

GC> but using one here could enable us to present hundreds of columns in an
GC> accessible way--e.g., as numerous categorized lists.

 If we can do it in the combobox dropdown, it would be even better,
wouldn't it?

 BTW, for keyboard loving users a combobox has a nice additional advantage
of being able to provide auto-completion. So you could enter "iss" and it
would propose all fields starting with this prefix to you, hopefully making
the choice much simpler.

GC> I guess the last of those three ideas is the only appealing one. There
GC> are details to work out (If I can "Add" a column, can I "Remove" it?

 I guess it should be possible but it does raise the question of what value
(if they differ) should be used for this column after it's removed. I guess
we'll need to ask the user, I don't see any way around this.

GC> Can I "Add" multiple columns at once?),

 This is the most important argument against using a combobox (even with
custom dropdown) that I see. If the users will typically need to add more
than one column at once, a separate dialog (or maybe a separate group of
controls in the same window) must be used.

GC> but before working that out in detail we should try to think of other
GC> ideas that may be even better.

 I don't see anything radically different.

 Regards,
VZ