1. 16 Jul, 2018 1 commit
  2. 14 May, 2018 1 commit
  3. 31 Jul, 2017 1 commit
  4. 21 Jun, 2017 1 commit
  5. 16 May, 2017 2 commits
  6. 24 Apr, 2017 3 commits
  7. 04 Apr, 2017 1 commit
  8. 12 Dec, 2016 1 commit
  9. 02 Dec, 2016 1 commit
  10. 24 Oct, 2016 1 commit
  11. 03 Jun, 2016 1 commit
  12. 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
  13. 05 May, 2016 1 commit
  14. 18 Feb, 2016 1 commit
  15. 01 Dec, 2015 1 commit
  16. 17 Nov, 2015 1 commit
  17. 03 Nov, 2015 1 commit
  18. 29 Oct, 2015 1 commit
  19. 13 Aug, 2015 1 commit
  20. 24 Mar, 2015 1 commit
    • Ken Thomases's avatar
      winemac: Restore a maximized window if a user tries to move it by dragging its title bar. · 792b47ad
      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-movable window from being moved.  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 move a window that's maximized.
      
      To get similar behavior while still respecting Win32 semantics, we detect when
      the user tries to move a maximized window.  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 move.
      
      The user expects to move 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.
      792b47ad
  21. 02 Feb, 2015 3 commits
  22. 30 Jul, 2014 1 commit
  23. 15 May, 2014 1 commit
    • Ken Thomases's avatar
      winemac: Add the ability to disable high-resolution scrolling. · 45191510
      Ken Thomases authored
      The Mac driver can generate scroll wheel events with values which are not integral
      multiples of WHEEL_DELTA.  Apps should handle that by scrolling a corresponding
      non-integral multiple of what they'd do for a WHEEL_DELTA-valued scroll or, if
      they can't, then at least accumulate scroll distance until its magnitude exceeds
      WHEEL_DELTA and do a "chunky" scroll.  However, many apps don't do that properly.
      They may scroll way too far/fast or even in the opposite direction.
      
      If the registry setting UsePreciseScrolling is set to "n", the Mac driver will do
      that accumulation and chunking itself to work around such broken app behavior.
      45191510
  24. 08 May, 2014 1 commit
    • Ken Thomases's avatar
      winemac: Don't bring owned windows to the front when they're clicked. · 3bca22a6
      Ken Thomases authored
      Cocoa will bring an unowned window to the front of its level when it's clicked,
      but it doesn't do that for owned windows.  The old code went out of its way to
      make owned windows behave like unowned windows in this respect.  That was
      exactly backward.  We wish we could control whether windows are raised on a
      click.  We don't have that opportunity for unowned windows, but, by ripping
      out a bunch of code, we do for owned windows.
      3bca22a6
  25. 29 Apr, 2014 1 commit
  26. 29 Jan, 2014 1 commit
  27. 10 Jan, 2014 5 commits
  28. 31 Dec, 2013 2 commits
    • Ken Thomases's avatar
      winemac: More thoroughly discard events which have been obsoleted by subsequent… · 4f9de6bc
      Ken Thomases authored
      winemac: More thoroughly discard events which have been obsoleted by subsequent Wine- or program-driven changes.
      
      Among other things, this fixes Syberia 2.  That game shows, hides, and then
      shows its window.  Hiding it caused a WINDOW_LOST_FOCUS event to be queued.
      By the time it was processed, the window was the foreground window again.
      In response to being told it had lost focus, the game minimized its window.
      
      Hiding the window should have prevented or discarded the WINDOW_LOST_FOCUS
      event since the change was driven from Wine and the Win32 foreground/active
      window state would already be correct.  In addition, when the program
      re-showed its window and made it foreground, that should have discarded the
      event as being out of date.  Now they do.
      4f9de6bc
    • Ken Thomases's avatar
      winemac: Defer adjusting window levels while the process is hidden. · 6447e8e7
      Ken Thomases authored
      While the process is hidden, it can't get a list of its windows which would
      be visible were it not hidden.
      6447e8e7
  29. 17 Dec, 2013 1 commit
  30. 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