[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Vaclav Slavik
Subject: Re: [lmi] Allow direct drill-down editing in census manager
Date: Thu, 05 Aug 2010 18:46:51 +0200


[There's a terminology problem; I'll use "cell" in the spreadsheet cell
sense and if I need to refer to LMI Cells, I'll use "Cell".]

On Thu, 2010-08-05 at 11:32 +0000, Greg Chicares wrote:
> But the problem we're trying to solve is that it's too row-oriented
> today. Users want to be liberated from that straitjacket. They might
> load a saved census, and want to change everyone's "specified amount".
> To them, a spreadsheet is the natural abstraction, and they want to be
> able to navigate columns as easily as rows. Even in the days before
> spreadsheet programs or personal computers existed, a census was a
> two-dimensional array: a multi-column list, created on a typewriter or
> written by hand.

That 2D array is only a particular *rendering* of a census -- and in
this sense, both wxGrid and wxDVC are 2D arrays. What I'm trying to
understand is whether it is -- semantically -- a list of records=Cells
or a grid of somewhat independent values organized in 2D space.

Or, to put it differently, whether the straitjacket is the inconvenient
UI for editing the records (no in-line editing, you have to go to a
dialog) or if there are (other) problems caused by the orientation to

> > - Three clicks seemed reliably necessary to edit a control [...]
> I'd be least surprised if it supported the same ways of entering and
> exiting edit mode as a spreadsheet.
> > - Similar (but different) behavior exists on the dialog that has
> >     the toggle checkboxes [...multiple clicks required...]
> I'd expect a single click, or a single depression of Spacebar, to toggle a
> checkbox.
> > - I prefer using the keyboard for navigating between cells

There are all merely implementation details, current defects that can
and should be fixed. It's not a fundamental property of wxDataViewCtrl
that double clicks are required or that keyboard navigation must not

> Navigation behaviors like wxGrid's would be useful: a highlighted
> selection (row and column) that works like a spreadsheet's.

This, however, is *the* difference that matters. wxDataViewCtrl is
row-oriented, wxGrid is cell-oriented. You cannot select a cell in
wxDVC. You cannot select a row in wxGrid -- when you do, you're making a
multi-cell selection of a set of cells (with e.g. keyboard navigation
implications: up arrow doesn't select previous row, it cancels the
selection and selects a single cell). 

In both controls, *focus* is cell-oriented. Note that this is different
from *selection*. You can move focus to, and edit, individual cells in
both. It's just the selection that behaves differently.

In particular, selection of a cell, or multiple cells, is impossible in
wxDVC. But do you actually need it? You don't need it for keyboard
editing -- that's what the focus is for. You don't need it for mouse
editing either -- you just click on the thing you want to edit.

The only thing it would be useful for is editing of multiple cells at
once, to assign them all the same value. Is that something you need? And
if you do, how is that done in Excel and friends? I couldn't find a
way... (That's just my curiosity, I don't think it's something that
would fit in wxDVC well.)

>  Highlighting one full row
> at a time suggests the strong record orientation of a listview, which we're
> trying to escape.

I terribly misunderstood this :( I thought the goal was just to enable
in-line ("drill-down") editing of cells as an incremental improvement on
the current UI, rather then to change the editing UI entirely.

> Overall, I guess we're saying that wxDataView is suitable to the extent
> that (a subset of) it can be made to behave like (a minimal) wxGrid. 

It cannot, there's the fundamental difference discussed above.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]