Recognizing that CTRL-SHIFT have come up together

[rmkaplan]

Original question from @rmkaplan:

I’m having trouble in Tedit in recognizing that the CTRL-SHIFT had been down when the user releases the keys. It’s in a polling loop decoding the key combinations into MOVE (both down), COPY (shift only), DELETE (CTRL only).

The problem (I think) is that the user doesn’t actually release the keys simultaneously, it goes around the loop between the time that one key has come up but the other hasn’t. So an intended MOVE gets seen as either a COPY or a DELETE. And if the mouse is also up at that time, the action is executed.

But that kind of transition is also generally allowed—you can change your mind in the middle, say by adding a CTRL to a SHIFT to go from a delete to a move or vice versa (as long as something stays down when you fiddle). And you can do this whether the mouse buttons are up or down, if you want to move to a new location with the same operation.

Is there an established way of recognizing CTRL-SHIFT coming up (or going down) as an atomic event? Putting in some sort of explicit timing delay before it goes around the loop again?

[rmkaplan]

From @nbriggs:
I don’t know of one, but I’m away from home until Sunday so it’s not easy to look at the code. It may be that our speed is not helping us here. Is there code in sketch that has dealt with the same issue?

[rmkaplan]

From @rmkaplan:
I looked at Sedit, and it seems to have the same key decoding as Tedit. I haven’t yet tried to decipher Sketch.

My current thought is that if both keys were down the last time around the polling loop, and now one of them is up but one is down, then wait a bit (50 msec?) and check again to see if they are now both up.

So far seems to work. But I’m still open to better ideas.

[rmkaplan]

From @rmkaplan:
Here is what I now have, for deciding what the Tedit operation is. A better way?

(LAMBDA (READONLY CUROPERATION)
"Look at the mode keys to figure out the new operation."
"In a read-only document you cannot move or delete. Selection is NORMAL if no keys are down. "

  (PROG NIL
              (CL:WHEN (AND (EQ 'MOVE CUROPERATION) (NEQ (SHIFTDOWNP ‘SHIFT) (SHIFTDOWNP 'CTRL)))              
                                     "If both were down (MOVE) and now they're in different states, wait a bit to see if they both come up"
                          (DISMISS 50 NIL T)
                          (CL:UNLESS (OR (SHIFTDOWNP ‘SHIFT) (SHIFTDOWNP 'CTRL))   "Normal if both now up, otherwise fall through"
                                 (RETURN 'NORMAL)))

              (RETURN (if (AND (SHIFTDOWNP ‘CTRL) (NOT READONLY))
                                  then  (if (SHIFTDOWNP 'SHIFT) then 'MOVE else 'DELETE)
                                elseif (OR (SHIFTDOWNP ‘SHIFT) (KEYDOWNP 'COPY))
                                   then  ‘COPY
                                elseif (SHIFTDOWNP 'META)
                                  then  ‘COPYLOOKS
                                else   'NORMAL))))  "No keys down”

[masinter]

It might be helpful to make a state transition diagram and include the visual feedback as well as when effects actually happen. Here's a strawman for constraints:

• show visual feedback as soon as possible; should show what WILL happen when mouse is released (down->up)
• effects only happen after mouse down -> up
• when you release mouse, you want to wait until the user has the time to see the visual feedback and react (> 250 ms)
• if the state of shift keys change, timers are reset