1. 21 Jun, 2017 1 commit
  2. 24 Apr, 2017 1 commit
  3. 12 Dec, 2016 1 commit
  4. 24 Oct, 2016 3 commits
  5. 14 May, 2016 1 commit
    • Ken Thomases's avatar
      winemac: Mirror the hierarchy of Win32 child windows with Cocoa views. · d91e5686
      Ken Thomases authored
      This only really affects OpenGL child windows.  GDI rendering to the window
      surface is still only blitted to the window's content view.  The descendant
      views don't draw and so are transparent, letting the content view show through.
      
      Using Cocoa views for child windows fixes a problem where changes to the
      position and visibility of child GL windows didn't properly affect the Cocoa GL
      view.  Hiding, showing, and moving the top-level window affected the Cocoa
      window and thus, indirectly, the GL view.  Moving the child GL window itself
      was propagated to the GL view, so that worked.  But hiding, showing, or moving
      any of the intervening ancestors of the child GL window didn't properly affect
      the GL view.  Neither did hiding or showing the child GL window itself.
      
      This also slightly improves the clipping of the GL view by its ancestors,
      although it still doesn't work quite right due to Cocoa bugs.  There are also
      remaining bugs with z-order among multiple GL views and clipping by overlapping
      siblings.  I hope to eventually fix those using Core Animation layers, for
      which this is a prerequisite.
      Signed-off-by: 's avatarKen Thomases <ken@codeweavers.com>
      Signed-off-by: 's avatarAlexandre Julliard <julliard@winehq.org>
      d91e5686
  6. 06 May, 2016 1 commit
    • Ken Thomases's avatar
      winemac: Add support for a high-resolution ("Retina") rendering mode. · 1c94bf39
      Ken Thomases authored
      When this Retina mode is enabled and the primary display is in the user's
      default configuration, Wine gets told that screen and window sizes and mouse
      coordinates are twice what Cocoa reports them as in its virtual coordinate
      system ("points").  The Windows apps then renders at that high resolution and
      the Mac driver blits it to screen.  If the screen is actually a Retina display
      in a high-DPI mode, then this extra detail will be preserved.  Otherwise, the
      rendering will be downsampled and blurry.
      
      This is intended to be combined with increasing the Windows DPI, as via winecfg.
      If that is doubled to 192, then, in theory, graphical elements will remain the
      same visual size on screen but be rendered with finer detail.  Unfortunately,
      many Windows programs don't correctly handle non-standard DPI so the results
      are not always perfect.
      
      The registry setting to enable Retina mode is:
      
      [HKEY_CURRENT_USER\Software\Wine\Mac Driver]
      "RetinaMode"="y"
      
      Note that this setting is not looked for in the AppDefaults\<exe name> key
      because it doesn't make sense for only some processes in a Wine session to see
      the high-resolution sizes and coordinates.
      Signed-off-by: 's avatarKen Thomases <ken@codeweavers.com>
      Signed-off-by: 's avatarAlexandre Julliard <julliard@winehq.org>
      1c94bf39
  7. 05 Feb, 2016 1 commit
  8. 06 Oct, 2015 1 commit
    • Ken Thomases's avatar
      winemac: Queue an event to reassert the WinAPI window position before Cocoa… · 9372af77
      Ken Thomases authored
      winemac: Queue an event to reassert the WinAPI window position before Cocoa adjusts its position for a display change.
      
      When the display mode changes such that the screen height changes, we'd like
      our windows to keep their position relative to the top-left of the primary
      screen.  That's how WinAPI's coordinate system works and we want the WinAPI
      position of the window to not change just because the display mode changed.
      
      Unfortunately that's not achievable in Cocoa.  Cocoa keeps the window
      stationary relative to the screen it's on, not necessarily the primary screen,
      and it's sometimes relative to the bottom-left and sometimes the top-left of
      that screen.
      
      So, what we do instead is queue an event to get the back end to reassert the
      WinAPI position of the window.  This is queued before Cocoa can adjust the
      Cocoa position of the window which would queue a WINDOW_FRAME_CHANGED to the
      back end and mess up the WinAPI position.  The back end's reassertion of the
      WinAPI position won't be processed by the Cocoa thread until after Cocoa has
      adjusted the position and will thus override it.  It will also discard any
      wrong WINDOW_FRAME_CHANGED that may have been queued.
      Signed-off-by: 's avatarKen Thomases <ken@codeweavers.com>
      9372af77
  9. 05 Jun, 2015 1 commit
  10. 24 Mar, 2015 1 commit
    • Ken Thomases's avatar
      winemac: Allow the user to attempt to resize a maximized window and try to restore it if they do. · 8d581d0e
      Ken Thomases authored
      OS X doesn't have the same concept of maximized windows as Windows does.
      There's no mode that prevents a normally-resizable window from being resized.
      If a window is "zoomed", it mostly fills the screen but the user can still
      move or resize it, at which point it ceases to be in the zoomed state.  So,
      users are confused and frustrated when they can't resize a window that's
      maximized.
      
      To get similar behavior while still respecting Win32 semantics, we now let the
      user try to resize maximized windows.  (The resize cursors are shown at the
      edges of the window frame.)  When they start, a request is submitted to the app
      to restore the window.  Unless and until the window is restored, we don't
      actually allow the window to change its size.
      
      The user expects to resize the window from its current (maximized) position.
      It should not jump to its normal position upon being restored.  So, we set the
      window's normal position to its current position before restoring it.
      8d581d0e
  11. 20 Jan, 2015 1 commit
  12. 24 Apr, 2014 1 commit
  13. 21 Mar, 2014 1 commit
  14. 30 Dec, 2013 1 commit
    • Ken Thomases's avatar
      winemac: Implement support for maximizing windows. · 66736b4a
      Ken Thomases authored
      The user is prevented from moving or resizing a maximized window.  The zoom
      button is still present and enabled for a maximized window but requests that
      it be restored rather than simply resizing it, which is what it does for
      normal windows.
      
      If a window is not resizable (lacks WS_THICKFRAME) but has a maximize box
      (WS_MAXIMIZEBOX), then the zoom button requests that it be maximized rather
      than resizing it.
      66736b4a
  15. 17 Dec, 2013 1 commit
  16. 12 Dec, 2013 1 commit
    • Ken Thomases's avatar
      winemac: Send WM_{ENTER, EXIT}SIZEMOVE before/after window dragging and run an… · f068e329
      Ken Thomases authored
      winemac: Send WM_{ENTER, EXIT}SIZEMOVE before/after window dragging and run an internal event loop during.
      
      This simulates some of what would happen if user32 were managing the drag.  The
      click in the caption would cause WM_SYSCOMMAND/SC_MOVE.  The processing of that
      message is synchronous and doesn't return until the move is complete.
      
      Some games require that "blocking" in the internal event loop to prevent them
      from misbehaving during the drag.
      f068e329
  17. 22 Nov, 2013 1 commit
  18. 20 Nov, 2013 1 commit
  19. 01 Nov, 2013 1 commit
  20. 22 Oct, 2013 2 commits
  21. 21 Oct, 2013 1 commit
  22. 11 Oct, 2013 1 commit
  23. 08 Oct, 2013 3 commits
  24. 30 Sep, 2013 1 commit
  25. 27 Sep, 2013 2 commits
  26. 18 Sep, 2013 2 commits
  27. 06 Sep, 2013 1 commit
  28. 21 Aug, 2013 1 commit
  29. 09 Jul, 2013 1 commit
  30. 02 Jul, 2013 2 commits
  31. 20 Jun, 2013 1 commit
  32. 04 Jun, 2013 1 commit