<div dir="ltr"><div>Followup to some email:<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Instead of using shift or Keypad0, why not use Num_Lock?<br clear="none"><br clear="none">This would be like: using the Num_Lock key to toggle between behavior<br clear="none">1 and behavior 2?<br clear="none"><br clear="none"><br clear="none">My first thought was about somehow using the other (unused) keys on<br clear="none">the keypad for the behavior 2, but mainly because of the special<br clear="none">behavior of the Num_Lock key this might cause more difficulties than<br clear="none">it solves problems.</blockquote><div><br>Sorry for the delay in the response, but I really did look around to see what was possible and would probably work best.  Here is what I found:<br><br>XKeyEvents have a "Key masks" used as modifier bits,<br><br>        ctrl_mask = (key_state & ControlMask) ? 1 : 0;  // ctrl key down<br>        shift_mask = (key_state & ShiftMask) ? 1 : 0;   // shift key down<br>        alt_mask = (key_state & Mod1Mask) ? 1 : 0;      // alt key down<br><br>While it is true that you can access the num-lock state with XQueryPointer, the num-lock state affects the way the numeric pad is interpreted by other applications which may be also in use at the same time.  That is not very convenient...  It also depends on the keyboard mapping which may be quite variable... Some small keyboards may not have num-lock, and the light may or<br>may not be present.  All in all, not my first choice.<br><br>The XKeyEvent masks are always there, and have a long term historical basis, so are likely to work on all X implementations using shift.  On all of my systems<br>there is a shift key near the the numeric pad anyway - my laptop has it just as close as the 0 key while the desktop has only a single column between so it is still easy enough to reach with the right hand.   You can also just use your left hand to use the Shift key on the other side of the keyboard.<br><br>Yea,...  anyway... KP4 is now correctly working with the Shift key plus you can, for example, now switch from KP4 to Shift-KP4 without stopping first.  This has been checked into the Git repository.  Give it a try and let us know what you think.<br> </div><div>Pierre quote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The only inconvenience that I currently see, is when I want to
      change
      <br clear="none">
      the playback speed without interruption while it's already
      playing.
      <br clear="none"></blockquote>
      <br>Frederic quote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><span class="gmail-yiv1657067947" id="gmail-yiv1657067947result_box" lang="en"><span class="gmail-yiv1657067947" id="gmail-yui_3_16_0_ym19_1_1502230440395_6891">but maybe it would be possible that when one of
          these keys in combination with shift or Keypad0 would be used
          to activate the playback, without it being</span> <span class="gmail-yiv1657067947" id="gmail-yui_3_16_0_ym19_1_1502230440395_6890">Stopped...</span></span><br></div></blockquote><div><br></div><div>You don't have to worry about blinking and missing anything any more.  For example, press KP3 for playing normal forward, <b>don't press KP3 to stop</b>, just press KP2 to reverse or whatever you want to do next.  It does not miss any frames.  This should work for all of the keys along with the new Shift keys so you can go from KP1 to Shift-KP1 and miss nothing, but now get sound.<br><br></div><div>gg<br></div></div>