1. 20 Jan, 2003 1 commit
  2. 19 Jan, 2003 1 commit
  3. 27 Dec, 2002 1 commit
    • Ryan C. Gordon's avatar
      Massive Quartz input enhancements from Darrell Walisser. His email: · f39381e3
      Ryan C. Gordon authored
      Enclosed is a patch that addresses the following:
      
      --Various minor cleanups.
      Removed dead/obsolete code, made some style cleanups
      
      --Mouse Events
      Now keep track of what button(s) were pressed so we know when to send
      the mouse up event. This fixes the case where the mouse is dragged
      outside of the game window and released (in which case we want to send
      the mouse up event even though the mouse is outside the game window).
      
      --Input Grabbing
      Here is my take on the grabbing situation, which is the basis for the
      new implementation.
      
      There are 3 grab states, ungrabbed (UG), visible (VG), and invisible
      (IG). Both VG and IG keep the mouse constrained to the window and
      produce relative motion events. In VG the cursor is visible (duh), in
      IG it is not. In VG, absolute motion events also work.
      
      There are 6 actions that can affect grabbing:
      
      1. Set Fullscreen/Window (F/W). In fullscreen, a visible grab should do
      nothing. However, a fullscreen visible grab can be treated just like a
      windowed visible grab, which is what I have done to help simplify
      things.
      
      2. Cursor hide/show (H/S). If the cursor is hidden when grabbing, the
      grab is an invisible grab. If the cursor is visible, the grab should
      just constrain the mouse to the window.
      
      3. Input grab/ungrab(G/U). If grabbed, the cursor should be confined to
      the window as should the keyboard input. On Mac OS X, the keyboard
      input is implicitly grabbed by confining the cursor, except for
      command-tab which can switch away from the application. Should the
      window come to the foreground if the application is deactivated and
      grab input is called? This isn't necessary in this implementation
      because the grab state will be asserted upon activation.
      
      Using my notation, these are all the cases that need to be handled
      (state + action = new state).
      
      UG+U = UG
      UG+G = VG or IG, if cursor is visible or not
      UG+H = UG
      UG+S = UG
      
      VG+U = UG
      VG+G = VG
      VG+H = IG
      VG+S = VG
      
      IG+U = UG
      IG+G = IG
      IG+H = IG
      IG+S = VG
      
      The cases that result in the same state can be ignored in the code,
      which cuts it down to just 5 cases.
      
      Another issue is what happens when the app loses/gains input focus from
      deactivate/activate or iconify/deiconify. I think that if input focus
      is ever lost (outside of SDL's control), the grab state should be
      suspended and the cursor should become visible and active again. When
      regained, the cursor should reappear in its original location and/or
      grab state. This way, when reactivating the cursor is still in the same
      position as before so apps shouldn't get confused when the next motion
      event comes in. This is what I've done in this patch.
      
      --HG--
      extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%40564
      f39381e3
  4. 20 Dec, 2002 1 commit
  5. 15 Dec, 2002 1 commit
    • Sam Lantinga's avatar
      Date: Sat, 14 Dec 2002 13:33:05 -0500 · 8e0540e5
      Sam Lantinga authored
      From: Darrell Walisser
      Subject: Re: crash in SDL / OSX
      
      > Yes, compose keys and other "dead" keys should have unicode 0.
      > As a hack, if you get multiple composed characters, you can send the
      > sequence with a valid unicode and a keysym of 0.  It's because of
      > things like this that I'm separating the key and char events in SDL 2.0
      
      I've done this and here's the patch.
      
      --HG--
      extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%40562
      8e0540e5
  6. 13 Dec, 2002 1 commit
  7. 11 Dec, 2002 2 commits
  8. 07 Dec, 2002 3 commits
  9. 02 Dec, 2002 5 commits
  10. 24 Nov, 2002 1 commit
  11. 17 Nov, 2002 8 commits
  12. 09 Nov, 2002 5 commits
  13. 22 Oct, 2002 2 commits
  14. 20 Oct, 2002 1 commit
  15. 15 Oct, 2002 2 commits
  16. 14 Oct, 2002 1 commit
  17. 11 Oct, 2002 4 commits