Commit 1d0fad3 revealed that there were some assumptions made that were
actually to compensate for the bug fixed by that commit, so we need to
remove those assumptions as they would result in AerSnap to not work
properly on HiDPI screens.
Also re-do how we set the x and y positions of our GdkWindow, so that we
are more consistent across the board when we go between a GDK window
coordinate and a Windows API window cooredinate.
This would also simplify the code a bit.
https://bugzilla.gnome.org/show_bug.cgi?id=785999
Some drivers don't do that (not sure whether that is the correct behaviour
or not). Remember each WT_PROXIMITY with LOWORD(lParam) != 0 that we get,
then look for a WT_CSRCHANGE. If WT_CSRCHANGE doesn't come, but a WT_PACKET
does, assume that this device is the one that sent WT_PROXIMITY.
Also include fallback code to ensure that WT_PACKETs for an enabled device
disable the system pointer, because WT_PROXIMITY handler might have
enabled it by mistake, since it's not possible to know which device left
the proximity (it might have been a disabled device).
https://bugzilla.gnome.org/show_bug.cgi?id=778328
Previously HiDPI scale was retrieved and applied too late in the initialization
process to affect monitor size and monitor workarea size, but the code that
initializes these sizes *did* try to use the scale, even though it was always
getting scale=1.
To fix this, move the too-late code into monitor enumeration routine.
This also fixes a probable semantic bug where width and height were divided
by scale, again.
Now monitor and workarea should be in application pixels (i.e. divided by scale),
as intended.
https://bugzilla.gnome.org/show_bug.cgi?id=778835
Previously GDK only made up monitors when it initially found none. Now it
also makes up monitors when it initially finds some, but later fails to get
their informatin in a normal way and finally prunes them out, being left with
zero monitors.
Having zero-length monitor array is unexpected and causes a number
of critical warnings and some critical functionality (such as displaying
drop-down menus) fails in such cases.
Ideally, there might be such a way to interrogate W32 API that produces the
information about non-real (but active) monitors out of it so that it isn't
necessary for us to make stuff up. However, this code is already complicated,
and i am not prepared to dig W32 API to find a way to do this.
This fixes the issues people had when they accessed a Windows desktop via RDP.
https://bugzilla.gnome.org/show_bug.cgi?id=777527
Windows WM handles AeroSnap for normal windows on keydown. We did this
on keyup only because we do not get a keydown message, even if Windows WM
does nothing with a combination. However, in some specific cases it DOES
do something - and we have no way to detect that. Specifically, winkey+downarrow
causes maximized window to be restored by WM, and GDK fails to detect that. Then
GDK gets a keyup message, figures that winkey+downarrow was pressed and released,
and handles the combination - by minimizing the window.
To overcome this, install a low-level keyboard hook (high-level ones have
the same problem as normal message loop - they don't get messages when
Windows WM handles combinations) and use it to detect interesting key combinations
before Windows WM has a chance to block them from being processed.
Once an interesting combination is detected, post a message to the window, which
will be handled in due order.
It should be noted that this code handles key repetitions in a very crude manner.
The downside is that AeroSnap will not work if hook installation function call fails.
Also, this is a global hook, and if the hook procedure does something wrong, bad things
can happen.
https://bugzilla.gnome.org/show_bug.cgi?id=776031
Instead of using some kind of flawed logic about modifying a keypress result
when CapsLock is toggled, just add a CapsLock shift level (and all derived
shift levels, i.e. Shift+CapsLock and CapsLock+AltGr and Shift+CapsLock+AltGr)
and query Windows keyboard layout API about the result of keypresses involving
CapsLock.
Keysym table is going to be (roughly) twice as large now, but CapsLock'ed
keypresses will give correct results for some keyboard layouts (such as
Czech keyboard layout, which without this change produces lowercase letters
for CapsLock->[0,2,3,4...] instead of uppercase ones).
Keymap update time also increases accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=165385
Instead of checking for window state and giving it extra styles that
fit, just give it all styles that it is missing. It turned out that
otherwise it is impossible to, for example, restore a maximized window
via sysmenu. Also, be more flexible towards GDK/WM window state mismatches
and consider the window minimized/maximized if *either* GDK or WM thinks so.
https://bugzilla.gnome.org/show_bug.cgi?id=776485
Just set check_for_dpi_awareness = TRUE and eventually it will be handled
correctly, even if setDpiAwareFunc() returns E_ACCESSDENIED or shcore functions
are NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=777031
When primary monitor is smaller than the actual monitor on which the
window is being maximized, the WM will do widnow size adjustments
that will completely screw the window size if we try to make it
smaller than 100% fullscreen (to account for taskbar size, for example).
Fix this by overriding maximized window size during WM_WINDOWPOSCHANGING.
https://bugzilla.gnome.org/show_bug.cgi?id=775808
Ensure that things build again, and instead use the Windows API to
acquire the screen dimensions (note: this may need to be scaled for
HiDPI, but since I do not own a WinTab-based device, I will need to
keep the dimensions as-is for now).
Also update the gdkdnd-win32.c code to use formats rather than targets.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
Instead, turn the functions into backend API:
gdk_broadway_display_add_selection_targets()
gdk_broadway_display_clear_selection_targets()
Remove the old per-backend functions, too.
Like the X11 and Wayland backends, re-work how the cursors are being
handled. So, we use a hash table to cache up the HCURSORS that we
create along the way.
We still need to cache up the icon/cursor themes since this is something
that is not part of Windows but was added on to support icon/cursor themes
such as Adwaita on Windows, but should be in-line with what is going on in
GdkCursor.
Also, remove the _gdk_grab_cursor global variable in gdkprivate-win32.h,
and replace it with another variable in the GdkWin32Display structure,
to make things cleaner in the process.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
Since on Windows we need to use a good amount of temporary GL contexts,
we need to switch back to the original GL contexts we were using when
we are done with the temporary GL contexts, otherwise multi-GL windows
will cause confusions causing display artifacts and crashes.
Also, use the GdkWin32GLContext::gl_hdc consistently throughout
the code and remove the GdkWin32Display::gl_hdc as Lukas K pointed out
that GdkWin32Display::gl_hdc becomes out-of-date and so the HDC that the
GL context is bound to becomes incorrect in sceanarios using multiple
windows with GtkGLArea/GdkGLArea items (which would cause the artifacts in
programs that use multiple windows with GtkGLArea/GdkGLArea items, and it
turns out that GdkWin32Display::gl_hdc is actually not necessary to help
keep track of the HDCs we use for our GL contexts.
This will also fix on Windows with GDK_GL=always, or when GSK's gl
renderer is used.
Partly based on patch from Lukas K <lu@0x83.eu>
https://bugzilla.gnome.org/show_bug.cgi?id=789213
Move the leftovers from the removals to use the current APIs, to fix the
build. Also for gdk_device_virtual_set_window_cursor(), only do
something when a valid GdkCursor is passed in here.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
The preferred api to create cursors is by name, and the
GdkCursorType enumeration can directly trace its ancestry
to the horrible X cursor font. So lets stop using it.
Drop the screen argument from gdk_dnd_find_window_for_screen
and rename the function to gdk_dnd_find_window. The screen
argument does not add anything here since the drag context
is already tied to the display. Update all backends, and
update all callers.
Implement GdkDisplay->get_setting() using the existing
_gdk_win32_screen_get_setting() and get rid of GdkScreen->get_setting()
as a result, to follow the changes in GDK.
Also, since we don't emit settings events in the Windows GDK backend,
but we acquire settings to print using GDK_SETTING, drop all references
related to GDK_SETTING since that is now removed. Update the debug
strings that are print out as a result
(gdk_screen_get_setting->gdk_display_get_setting).
https://bugzilla.gnome.org/show_bug.cgi?id=773299
The list of surfaces passed into the function may be NULL, so don't try
to initialize the surfaces if it is so, to avoid a crash.
Also, remove the cast to GdkPixbuf* for getting surfaces->data, as we
are already using a cairo_surface_t*.
https://bugzilla.gnome.org/show_bug?id=773299
Those should be interpreted by widget-local gestures, not guessed at a
high level with no notions of the specific context. Users will want
GtkGestureMultiPress to replace these events.
Interpret NULL as "root window" here - we only have one
screen nowadays, so there is no choice involved, and this
will let us avoid dealing with the root window in the
fontend code.
It was suggested that the project files to be moved to win32/, so that we can
have one less layer of directories we need to go down into to reach the project files.
This adds support to the GDK Win32 backend so that we can support Vulkan
context creation for use in the GSK Vulkan renderer, so that we can test
it on Windows platforms as well.
https://bugzilla.gnome.org/show_bug.cgi?id=776544
Fix the build after the branch wip/alexl/simplify-gdkwindow was merged, as
there are some changes that broke things in the Windows backend, namely:
-gdk_win32_input_shape_combine_region() should not be removed at this
point (though it is a stub--otherwise GDK/Win32 will crash)
-Some more code need to be removed due to the removal of items in the
above-mentioned merged branch
Also, like the X11 backend, do not allow the creation of native child
windows, and stop checking for subsequent child windows
(GDK_WINDOW_CHILD), so that we can clean things up a bit.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
We're not currently using this, and dropping it allows us to loose
a bunch of code which leads us towards the goal of having GdkWindow
only for toplevels (and reparenting makes not sense for toplevels).
We can't really support these on e.g. wayland anyway, and we're trying
to get rid of subwindow at totally in the long term, so lets drop this.
It allows us to drop a lot of complexity.
There were some parts that need some updates after the refactoring in
GDKGL, so that the code will continue to build and run.
For gdkwindow-win32.c, comment out the parts where we check for use_gl
(which was removed), since we are going to move all drawing to OpenGL,
but don't remove/disable the whole portion as that transition is not
complete at this point.
There a is new GDKGL function that checks for the damaged area of the back
buffer, but since the notion of "damage" is for *NIX (GLX/EGL for
Wayland/mir), meaning that there is no such extension for Windows in this
regard, so we can't support this on Windows as-is, at least for now.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
... instead of a gl context.
This requires some refactoring in the way we mark the shared context as
drawing: We now call begin_frame/end_frame() on it and ignore the call
on the main context.
Unfortunately we need to do this check in all vfuncs, which sucks. But I
haven't found a better way.
No visible changes as GL rendering is disabled at the moment.
What was done:
1. Move window->invalidate_for_new_frame to glcontext->begin_frame
This moves the code to where it is used (the GLContext) and prepares it
for being called where it is used when actually beginning to draw the
frame.
2. Get rid of buffer-age usage
We want to let the application render directly to the backbuffer.
Because of that, we cannot make any assumptions about the contents the
application renders outside the clip area.
In particular GskGLRenderer renders random stuff there but not actual
contents.
3. Pass the actual GL context
Previously, we passed the shared context to end_frame, now we pass the
actual GL context that the application uses for rendering. This is so
that the vfuncs could prepare the actual contexts for rendering (they
don't currently).
4. Simplify the code
The previous code set up the final drawing method in begin_frame.
Instead, we now just ensure the clip area is something we can render
and decide on the actual method in end_frame.
This is both more robust (we can change the clip area in between if we
want to) and less code.
Only attempt to initialize Wintab after the display manager announces
that the first default display has been set. Fixes a segfault during
initialization of specific tablet drivers' wintab32.dlls. Add assertions
and verbose comments explaining this nonsense because this stuff is a
pain to have to keep fixing.
https://bugzilla.gnome.org/show_bug.cgi?id=774379
Move the orientation sanity-checks into the packet decode func.
Rationale: the packet handling func may otherwise read beyond the end of
device->last_axis_data.
Also expand them to cope with my test Huion's weird reporting.
Also correct the azimuth angle to align with GDK's presentation.
Most importantly, fix annoying comment typo.
https://bugzilla.gnome.org/show_bug.cgi?id=774265
Fix a regression introduced in 4ce6d10601
which causes devices with an odd-numbered zero-based index in the list
to be passed over incorrectly. This might present as yet another "device
does not send pressure" bug for ~50% of devices out there.
This commit also closes off another potential segfault for wintab_devices
lists which have an odd length.
https://bugzilla.gnome.org/show_bug.cgi?id=774699
As in the last commit on gdkdisplay-win32.c, we need to define that to be
0x0600 (Vista) or later so that the items needed in the Windows headers be
activated.
See: https://bugzilla.gnome.org/show_bug.cgi?id=768081#c62
... to be for Vista (0x0600) or later. This is so that the necessary
items in the Windows headers be activated so that the code will build
properly on mingw-w64, and we already require Vista or later for GTK+.
Thanks Ting-Wei Lan for pointing this out.
See: https://bugzilla.gnome.org/show_bug.cgi?id=768081#c62
