|
Notes |
|
|
(0000912)
|
|
dandruczyk
|
2011-12-05 19:26
(edited on: 2011-12-05 19:37) |
|
The tables are a pile of text entries so I'm limited by its functionality, L/R arrows navigate WITHIN the cell to place the cursor in an appropriate place, by using the arrows to switch cells it makes it impossible to edit PART of the text (i.e. change 0.83 to 0.82), I can probably make it jump to the next cell when the cursor is already at the LIMITS of the existing cells, but there's also VI navigation and TAB navigation as well
TAB and Shift+Tab will give you left and right, as well as VI navigation (h==left, j=down, k=up, l = right) which does what you want and doesn't conflict with the arrow keys.
+/q -/w increment/decrement by small amounts, Pgup/Pgdn by large amounts, click then shift+click into other cells grabs cells for group manipulation, i.e. it'll ungrey the box just below the table to allow things like math expression, +,-,/,*.
|
|
|
|
|
|
You probably am not aware of the VI navigation mode.... |
|
|
|
(0000917)
|
|
Fred
|
|
2011-12-06 16:26
|
|
I was aware that there was an alternative, but it's not the natural default that anyone would assume. For example, when I use the letters, I assume an ijkl layout for arrow movement. Both are common enough.
I was thinking about this just now and what I realised is that editing a cell to a specific value is not actually a common operation in the field. What you want to do is move around quickly and inc/dec small/large cells until things run right. Only when fine tuning later would you do that, and even then, you'd want access to the full precision value, not a shrunk for visuals version. So here is what I propose:
- Existing VI scheme plus:
- Arrows for nav (and mouse, of course)
- Something for for small inc/dec (perhaps ctrl up/down (to prevent having to move your hand around) as well as -/= (just checked, you don't use plus, you use the plus _key_))
- Something for large inc/dec (perhaps ctrl -/= and/or ctrl-alt or ctrl-shift up/down, as well as the pg up/down keys?)
- A key binding to enter the group edit mode as well as ctrl click
- A way to select an area of cells rather than one-by-one
- A way to enter edit mode in a cell to allow convenient in-place editing of a single cell to function with natural arrow nav
Please, no flames, yet! :-p Assigning to Ben for comment. |
|
|
|
(0000918)
|
|
Fred
|
|
2011-12-06 16:29
|
|
|
Additional comment, it's fine to have multiple sets of controls that do the same thing in this view of data, provided that they don't overlap and are all complete and reasonable sets. Having stuff that is mouse only is bad considering bumpy in car use and touch pads. |
|
|
|
(0000919)
|
|
BenFenner
|
2011-12-06 17:12
(edited on: 2011-12-06 17:16) |
|
You're correct in assuming my opinions are strong on this. =D
I love TAB and Shift+TAB for move focus one cell to the right and one cell to the left respectively. Good job on that. The analog for up and down is ENTER and Shift+ENTER (both keyboard and pad ENTER). Those should work too if they do not.
Arrow keys IMO should also navigate between cells identical to the TAB and ENTER above.
Moving within a cell should only take place once a cell is active for editing, not just focused/selected. This means a double click on the cell or pressing F2 (Windows) (or Control+U apparently on the Mac?). Once a cell is active for editing, arrow keys traverse the text inside the cell and cannot move focus from that cell until ENTER/TAB is used to move focus to a new cell, or the mouse pointer is clicked on a new cell to move focus there.
This is expected spreadsheet behavior, and IMO expected behavior of any cell-driven software. This is (mostly) how AEM-Tuner behaves as well.
Obviously if you're not editing a cell, and it is merely selected, you can use other shortcuts to fine/coarse adjust the cell value.
|
|
|
|
(0000920)
|
|
Fred
|
|
2011-12-06 17:21
|
|
|
Well articulated, Ben! Good spotting on the enter/shift-enter thing, though I bet dave won't like that as currently enter commits the change, however enter could still do that once in edit mode for a cell is activated, as you so succinctly put it. Glad you agree about the arrow keys. Back to Dave for more deliberation :-) |
|
|
|
(0000921)
|
|
BenFenner
|
2011-12-06 17:32
(edited on: 2011-12-06 17:36) |
|
Moving focus to any other cell (via ENTER/TAB, MouseClick, etc.) should commit the change. This is a small detail not many seem to get right.
The only thing that should void the commit is pressing Esc. Esc should return the value to the previously committed value, exit from cell edit mode, but maintain selection/focus on the cell.
|
|
|
|
(0000922)
|
|
Fred
|
|
2011-12-06 17:36
|
|
|
You mean when editing, right? If incrementing or decrementing clearly it should be sent to volatile device memory immediately. |
|
|
|
|
|
If you're not in edit-mode on a cell, and you're simply incrementing/decrementing with shortcuts, then yes, those changes need to be committed right away (without additional action). |
|
|
|
|
If the text is red (being edited) its NOT sent, changing FOCUS or hitting enter sends it, hitting escape reverts to original value.
small increment is q/w +/-, large increment is pgup/pgdn
so you can navigate and edit all cells with keyboard, q/w for inc/dec, and hjkl for nav.
Will look into issues regarding focus/shift via enter, but it may be hard/impossible to acheive reliably due to enter triggering a different (activate) event, vs a generic key event. |
|
|
|
|
L/R/Up/Down arrows added, however this'll break the ability to move hte cursor WITHIN a cell for the time being (perhaps forever). when it jumps out of the cell it sends the value as well...
in hash: 73607d2ec665227756da331c155d7f8d620a4732 |
|