2010-05-25 22:38:44 +00:00
|
|
|
/* GDK - The GIMP Drawing Kit
|
|
|
|
* Copyright (C) 2009 Carlos Garnacho <carlosg@gnome.org>
|
|
|
|
*
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2 of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
2012-02-27 13:01:10 +00:00
|
|
|
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
|
2010-05-25 22:38:44 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include "config.h"
|
|
|
|
|
|
|
|
#include <gdk/gdkwindow.h>
|
|
|
|
|
|
|
|
#include <windowsx.h>
|
|
|
|
#include <objbase.h>
|
|
|
|
|
2011-01-02 10:51:25 +00:00
|
|
|
#include "gdkdisplayprivate.h"
|
2010-05-25 22:38:44 +00:00
|
|
|
#include "gdkdevice-win32.h"
|
|
|
|
#include "gdkwin32.h"
|
|
|
|
|
|
|
|
G_DEFINE_TYPE (GdkDeviceWin32, gdk_device_win32, GDK_TYPE_DEVICE)
|
|
|
|
|
|
|
|
static gboolean
|
|
|
|
gdk_device_win32_get_history (GdkDevice *device,
|
|
|
|
GdkWindow *window,
|
|
|
|
guint32 start,
|
|
|
|
guint32 stop,
|
|
|
|
GdkTimeCoord ***events,
|
2010-10-19 11:30:42 +00:00
|
|
|
gint *n_events)
|
2010-05-25 22:38:44 +00:00
|
|
|
{
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gdk_device_win32_get_state (GdkDevice *device,
|
|
|
|
GdkWindow *window,
|
|
|
|
gdouble *axes,
|
|
|
|
GdkModifierType *mask)
|
|
|
|
{
|
|
|
|
gint x_int, y_int;
|
|
|
|
|
2013-07-30 03:06:57 +00:00
|
|
|
gdk_window_get_device_position (window, device, &x_int, &y_int, mask);
|
2010-05-25 22:38:44 +00:00
|
|
|
|
|
|
|
if (axes)
|
|
|
|
{
|
|
|
|
axes[0] = x_int;
|
|
|
|
axes[1] = y_int;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gdk_device_win32_set_window_cursor (GdkDevice *device,
|
|
|
|
GdkWindow *window,
|
|
|
|
GdkCursor *cursor)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gdk_device_win32_warp (GdkDevice *device,
|
|
|
|
GdkScreen *screen,
|
2013-07-03 09:52:58 +00:00
|
|
|
gdouble x,
|
|
|
|
gdouble y)
|
2010-05-25 22:38:44 +00:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
static GdkModifierType
|
|
|
|
get_current_mask (void)
|
|
|
|
{
|
|
|
|
GdkModifierType mask;
|
|
|
|
BYTE kbd[256];
|
|
|
|
|
|
|
|
GetKeyboardState (kbd);
|
|
|
|
mask = 0;
|
|
|
|
if (kbd[VK_SHIFT] & 0x80)
|
|
|
|
mask |= GDK_SHIFT_MASK;
|
|
|
|
if (kbd[VK_CAPITAL] & 0x80)
|
|
|
|
mask |= GDK_LOCK_MASK;
|
|
|
|
if (kbd[VK_CONTROL] & 0x80)
|
|
|
|
mask |= GDK_CONTROL_MASK;
|
|
|
|
if (kbd[VK_MENU] & 0x80)
|
|
|
|
mask |= GDK_MOD1_MASK;
|
|
|
|
if (kbd[VK_LBUTTON] & 0x80)
|
|
|
|
mask |= GDK_BUTTON1_MASK;
|
|
|
|
if (kbd[VK_MBUTTON] & 0x80)
|
|
|
|
mask |= GDK_BUTTON2_MASK;
|
|
|
|
if (kbd[VK_RBUTTON] & 0x80)
|
|
|
|
mask |= GDK_BUTTON3_MASK;
|
|
|
|
|
|
|
|
return mask;
|
|
|
|
}
|
|
|
|
|
2012-03-09 12:20:41 +00:00
|
|
|
static void
|
2010-05-25 22:38:44 +00:00
|
|
|
gdk_device_win32_query_state (GdkDevice *device,
|
|
|
|
GdkWindow *window,
|
|
|
|
GdkWindow **root_window,
|
|
|
|
GdkWindow **child_window,
|
2013-07-03 09:52:58 +00:00
|
|
|
gdouble *root_x,
|
|
|
|
gdouble *root_y,
|
|
|
|
gdouble *win_x,
|
|
|
|
gdouble *win_y,
|
2010-05-25 22:38:44 +00:00
|
|
|
GdkModifierType *mask)
|
|
|
|
{
|
2015-12-17 23:36:57 +00:00
|
|
|
GdkScreen *screen;
|
2010-05-25 22:38:44 +00:00
|
|
|
POINT point;
|
|
|
|
HWND hwnd, hwndc;
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
GdkWindowImplWin32 *impl;
|
2010-05-25 22:38:44 +00:00
|
|
|
|
2015-12-17 23:36:57 +00:00
|
|
|
screen = gdk_window_get_screen (window);
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
impl = GDK_WINDOW_IMPL_WIN32 (window->impl);
|
2015-12-17 23:36:57 +00:00
|
|
|
|
2010-05-25 22:38:44 +00:00
|
|
|
hwnd = GDK_WINDOW_HWND (window);
|
|
|
|
GetCursorPos (&point);
|
|
|
|
|
|
|
|
if (root_x)
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
*root_x = point.x / impl->window_scale;
|
2010-05-25 22:38:44 +00:00
|
|
|
|
|
|
|
if (root_y)
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
*root_y = point.y / impl->window_scale;
|
2010-05-25 22:38:44 +00:00
|
|
|
|
|
|
|
ScreenToClient (hwnd, &point);
|
|
|
|
|
|
|
|
if (win_x)
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
*win_x = point.x / impl->window_scale;
|
2010-05-25 22:38:44 +00:00
|
|
|
|
|
|
|
if (win_y)
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
*win_y = point.y / impl->window_scale;
|
2010-05-25 22:38:44 +00:00
|
|
|
|
2015-12-17 23:36:57 +00:00
|
|
|
if (window == gdk_screen_get_root_window (screen))
|
2010-05-25 22:38:44 +00:00
|
|
|
{
|
|
|
|
if (win_x)
|
|
|
|
*win_x += _gdk_offset_x;
|
|
|
|
|
|
|
|
if (win_y)
|
|
|
|
*win_y += _gdk_offset_y;
|
2015-04-29 07:31:08 +00:00
|
|
|
|
2013-11-01 16:59:05 +00:00
|
|
|
if (root_x)
|
|
|
|
*root_x += _gdk_offset_x;
|
|
|
|
|
|
|
|
if (root_y)
|
|
|
|
*root_y += _gdk_offset_y;
|
2010-05-25 22:38:44 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (child_window)
|
|
|
|
{
|
|
|
|
hwndc = ChildWindowFromPoint (hwnd, point);
|
|
|
|
|
|
|
|
if (hwndc && hwndc != hwnd)
|
2011-02-06 14:03:32 +00:00
|
|
|
*child_window = gdk_win32_handle_table_lookup (hwndc);
|
2010-05-25 22:38:44 +00:00
|
|
|
else
|
|
|
|
*child_window = NULL; /* Direct child unknown to gdk */
|
|
|
|
}
|
|
|
|
|
|
|
|
if (root_window)
|
2015-12-17 23:36:57 +00:00
|
|
|
*root_window = gdk_screen_get_root_window (screen);
|
2010-05-25 22:38:44 +00:00
|
|
|
|
|
|
|
if (mask)
|
|
|
|
*mask = get_current_mask ();
|
|
|
|
}
|
|
|
|
|
|
|
|
static GdkGrabStatus
|
|
|
|
gdk_device_win32_grab (GdkDevice *device,
|
|
|
|
GdkWindow *window,
|
|
|
|
gboolean owner_events,
|
|
|
|
GdkEventMask event_mask,
|
|
|
|
GdkWindow *confine_to,
|
|
|
|
GdkCursor *cursor,
|
|
|
|
guint32 time_)
|
|
|
|
{
|
2012-03-30 12:59:17 +00:00
|
|
|
/* No support for grabbing the slave atm */
|
|
|
|
return GDK_GRAB_NOT_VIEWABLE;
|
2010-05-25 22:38:44 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gdk_device_win32_ungrab (GdkDevice *device,
|
|
|
|
guint32 time_)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
Win32: Fix _gdk_windowing_window_at_pointer to correctly return a toplevel
Commit 5ebb32d1ffa23241d562fb4d5be02bc6f156b515 didn't add the correct
code to find the toplevel window. The WindowFromPoint() function does
not return the toplevel window in the hierarchy, it returns the deepest
non-disabled, non-invisible child. As we don't use invisible or disabled
windows, we don't actually need to use the ChildWindowFromPoint walk for
the non get_toplevel case, so we can remove that code path.
To find a toplevel, we need to start from the desktop and work up, using
ChildWindowFromPointEx (to ignore invisible and disabled windows). If we
don't ignore invisible and disabled windows (as is the case with the
ChildWindowFromPoint call, we are liable to get returns of hidden or
disabled children of the desktop which don't belong to us, but notionally
occupy the same area under the pointer.
An alternative might be to start our walk with one of the children of the
desktop owned by our process and thread - which we can enumerate using,
the EnumThreadWindows call, or (presumably) determine internally. This
would not work when we are inside a GtkSocket though, as the children of
the desktop would belong to the process owning the GtkPlug - we would
have to rely on our own list of windows.
For correctness, this commit adds tests to ensure that we don't try to
return either x or y window coordinates if that corresponding pointer is
NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=658842
2011-09-10 15:30:56 +00:00
|
|
|
static void
|
|
|
|
screen_to_client (HWND hwnd, POINT screen_pt, POINT *client_pt)
|
|
|
|
{
|
|
|
|
*client_pt = screen_pt;
|
|
|
|
ScreenToClient (hwnd, client_pt);
|
|
|
|
}
|
|
|
|
|
2015-12-19 09:31:32 +00:00
|
|
|
GdkWindow *
|
|
|
|
_gdk_device_win32_window_at_position (GdkDevice *device,
|
|
|
|
gdouble *win_x,
|
|
|
|
gdouble *win_y,
|
|
|
|
GdkModifierType *mask,
|
|
|
|
gboolean get_toplevel)
|
2010-05-25 22:38:44 +00:00
|
|
|
{
|
Win32: Fix _gdk_windowing_window_at_pointer to correctly return a toplevel
Commit 5ebb32d1ffa23241d562fb4d5be02bc6f156b515 didn't add the correct
code to find the toplevel window. The WindowFromPoint() function does
not return the toplevel window in the hierarchy, it returns the deepest
non-disabled, non-invisible child. As we don't use invisible or disabled
windows, we don't actually need to use the ChildWindowFromPoint walk for
the non get_toplevel case, so we can remove that code path.
To find a toplevel, we need to start from the desktop and work up, using
ChildWindowFromPointEx (to ignore invisible and disabled windows). If we
don't ignore invisible and disabled windows (as is the case with the
ChildWindowFromPoint call, we are liable to get returns of hidden or
disabled children of the desktop which don't belong to us, but notionally
occupy the same area under the pointer.
An alternative might be to start our walk with one of the children of the
desktop owned by our process and thread - which we can enumerate using,
the EnumThreadWindows call, or (presumably) determine internally. This
would not work when we are inside a GtkSocket though, as the children of
the desktop would belong to the process owning the GtkPlug - we would
have to rely on our own list of windows.
For correctness, this commit adds tests to ensure that we don't try to
return either x or y window coordinates if that corresponding pointer is
NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=658842
2011-09-10 15:30:56 +00:00
|
|
|
GdkWindow *window = NULL;
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
GdkWindowImplWin32 *impl = NULL;
|
Win32: Fix _gdk_windowing_window_at_pointer to correctly return a toplevel
Commit 5ebb32d1ffa23241d562fb4d5be02bc6f156b515 didn't add the correct
code to find the toplevel window. The WindowFromPoint() function does
not return the toplevel window in the hierarchy, it returns the deepest
non-disabled, non-invisible child. As we don't use invisible or disabled
windows, we don't actually need to use the ChildWindowFromPoint walk for
the non get_toplevel case, so we can remove that code path.
To find a toplevel, we need to start from the desktop and work up, using
ChildWindowFromPointEx (to ignore invisible and disabled windows). If we
don't ignore invisible and disabled windows (as is the case with the
ChildWindowFromPoint call, we are liable to get returns of hidden or
disabled children of the desktop which don't belong to us, but notionally
occupy the same area under the pointer.
An alternative might be to start our walk with one of the children of the
desktop owned by our process and thread - which we can enumerate using,
the EnumThreadWindows call, or (presumably) determine internally. This
would not work when we are inside a GtkSocket though, as the children of
the desktop would belong to the process owning the GtkPlug - we would
have to rely on our own list of windows.
For correctness, this commit adds tests to ensure that we don't try to
return either x or y window coordinates if that corresponding pointer is
NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=658842
2011-09-10 15:30:56 +00:00
|
|
|
POINT screen_pt, client_pt;
|
2010-05-25 22:38:44 +00:00
|
|
|
HWND hwnd, hwndc;
|
|
|
|
RECT rect;
|
|
|
|
|
Win32: Fix _gdk_windowing_window_at_pointer to correctly return a toplevel
Commit 5ebb32d1ffa23241d562fb4d5be02bc6f156b515 didn't add the correct
code to find the toplevel window. The WindowFromPoint() function does
not return the toplevel window in the hierarchy, it returns the deepest
non-disabled, non-invisible child. As we don't use invisible or disabled
windows, we don't actually need to use the ChildWindowFromPoint walk for
the non get_toplevel case, so we can remove that code path.
To find a toplevel, we need to start from the desktop and work up, using
ChildWindowFromPointEx (to ignore invisible and disabled windows). If we
don't ignore invisible and disabled windows (as is the case with the
ChildWindowFromPoint call, we are liable to get returns of hidden or
disabled children of the desktop which don't belong to us, but notionally
occupy the same area under the pointer.
An alternative might be to start our walk with one of the children of the
desktop owned by our process and thread - which we can enumerate using,
the EnumThreadWindows call, or (presumably) determine internally. This
would not work when we are inside a GtkSocket though, as the children of
the desktop would belong to the process owning the GtkPlug - we would
have to rely on our own list of windows.
For correctness, this commit adds tests to ensure that we don't try to
return either x or y window coordinates if that corresponding pointer is
NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=658842
2011-09-10 15:30:56 +00:00
|
|
|
GetCursorPos (&screen_pt);
|
2010-05-25 22:38:44 +00:00
|
|
|
|
Win32: Fix _gdk_windowing_window_at_pointer to correctly return a toplevel
Commit 5ebb32d1ffa23241d562fb4d5be02bc6f156b515 didn't add the correct
code to find the toplevel window. The WindowFromPoint() function does
not return the toplevel window in the hierarchy, it returns the deepest
non-disabled, non-invisible child. As we don't use invisible or disabled
windows, we don't actually need to use the ChildWindowFromPoint walk for
the non get_toplevel case, so we can remove that code path.
To find a toplevel, we need to start from the desktop and work up, using
ChildWindowFromPointEx (to ignore invisible and disabled windows). If we
don't ignore invisible and disabled windows (as is the case with the
ChildWindowFromPoint call, we are liable to get returns of hidden or
disabled children of the desktop which don't belong to us, but notionally
occupy the same area under the pointer.
An alternative might be to start our walk with one of the children of the
desktop owned by our process and thread - which we can enumerate using,
the EnumThreadWindows call, or (presumably) determine internally. This
would not work when we are inside a GtkSocket though, as the children of
the desktop would belong to the process owning the GtkPlug - we would
have to rely on our own list of windows.
For correctness, this commit adds tests to ensure that we don't try to
return either x or y window coordinates if that corresponding pointer is
NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=658842
2011-09-10 15:30:56 +00:00
|
|
|
if (get_toplevel)
|
2010-05-25 22:38:44 +00:00
|
|
|
{
|
Win32: Fix _gdk_windowing_window_at_pointer to correctly return a toplevel
Commit 5ebb32d1ffa23241d562fb4d5be02bc6f156b515 didn't add the correct
code to find the toplevel window. The WindowFromPoint() function does
not return the toplevel window in the hierarchy, it returns the deepest
non-disabled, non-invisible child. As we don't use invisible or disabled
windows, we don't actually need to use the ChildWindowFromPoint walk for
the non get_toplevel case, so we can remove that code path.
To find a toplevel, we need to start from the desktop and work up, using
ChildWindowFromPointEx (to ignore invisible and disabled windows). If we
don't ignore invisible and disabled windows (as is the case with the
ChildWindowFromPoint call, we are liable to get returns of hidden or
disabled children of the desktop which don't belong to us, but notionally
occupy the same area under the pointer.
An alternative might be to start our walk with one of the children of the
desktop owned by our process and thread - which we can enumerate using,
the EnumThreadWindows call, or (presumably) determine internally. This
would not work when we are inside a GtkSocket though, as the children of
the desktop would belong to the process owning the GtkPlug - we would
have to rely on our own list of windows.
For correctness, this commit adds tests to ensure that we don't try to
return either x or y window coordinates if that corresponding pointer is
NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=658842
2011-09-10 15:30:56 +00:00
|
|
|
/* Only consider visible children of the desktop to avoid the various
|
|
|
|
* non-visible windows you often find on a running Windows box. These
|
|
|
|
* might overlap our windows and cause our walk to fail. As we assume
|
|
|
|
* WindowFromPoint() can find our windows, we follow similar logic
|
|
|
|
* here, and ignore invisible and disabled windows.
|
|
|
|
*/
|
|
|
|
hwnd = GetDesktopWindow ();
|
|
|
|
do {
|
|
|
|
window = gdk_win32_handle_table_lookup (hwnd);
|
|
|
|
|
|
|
|
if (window != NULL &&
|
|
|
|
GDK_WINDOW_TYPE (window) != GDK_WINDOW_ROOT &&
|
|
|
|
GDK_WINDOW_TYPE (window) != GDK_WINDOW_FOREIGN)
|
|
|
|
break;
|
|
|
|
|
|
|
|
screen_to_client (hwnd, screen_pt, &client_pt);
|
|
|
|
hwndc = ChildWindowFromPointEx (hwnd, client_pt, CWP_SKIPDISABLED |
|
|
|
|
CWP_SKIPINVISIBLE);
|
2011-10-19 14:15:17 +00:00
|
|
|
|
|
|
|
/* Verify that we're really inside the client area of the window */
|
|
|
|
if (hwndc != hwnd)
|
|
|
|
{
|
|
|
|
GetClientRect (hwndc, &rect);
|
|
|
|
screen_to_client (hwndc, screen_pt, &client_pt);
|
|
|
|
if (!PtInRect (&rect, client_pt))
|
|
|
|
hwndc = hwnd;
|
|
|
|
}
|
|
|
|
|
Win32: Fix _gdk_windowing_window_at_pointer to correctly return a toplevel
Commit 5ebb32d1ffa23241d562fb4d5be02bc6f156b515 didn't add the correct
code to find the toplevel window. The WindowFromPoint() function does
not return the toplevel window in the hierarchy, it returns the deepest
non-disabled, non-invisible child. As we don't use invisible or disabled
windows, we don't actually need to use the ChildWindowFromPoint walk for
the non get_toplevel case, so we can remove that code path.
To find a toplevel, we need to start from the desktop and work up, using
ChildWindowFromPointEx (to ignore invisible and disabled windows). If we
don't ignore invisible and disabled windows (as is the case with the
ChildWindowFromPoint call, we are liable to get returns of hidden or
disabled children of the desktop which don't belong to us, but notionally
occupy the same area under the pointer.
An alternative might be to start our walk with one of the children of the
desktop owned by our process and thread - which we can enumerate using,
the EnumThreadWindows call, or (presumably) determine internally. This
would not work when we are inside a GtkSocket though, as the children of
the desktop would belong to the process owning the GtkPlug - we would
have to rely on our own list of windows.
For correctness, this commit adds tests to ensure that we don't try to
return either x or y window coordinates if that corresponding pointer is
NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=658842
2011-09-10 15:30:56 +00:00
|
|
|
} while (hwndc != hwnd && (hwnd = hwndc, 1));
|
2010-05-25 22:38:44 +00:00
|
|
|
|
Win32: Fix _gdk_windowing_window_at_pointer to correctly return a toplevel
Commit 5ebb32d1ffa23241d562fb4d5be02bc6f156b515 didn't add the correct
code to find the toplevel window. The WindowFromPoint() function does
not return the toplevel window in the hierarchy, it returns the deepest
non-disabled, non-invisible child. As we don't use invisible or disabled
windows, we don't actually need to use the ChildWindowFromPoint walk for
the non get_toplevel case, so we can remove that code path.
To find a toplevel, we need to start from the desktop and work up, using
ChildWindowFromPointEx (to ignore invisible and disabled windows). If we
don't ignore invisible and disabled windows (as is the case with the
ChildWindowFromPoint call, we are liable to get returns of hidden or
disabled children of the desktop which don't belong to us, but notionally
occupy the same area under the pointer.
An alternative might be to start our walk with one of the children of the
desktop owned by our process and thread - which we can enumerate using,
the EnumThreadWindows call, or (presumably) determine internally. This
would not work when we are inside a GtkSocket though, as the children of
the desktop would belong to the process owning the GtkPlug - we would
have to rely on our own list of windows.
For correctness, this commit adds tests to ensure that we don't try to
return either x or y window coordinates if that corresponding pointer is
NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=658842
2011-09-10 15:30:56 +00:00
|
|
|
}
|
|
|
|
else
|
2010-05-25 22:38:44 +00:00
|
|
|
{
|
Win32: Fix _gdk_windowing_window_at_pointer to correctly return a toplevel
Commit 5ebb32d1ffa23241d562fb4d5be02bc6f156b515 didn't add the correct
code to find the toplevel window. The WindowFromPoint() function does
not return the toplevel window in the hierarchy, it returns the deepest
non-disabled, non-invisible child. As we don't use invisible or disabled
windows, we don't actually need to use the ChildWindowFromPoint walk for
the non get_toplevel case, so we can remove that code path.
To find a toplevel, we need to start from the desktop and work up, using
ChildWindowFromPointEx (to ignore invisible and disabled windows). If we
don't ignore invisible and disabled windows (as is the case with the
ChildWindowFromPoint call, we are liable to get returns of hidden or
disabled children of the desktop which don't belong to us, but notionally
occupy the same area under the pointer.
An alternative might be to start our walk with one of the children of the
desktop owned by our process and thread - which we can enumerate using,
the EnumThreadWindows call, or (presumably) determine internally. This
would not work when we are inside a GtkSocket though, as the children of
the desktop would belong to the process owning the GtkPlug - we would
have to rely on our own list of windows.
For correctness, this commit adds tests to ensure that we don't try to
return either x or y window coordinates if that corresponding pointer is
NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=658842
2011-09-10 15:30:56 +00:00
|
|
|
hwnd = WindowFromPoint (screen_pt);
|
2010-05-25 22:38:44 +00:00
|
|
|
|
2011-10-19 14:15:17 +00:00
|
|
|
/* Verify that we're really inside the client area of the window */
|
|
|
|
GetClientRect (hwnd, &rect);
|
|
|
|
screen_to_client (hwnd, screen_pt, &client_pt);
|
|
|
|
if (!PtInRect (&rect, client_pt))
|
|
|
|
hwnd = NULL;
|
|
|
|
|
Win32: Fix _gdk_windowing_window_at_pointer to correctly return a toplevel
Commit 5ebb32d1ffa23241d562fb4d5be02bc6f156b515 didn't add the correct
code to find the toplevel window. The WindowFromPoint() function does
not return the toplevel window in the hierarchy, it returns the deepest
non-disabled, non-invisible child. As we don't use invisible or disabled
windows, we don't actually need to use the ChildWindowFromPoint walk for
the non get_toplevel case, so we can remove that code path.
To find a toplevel, we need to start from the desktop and work up, using
ChildWindowFromPointEx (to ignore invisible and disabled windows). If we
don't ignore invisible and disabled windows (as is the case with the
ChildWindowFromPoint call, we are liable to get returns of hidden or
disabled children of the desktop which don't belong to us, but notionally
occupy the same area under the pointer.
An alternative might be to start our walk with one of the children of the
desktop owned by our process and thread - which we can enumerate using,
the EnumThreadWindows call, or (presumably) determine internally. This
would not work when we are inside a GtkSocket though, as the children of
the desktop would belong to the process owning the GtkPlug - we would
have to rely on our own list of windows.
For correctness, this commit adds tests to ensure that we don't try to
return either x or y window coordinates if that corresponding pointer is
NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=658842
2011-09-10 15:30:56 +00:00
|
|
|
/* If we didn't hit any window at that point, return the desktop */
|
|
|
|
if (hwnd == NULL)
|
|
|
|
{
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
window = gdk_get_default_root_window ();
|
|
|
|
impl = GDK_WINDOW_IMPL_WIN32 (window->impl);
|
|
|
|
|
Win32: Fix _gdk_windowing_window_at_pointer to correctly return a toplevel
Commit 5ebb32d1ffa23241d562fb4d5be02bc6f156b515 didn't add the correct
code to find the toplevel window. The WindowFromPoint() function does
not return the toplevel window in the hierarchy, it returns the deepest
non-disabled, non-invisible child. As we don't use invisible or disabled
windows, we don't actually need to use the ChildWindowFromPoint walk for
the non get_toplevel case, so we can remove that code path.
To find a toplevel, we need to start from the desktop and work up, using
ChildWindowFromPointEx (to ignore invisible and disabled windows). If we
don't ignore invisible and disabled windows (as is the case with the
ChildWindowFromPoint call, we are liable to get returns of hidden or
disabled children of the desktop which don't belong to us, but notionally
occupy the same area under the pointer.
An alternative might be to start our walk with one of the children of the
desktop owned by our process and thread - which we can enumerate using,
the EnumThreadWindows call, or (presumably) determine internally. This
would not work when we are inside a GtkSocket though, as the children of
the desktop would belong to the process owning the GtkPlug - we would
have to rely on our own list of windows.
For correctness, this commit adds tests to ensure that we don't try to
return either x or y window coordinates if that corresponding pointer is
NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=658842
2011-09-10 15:30:56 +00:00
|
|
|
if (win_x)
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
*win_x = (screen_pt.x + _gdk_offset_x) / impl->window_scale;
|
Win32: Fix _gdk_windowing_window_at_pointer to correctly return a toplevel
Commit 5ebb32d1ffa23241d562fb4d5be02bc6f156b515 didn't add the correct
code to find the toplevel window. The WindowFromPoint() function does
not return the toplevel window in the hierarchy, it returns the deepest
non-disabled, non-invisible child. As we don't use invisible or disabled
windows, we don't actually need to use the ChildWindowFromPoint walk for
the non get_toplevel case, so we can remove that code path.
To find a toplevel, we need to start from the desktop and work up, using
ChildWindowFromPointEx (to ignore invisible and disabled windows). If we
don't ignore invisible and disabled windows (as is the case with the
ChildWindowFromPoint call, we are liable to get returns of hidden or
disabled children of the desktop which don't belong to us, but notionally
occupy the same area under the pointer.
An alternative might be to start our walk with one of the children of the
desktop owned by our process and thread - which we can enumerate using,
the EnumThreadWindows call, or (presumably) determine internally. This
would not work when we are inside a GtkSocket though, as the children of
the desktop would belong to the process owning the GtkPlug - we would
have to rely on our own list of windows.
For correctness, this commit adds tests to ensure that we don't try to
return either x or y window coordinates if that corresponding pointer is
NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=658842
2011-09-10 15:30:56 +00:00
|
|
|
if (win_y)
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
*win_y = (screen_pt.y + _gdk_offset_y) / impl->window_scale;
|
2015-12-17 23:36:57 +00:00
|
|
|
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
return window;
|
Win32: Fix _gdk_windowing_window_at_pointer to correctly return a toplevel
Commit 5ebb32d1ffa23241d562fb4d5be02bc6f156b515 didn't add the correct
code to find the toplevel window. The WindowFromPoint() function does
not return the toplevel window in the hierarchy, it returns the deepest
non-disabled, non-invisible child. As we don't use invisible or disabled
windows, we don't actually need to use the ChildWindowFromPoint walk for
the non get_toplevel case, so we can remove that code path.
To find a toplevel, we need to start from the desktop and work up, using
ChildWindowFromPointEx (to ignore invisible and disabled windows). If we
don't ignore invisible and disabled windows (as is the case with the
ChildWindowFromPoint call, we are liable to get returns of hidden or
disabled children of the desktop which don't belong to us, but notionally
occupy the same area under the pointer.
An alternative might be to start our walk with one of the children of the
desktop owned by our process and thread - which we can enumerate using,
the EnumThreadWindows call, or (presumably) determine internally. This
would not work when we are inside a GtkSocket though, as the children of
the desktop would belong to the process owning the GtkPlug - we would
have to rely on our own list of windows.
For correctness, this commit adds tests to ensure that we don't try to
return either x or y window coordinates if that corresponding pointer is
NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=658842
2011-09-10 15:30:56 +00:00
|
|
|
}
|
2010-05-25 22:38:44 +00:00
|
|
|
|
Win32: Fix _gdk_windowing_window_at_pointer to correctly return a toplevel
Commit 5ebb32d1ffa23241d562fb4d5be02bc6f156b515 didn't add the correct
code to find the toplevel window. The WindowFromPoint() function does
not return the toplevel window in the hierarchy, it returns the deepest
non-disabled, non-invisible child. As we don't use invisible or disabled
windows, we don't actually need to use the ChildWindowFromPoint walk for
the non get_toplevel case, so we can remove that code path.
To find a toplevel, we need to start from the desktop and work up, using
ChildWindowFromPointEx (to ignore invisible and disabled windows). If we
don't ignore invisible and disabled windows (as is the case with the
ChildWindowFromPoint call, we are liable to get returns of hidden or
disabled children of the desktop which don't belong to us, but notionally
occupy the same area under the pointer.
An alternative might be to start our walk with one of the children of the
desktop owned by our process and thread - which we can enumerate using,
the EnumThreadWindows call, or (presumably) determine internally. This
would not work when we are inside a GtkSocket though, as the children of
the desktop would belong to the process owning the GtkPlug - we would
have to rely on our own list of windows.
For correctness, this commit adds tests to ensure that we don't try to
return either x or y window coordinates if that corresponding pointer is
NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=658842
2011-09-10 15:30:56 +00:00
|
|
|
window = gdk_win32_handle_table_lookup (hwnd);
|
|
|
|
}
|
2010-05-25 22:38:44 +00:00
|
|
|
|
|
|
|
if (window && (win_x || win_y))
|
|
|
|
{
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
impl = GDK_WINDOW_IMPL_WIN32 (window->impl);
|
|
|
|
|
Win32: Fix _gdk_windowing_window_at_pointer to correctly return a toplevel
Commit 5ebb32d1ffa23241d562fb4d5be02bc6f156b515 didn't add the correct
code to find the toplevel window. The WindowFromPoint() function does
not return the toplevel window in the hierarchy, it returns the deepest
non-disabled, non-invisible child. As we don't use invisible or disabled
windows, we don't actually need to use the ChildWindowFromPoint walk for
the non get_toplevel case, so we can remove that code path.
To find a toplevel, we need to start from the desktop and work up, using
ChildWindowFromPointEx (to ignore invisible and disabled windows). If we
don't ignore invisible and disabled windows (as is the case with the
ChildWindowFromPoint call, we are liable to get returns of hidden or
disabled children of the desktop which don't belong to us, but notionally
occupy the same area under the pointer.
An alternative might be to start our walk with one of the children of the
desktop owned by our process and thread - which we can enumerate using,
the EnumThreadWindows call, or (presumably) determine internally. This
would not work when we are inside a GtkSocket though, as the children of
the desktop would belong to the process owning the GtkPlug - we would
have to rely on our own list of windows.
For correctness, this commit adds tests to ensure that we don't try to
return either x or y window coordinates if that corresponding pointer is
NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=658842
2011-09-10 15:30:56 +00:00
|
|
|
if (win_x)
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
*win_x = client_pt.x / impl->window_scale;
|
Win32: Fix _gdk_windowing_window_at_pointer to correctly return a toplevel
Commit 5ebb32d1ffa23241d562fb4d5be02bc6f156b515 didn't add the correct
code to find the toplevel window. The WindowFromPoint() function does
not return the toplevel window in the hierarchy, it returns the deepest
non-disabled, non-invisible child. As we don't use invisible or disabled
windows, we don't actually need to use the ChildWindowFromPoint walk for
the non get_toplevel case, so we can remove that code path.
To find a toplevel, we need to start from the desktop and work up, using
ChildWindowFromPointEx (to ignore invisible and disabled windows). If we
don't ignore invisible and disabled windows (as is the case with the
ChildWindowFromPoint call, we are liable to get returns of hidden or
disabled children of the desktop which don't belong to us, but notionally
occupy the same area under the pointer.
An alternative might be to start our walk with one of the children of the
desktop owned by our process and thread - which we can enumerate using,
the EnumThreadWindows call, or (presumably) determine internally. This
would not work when we are inside a GtkSocket though, as the children of
the desktop would belong to the process owning the GtkPlug - we would
have to rely on our own list of windows.
For correctness, this commit adds tests to ensure that we don't try to
return either x or y window coordinates if that corresponding pointer is
NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=658842
2011-09-10 15:30:56 +00:00
|
|
|
if (win_y)
|
GDK-Win32/4.0: Enable HiDPI support for Windows
This enables HiDPI support for GTK+ on Windows, so that the
fonts and window look better on HiDPI displays. Notes for the current
work:
-The DPI awareness enabling can be disabled if and only if an application
manifest is not embedded in the app to enable DPI awareness AND a user
compatibility setting is not set to limit DPI awareness for the app, via
the envvar GDK_WIN32_DISABLE_HIDPI. The app manifest/user setting for
DPI awareness will always win against the envvar, and so the HiDPI items
will be always setup in such scenarios, unless DPI awareness is disabled.
-Both automatic detection for the scaling factor and setting the scale
factor using the GDK_SCALE envvar are supported, where the envvar takes
precedence, which will therefore disable automatic scaling when
resolution changes.
-We now default to a per-system DPI awareness model, which means that we
do not handle WM_DPICHANGED, unless one sets the
GDK_WIN32_PER_MONITOR_HIDPI envvar, where notes for it are in the
following point.
-Automatic scaling during WM_DISPLAYCHANGE is handled (DPI setting change of
current monitor) is now supported. WM_DPICHANGED is handled as well,
except that the window positioning during the change of scaling still
needs to be refined, a change in GDK itself may be required for this.
-I am unable to test the wintab items because I don't have such devices
around.
https://bugzilla.gnome.org/show_bug.cgi?id=768081
2016-06-27 05:16:43 +00:00
|
|
|
*win_y = client_pt.y / impl->window_scale;
|
2010-05-25 22:38:44 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return window;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gdk_device_win32_select_window_events (GdkDevice *device,
|
|
|
|
GdkWindow *window,
|
|
|
|
GdkEventMask event_mask)
|
|
|
|
{
|
|
|
|
}
|
2016-01-23 22:26:04 +00:00
|
|
|
|
|
|
|
static void
|
|
|
|
gdk_device_win32_class_init (GdkDeviceWin32Class *klass)
|
|
|
|
{
|
|
|
|
GdkDeviceClass *device_class = GDK_DEVICE_CLASS (klass);
|
|
|
|
|
|
|
|
device_class->get_history = gdk_device_win32_get_history;
|
|
|
|
device_class->get_state = gdk_device_win32_get_state;
|
|
|
|
device_class->set_window_cursor = gdk_device_win32_set_window_cursor;
|
|
|
|
device_class->warp = gdk_device_win32_warp;
|
|
|
|
device_class->query_state = gdk_device_win32_query_state;
|
|
|
|
device_class->grab = gdk_device_win32_grab;
|
|
|
|
device_class->ungrab = gdk_device_win32_ungrab;
|
|
|
|
device_class->window_at_position = _gdk_device_win32_window_at_position;
|
|
|
|
device_class->select_window_events = gdk_device_win32_select_window_events;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gdk_device_win32_init (GdkDeviceWin32 *device_win32)
|
|
|
|
{
|
|
|
|
GdkDevice *device;
|
|
|
|
|
|
|
|
device = GDK_DEVICE (device_win32);
|
|
|
|
|
|
|
|
_gdk_device_add_axis (device, GDK_NONE, GDK_AXIS_X, 0, 0, 1);
|
|
|
|
_gdk_device_add_axis (device, GDK_NONE, GDK_AXIS_Y, 0, 0, 1);
|
|
|
|
}
|