- 13 Dec, 2013 12 commits
-
-
Dmitry Timoshkov authored
-
Dmitry Timoshkov authored
-
Dmitry Timoshkov authored
-
Henri Verbeet authored
-
Henri Verbeet authored
-
Henri Verbeet authored
-
Henri Verbeet authored
-
Henri Verbeet authored
-
Frédéric Delanoy authored
-
Michael Stefaniuc authored
-
Ken Thomases authored
This prevents dragging a window's title bar behind a menu bar across the top of a screen, for example.
-
Ken Thomases authored
If the target rect is outside a monitor rect but is between its extremes in one dimension, that dimension should contribute 0 to the distance, rather than some arbitrary amount.
-
- 12 Dec, 2013 28 commits
-
-
Aurimas Fišeras authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Stefan Dösinger authored
-
Stefan Dösinger authored
-
Stefan Dösinger authored
-
Stefan Dösinger authored
-
Frédéric Delanoy authored
-
Alexandre Bique authored
-
Frédéric Delanoy authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Dmitry Timoshkov authored
-
Henri Verbeet authored
-
Henri Verbeet authored
-
Henri Verbeet authored
Tests show this is just wrong. This patch fixes a regression introduced by commit 74e3f516.
-
Henri Verbeet authored
-
Henri Verbeet authored
-
Dmitry Timoshkov authored
-
Andrew Eikum authored
-
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.
-
Ken Thomases authored
winemac: While a window is being dragged, suppress mouse events and disable cursor clipping and warping.
-
Ken Thomases authored
-
Ken Thomases authored
This fixes a problem where some apps move their window to the front after the user switches away to another app. OS X prevents the background app from actually coming in front of the active app's front window, but the window gets ordered in second place, possibly obscuring other windows of the active app.
-
Alexandre Julliard authored
-