It turns out that we must put Directory.Build.props in win32/vs10 and let
automake copy it over to win32/vs15/... so do that, and only dist the copy
in win32/vs15.
Update the NMake Makefiles used for generating the various sources be able to
cope with an ARM64 build environment, and update the project files, in
particular for Visual Studio 2017 (VisualStudioVersion 15.0) so that we can
pull in the system .lib's that were somehow excluded from the default list
on ARM64 builds.
Also, add a custom Directory.Build.props in win32/vs15 so that we do not
try to build with the Windows 8.1 SDK by defualt, which is not ready for ARM64
builds, but instead uses the appropriate Windows 10 SDK that supports this.
Update the README.win32 file to give people instructions on how ARM64 builds
can be carried out.
Look in the include/harfbuzz directory that is under the pre-defined prefix
directory, as Pango 1.44.x and later pulled in HarfBuzz headers for all builds
Intel OpenGL drivers have an issue where the results of a series of
glBlitFramebuffer() can delay updating the display, when we use GDK_GL=always,
which is manifested when attempting to enter text in text boxes.
This attempts to work around this issue by requiring a glFlush() call and a
retry to the same glBlitFramebuffer() calls to avoid delays in keystrokes when
using GDK_GL=always and when not using libANGLE OpenGL/ES emulation, when an
Intel OpenGL driver is being used.
Special thanks to Lukas K. for the analysis and coming up with a workaround,
which this patch builds upon.
Fixes issue 3487
fmin() is a function that is introduced with C99/C++11, so check for the
presence of it and provide a simple implementation for it if it does not
exist.
Also update the config.h.win32.in template accordingly, since this
function is provided on Visual Studio 2013 or later.
This way, we can enable the built binaries to print out diagnostic
messages as needed by the values we set via the envvar GDK_DEBUG.
The release configs of the Visual Studio project files follow the
settings of Meson's `debugoptimized` build settings.
Makes event listeners active explicitly if supported; corrects
handling for deleted surfaces preventing javascript errors in
accessing deleted objects; makes event identifiers unique for
broadwayd when executing in Chrome on Android.
Partially fixes#1493
The size of the cursor depends on either the gtk-cursor-aspect-ratio
GtkSetting or as of the previous commit on the GtkSetting or the
cursor-aspect-ratio style property. GtkTextView was only considering the
style property.
Related: https://gitlab.gnome.org/GNOME/gtk/-/issues/3441
The gtk-cursor-aspect-ratio GtkSetting was only recently introduced and
replaced the cursor-aspect-ratio style property. This was causing old
configurations that used CSS to modify this property to no longer apply.
This commit introduces a fallback from the GtkSetting to the style
property if the value of the setting is unchanged.
Related: https://gitlab.gnome.org/GNOME/gtk/-/issues/3441
The gtk-cursor-aspect-ratio property got added as a float property.
However there is no parser for float values from keyfiles which meant
that it could not be changed from settings.ini.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3441
When the notebook page does not have a label, it should not fallback to
asking its child accessible for extent, since the child might be asking
exactly the converse when it is a socket, thus getting in an infinite
loop. When the page does not have a label, is does not really make sense to
give it an extent anyway.
Fixes atk#18
The $button_fill hack for button.circular is pretty awkward and is
currently broken. Instead of relying on it, allow the button() mixin to
have an additional background-image optionally.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3354
In pointer_surface_update_scale(), only rescale the cursor surface when
the scale has actually changed and the cursor is on at least one output.
fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3350
Right now, this issue is not completely understood, so it might also
involve some questionable handling of cursor surface by sway/wlroots.
However, irrespective of that issue, this patch avoids unnecessary calls to the
compositor, and there should be no drawback: Whenever the pointer enters
a new output, pointer_surface_update_scale() will be called again, such
that correct scaling of the cursor is still ensured.
There is a slight difference: When the cursor leaves the last output,
previously the image was reset to scale factor 1. Now, it keeps whatever
was last. That might be more sensible than the previous behaviour,
assuming that it's likely that when the cursor enter an output again, it
has the same scaling. Alternatively, if one cares about resource usage
at this level, it might make more sense to destroy the surface then
rescaling to 1.
The existing treeview header button border in GTK3 is close to
invisible. The preferred way to find the border for a treeview column
is to hover the mouse near the beginning of the header button text
expecting the default cursor to switch to 'col-resize' cursor. This
works only when all column headers in the view are left aligned. After
adding a few numeric columns to the view, whose headers are right
aligned, it becomes really hard to find the location of the border
between a left aligned and right aligned column header.
This change addresses the issue by using high contrast colors for
borders of treeview header button - in line with the colors used in
Adwaita theme in GTK4.
See merge request GNOME/gtk!2467
In gdkdevice-win32.c we are interested in knowing which window
receives mouse input at a specific location.
Only WindowFromPoint is the right API for the task, other API's
(such as (Real)ChildWindowFromPoint(Ex)) have shortcomings because
they are really designed for other purposes. For example, only
WindowFromPoint is able to look through transparent layered windows.
So even if we want to find a direct child we have to use
WindowFromPoint and then walk up the hierarchy.
Fixes: #370, #417
See: !2767
There is some bug somewhere where the geometry ends up being correct.
Mutter didn't handle this gracefully, and is to be changed to simply
respect the protocol and error out the client that sends bogus data.
Prepare for this by instead of sending bogus data, complain loudly if it
would happen dropping the invalid geometry on the floor instead of
sending it.
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/1527
