lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Direct drill-down census editor testing


From: Vaclav Slavik
Subject: Re: [lmi] Direct drill-down census editor testing
Date: Wed, 23 Nov 2011 14:58:58 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0

Hi again,

On 2011-10-20 19:11, Václav Slavík wrote:
> On 20 Oct 2011, at 14:36, Wendy Boutin wrote:
>> 1. Keyboard navigation is very limited. I can use the up and down
>> arrow keys to select different cells, but I can't drill down to
>> any particular data column within a cell.
> 
> Yes. This is something I mentioned here before, this functionality
> is missing in the wxWidgets version used by LMI. The trunk version
> is much better, I just have some minor finishing touches to do, before
> it's fully ready for LMI. I'll post here once all the patches land.

wx SVN has keyboard navigation implemented now. Navigation between
columns works with left/right arrows, editing is triggered with
spacebar, Enter or F2.

There's one regression in there that needs fixing before it can be
used with LMI, though: pressing Enter when directly editing a spin
control value cancels the edit instead of committing it.

>> 4. The size of input controls is inconsistent; text controls look
>> shorter in height than all other controls.
> ...
>> 5. Selecting a control for editing causes it to grow tall enough
>> to cover much of the data in the row below it. It can be convenient
>> to see the next cells data if a user is editing an entire column
>> from top to bottom.
> 
> This should be fixed, of course -- all inline controls should use the
> same height and it should correspond to the row's height when not
> editing, both for the practical reasons you mention and for aesthetic ones.
> 
>> Also, within the text
>> control, the alignment of the inputted text makes it difficult to
>> read. Maybe all it needs is a border, but right now it isn't easy
>> to distinguish a 'q', 'g', and 'p'.

All these problems are caused by too small row height. wx's default
is now 2px larger, but some overlap is unavoidable even then. The only
reasonable fix that I can see is to do as follows:


(1) Revert the use of too small heights:

diff --git a/census_view.cpp b/census_view.cpp
index f7368d4..9e37ad8 100644
--- a/census_view.cpp
+++ b/census_view.cpp
@@ -948,11 +948,6 @@ wxWindow* CensusView::CreateChildWindow()
         ,wxDV_ROW_LINES | wxDV_MULTIPLE
         );
 
-    // Use same row height as used by wxListCtrl without icons. By default,
-    // wxDataViewCtrl uses slightly larger spacing, but we prefer to fit more
-    // on the screen over slightly improved readability.
-    list_window_->SetRowHeight(list_window_->GetCharHeight() + 1);
-
     list_window_->AssociateModel(list_model_.get());
 
     // Show headers.


(2) Use default control sizes only when necessary:

 diff --git a/census_view.cpp b/census_view.cpp
index f7368d4..9e37ad8 100644
--- a/census_view.cpp
+++ b/census_view.cpp
@@ -303,12 +303,16 @@ wxWindow* DateRenderer::DoCreateEditor
      ,wxRect const& rect
      ,tn_range_variant_data const& data)
 {
+    // Always use default height for editor controls
+    wxRect r(rect);
+    r.height = -1;
+
     wxDatePickerCtrl* ctrl = new(wx) wxDatePickerCtrl
         (parent
         ,wxID_ANY
         ,ConvertDateToWx(value_cast<calendar_date>(data.value))
-        ,rect.GetTopLeft()
-        ,rect.GetSize());
+        ,r.GetTopLeft()
+        ,r.GetSize());
 
     ctrl->SetRange
         (ConvertDateToWx(jdn_t(static_cast<int>(data.min)))
@@ -400,11 +404,7 @@ wxWindow* 
DatumSequenceRenderer::CreateEditorCtrl(wxWindow* parent, wxRect label
     ctrl->input(*data->input);
     ctrl->field_name(data->field);
 
-    // Always use default height for editor controls
-    wxRect rect(labelRect);
-    rect.height = -1;
-
-    ctrl->SetSize(rect);
+    ctrl->SetSize(labelRect);
 
     return ctrl;
 }


This way, textual controls will fit into the cell. But some
controls -- ones that don't look well if they are smaller than their
natural size -- will use slightly larger size and overlap a few
pixels over the cell below. It's not ideal, but the content being
edited is much more important. And it isn't that bad, it is (1) that
is making things so much worse.


Regards,
Vaclav



reply via email to

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