[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lmi] Improved input-sequence editor
From: |
Greg Chicares |
Subject: |
[lmi] Improved input-sequence editor |
Date: |
Fri, 13 May 2016 00:35:28 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0 |
Reference:
https://github.com/vadz/lmi/pull/25/
I've applied these changes locally to test them. The group-quote
redesign will be released soon, and I don't think we should commit
this patchset #25 until after that release, but I'd like to make
some comments now.
Scrollability is a major improvement that I'm sure end users will
welcome; and lmi's UI is sluggish in general, so responsiveness
improvements are wanted.
I've encountered a few behaviors that seem anomalous. Let me write
them down now and then we can postpone the topic until after the
release. When we reopen it, it might be a good idea to commit the
patchset as is, then test it, and only then consider any further
changes.
(1) When I pop up the tabbed input dialog (instead of editing in
the wxDataView census manager directly) and focus an input-sequence
control (without opening the input-sequence editor), the "OK"
pushbutton is highlighted, and I expect that (as previously)
pressing Enter will push "OK". But it does nothing. Instead, I think
Enter really should press "OK".
(2) If I have a really long input sequence (100 or 200 characters)
and I've set "varying" column width, the field is too long to fit
on one screen: I need to scroll rightward to get to the ellipsis
button. I suppose it was that way before this patchset, except that
it was less poignant because there was no ellipsis to scroll to
IIRC. I'm not sure this is really actionable. If we were designing
a full-featured spreadsheet, we might do whatever a spreadsheet
does--e.g., add a separate "edit bar" for the current cell, which
could grow as needed; but I don't think that should be our goal.
In this case, "use fixed width then" may be the optimal answer.
(2)(a) Another observation about case (2): after I close the
sequence editor, I see an apparent layout anomaly. All on one very
long line, I see, from left to right (on a 1920x1200, 192 dpi screen):
- a sunken edit box about 500 pixels wide, containing:
1000000 1; 1100000 2; 1200000 3; 1300000 4; 1400000
- an ellipsis button
- a fragmentary line of text, not sunken:
0 #1; 1500000 6; 1000000 7; [and so on, for about 3500 pixels]
Here, unlike in (2), the ellipsis button is accessible without
scrolling. I'm not sure exactly what series of operations produces
the difference; I'm just trying to write down what I see now and
then move on.
(3) We may want to think more about the tab order. While editing
a sequence with 35 elements, try using the keyboard to navigate
to the button that removes the seventh.
- [lmi] Improved input-sequence editor,
Greg Chicares <=
- Re: [lmi] Improved input-sequence editor, Greg Chicares, 2016/05/12
- Re: [lmi] Improved input-sequence editor, Greg Chicares, 2016/05/27
- Re: [lmi] Improved input-sequence editor, Vadim Zeitlin, 2016/05/28
- [lmi] 72 chars for git log messages [Was: Improved input-sequence editor], Greg Chicares, 2016/05/29
- Re: [lmi] 72 chars for git log messages [Was: Improved input-sequence editor], Greg Chicares, 2016/05/29
- Re: [lmi] 72 chars for git log messages [Was: Improved input-sequence editor], Vadim Zeitlin, 2016/05/29
- Re: [lmi] 72 chars for git log messages [Was: Improved input-sequence editor], Greg Chicares, 2016/05/30
- Re: [lmi] 72 chars for git log messages, Vadim Zeitlin, 2016/05/30
- Re: [lmi] 72 chars for git log messages, Greg Chicares, 2016/05/31
Re: [lmi] Improved input-sequence editor, Greg Chicares, 2016/05/28