When using this function in GtkSourceView (for GTK 3), there was a
mistake for retrieving a GdkRGBA value.
So, better document the function to avoid further mistakes.
The 1px shadow was showing up on adjacent monitors when a SSD window was
maximized. Additionally this was causing mutter to skip direct scanout
of these windows, because they extend beyond the screen.
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/2304
Add a target in the install-msvc.mak file that enables one to generate
the translations (.mo) files using msgfmt from the .po catalog files.
Add an entry in config-msvc.mak[.in] so that one can use it to configure
a custom location for the msgfmt.exe program, since it is harder to
install with Visual Studio, so that one can use a prebuilt copy from
Cygwin or MSYS2, for instance.
Generate the full GResource XML files for the Emoji data, and generate
the binary GResource data from them and copy them as appropriate.
At this point, the installed data files are in-line with what the Meson
builds install, sans the processed translation files.
This does what the Meson build files also do, so that people can have
the m4 module, the ITS files as RelaxNG files if they choose to use them
anyways.
In case of an offscreen window find its onscreen embedder, and NULL
any GdkWindowImpl that's not quartz, checking all return values.
This replaces 16ded683, removing its unnecessary search_for_nearest
functions.
Any unchecked cast of a GdkWindowImpl to GdkWindowImplQuartz risks at
least getting an invalid member reference, not just the ones in
gdk_quartz_window_get_foo, and all calls to gdk_quartz_window_get_foo need
to be checked, not just Gtk's internal calls. The motivation was that
transient_for was getting set on a Gimp offscreen window and that caused a
crash in raise_transient.
Includes creating the CVPixelBuffer to supply the layer contents when
creating the cairo_image_surface, which reduces the number of them created
at the wrong scale.
Add rules in the helper NMake Makefiles to generate the GResource
sources for gtk3-widget-factory. This prepares for us to add project
files to build that demo program.
The source listing is not likely to change for this one, so clean up the
build files a bit, and make the gtk3-icon-browser MSVC project a
complete one instead of a template.
This way, we can re-use items when we want to support generating project
files from the templates, such as building with project files directly
from a GIT checkout, or when we add sources and want to quickly add them
into the project files.
Use VS1X instead of VS10 in the variable names in the NMake Makefiles,
since the VS2010 MSBuild Visual Studio project files really apply to all Visual
Studio versions at or after VS2010.
Also use variable substitution here to ease future maintenance.
It is probably still possible with older GLib and GObject-Introspection
versions, but it is certainly not recommended with the advent of Meson.
One will not be able to re-generate demos.h.win32 (for
enabling/disabling the Font Features Demo) with Python 2.7.x-Python 3.x
or PERL must be used.
Append the detected Visual Studio version and target arch to the various
NMake Makefile snippets we generate on the fly, so that if multiple
items access the helper NMake Makefiles at the same time, we will be
much less prone to trouble.
This is not 100% fool-proof, but should make things much more robust when
attempting to build via different Visual Studio versions and configs at
the same time.
The scripts that are used during the build to generate the sources now
do require Python 3.x to work, so make this clear to people.
In the Visual Studio projects, update the default Python installation to
correspond with Python 3.7.x or later, which is the lowest supported
version series of Python at this point.
This uses CVDisplayLink to drive the GdkFrameClock. A GdkWindow
can register a frame callback to thaw their frame clock as necessary
based on the next notification from CVDisplayLink.
CVDisplayLink notifies us on a high-priority thread. We use the same
NSEventas gdkeventloop-quartz.c to wakeup the main loop. This is done
so that we don’t pathologically wake up the select thread to then
continue notifying the main loop.
We use an embedded GList node in the GdkWindowImplQuartz so that we
can avoid allocating any lists or arrays for pending frame callbacks.
Compare this to the same design in GdkWindow for children.
We no longer use the autotools 'dist-hook' to generate the items that we
need to build introspection with the Visual Studio projects, so drop the
autotools files and bits that we had to support this. So, for
introspection on Visual Studio via the project files, it is purely via
NMake at this point.
By doing so, we can drop the autotools rules that we use to generate the
file lists and rules for building introspection via NMake Makefiles for
Visual Studio builds via the project files.
Like what was done in the *.vcxprojin templates, consolidate project configs
that are repetitive, and use the 'Condition=' directive to distinguish between
configuration and/or target platform differences.
...for Visual Studio 2010 and later, since we used to copy them and
merely update the value of $(VSVer) during 'make dist' as needed.
Instead of doing that, move the property sheets for Visual Studio 2010,
which is the base version that we use, into a directory of its own, and
make the Visual Studio 2010~2022 projects look for them in that
directory, and set VSVer according to the toolset version identified by
each of the project files.
The ARM64-specific property sheet needed for VS2017 and the VS2008
property sheets will remain as they are.
We can again use MSBuild trickery to do what was done in the dropped
property sheet.
Unfortunately, like the last commit, I couldn't figure out a way do to
something similar in the VS2008 project files... :|
... and so stop using gtk3-install.[vsprops|props], and remove that
property sheet from the dist and dist the NMake Makefile for the
purpose.
Also remove win32/vs10/gtk3-install.vcxproj.filters as well, as it is
no longer needed.
We will remove the gtk3-install.[vsprops|[props][.in] in a subsequent
commit.
This is an NMake Makefile that will replace the property sheets in the
Visual Studio project files so that we can call it from the project
files to "install" the binaries and introspection files that were built,
along with the header files and other data files, which aims to be
easier to maintain for the current approach.
This will also be expanded upon to optionally build the translation
files and make the installed files more in-line with what are done in
the Meson build files, where there could be compatibility problems with
older Visual Studio toolchains.
This is a follow-up commit so that the generated GResources sources for
the demos are included in the project files.
As a result, don't include demo_resources.c when regenerating
gtk3-demo.vc[x]proj for toggling on or off the font features demo, as it
would have been there.
The Visual Studio projects have support for generating these, especially
that the encoded string that result from them may become too big for the
Visual Studio compiler to handle (such as for gtk3-demo) and we are normally
supposed to generate the GResources sources for all builds, as the
generated code depends on the compiler being used).
We already generate some of the sources for all builds, so extend this
to the other generated sources as well, since the Visual Studio projects
added support for generating these sources too.
Now that we have a frame clock in place, we should be able to drop
the beam-sync penalty prevention code as we should be aligning our
draws with CVDisplayLink.
Originally by Christian Hergert <chergert@redhat.com>, flushWindow
corrections and improvements by John Ralls.
If we get consecutive preedit string updates that announce a NULL
string, we still do end up issuing ::preedit-changed with those.
Ignore changes from NULL to NULL, it is the other combinations which
must issue this signal.
For reasons that only apply to the old serial handling, asking for
the surrounding after IM changes resulted in lazy handling of
commit() afterwards.
With the recent interpretation of serials, this problem became more
apparent, since it is in fact very likely that the last interaction
step after an IM change is notifying of the changed surrounding
text after the IM change was applied.
Make handling of surrounding text similar to caret position changes,
always commit() after the state change, but skip through non-changes.
This makes the compositor state fully up-to-date after an IM change.
(cherry-picked from commit eb7c78aa48)
Similarly, uses casts in `gtk_image_definition_unref()`. Compilation
succeeds without them, unlike in `gtk_image_definition_ref()`, because
`gtk_image_definition_unref()` is not called internally, unlike
`gtk_image_definition_ref()`. But the build would fail if some function
defined in the module were changed in the future to call
`gtk_image_definition_unref()`, and we can future-proof it now. This
also removes an inconsistency in how we access the members of the union.
`jhbuild build gtk+-3` with GCC 12 fails with:
```
In function ‘gtk_image_definition_ref’,
inlined from ‘gtk_image_definition_new_empty’
at ../../../../jhbuild/checkout/gtk+-3/gtk/gtkimagedefinition.c:107:10:
../../../../jhbuild/checkout/gtk+-3/gtk/gtkimagedefinition.c:241:13: error:
array subscript ‘GtkImageDefinition {aka union _GtkImageDefinition}[0]’
is partly outside array bounds of ‘GtkImageDefinitionEmpty[1]’
{aka ‘struct _GtkImageDefinitionEmpty[1]’} [-Werror=array-bounds]
241 | def->empty.ref_count++;
| ~~~~~~~~~~^~~~~~~~~~
../../../../jhbuild/checkout/gtk+-3/gtk/gtkimagedefinition.c:
In function ‘gtk_image_definition_new_empty’:
../../../../jhbuild/checkout/gtk+-3/gtk/gtkimagedefinition.c:105:34: note:
object ‘empty’ of size 8
105 | static GtkImageDefinitionEmpty empty = { GTK_IMAGE_EMPTY, 1 };
| ^~~~~
```
and many similar errors.
Fix it by casting `GtkImageDefinition` to `GtkImageDefinitionEmpty` or
similar, as appropriate.
Essentially backports 4dcd02e853 from main to gtk-3-24.
Instead of performing keyboard layout substitution whenever we find a matching
entry in the registry, first try to load the original layout and only attempt
substitution when that fails.
See #4724
This makes it easier to figure out those values (which are mentioned in
the GtkApplication documentation) rather than working that out from the
way they're generated (or documented as being generated).
Some Windows keymaps have bogus mappings for the Ctrl modifier. !4423 attempted
to fix this by ignoring the Ctrl layer, but that was not enough. We also need to
ignore combinations of Ctrl with other modifiers, i.e. Ctrl + Shift. For example,
Ctrl + Shift + 6 is mapped to the character 0x1E on a US keyboard (but it should
be treated as Ctrl + ^). Basically, always ignore Ctrl unless it is used in
conjunction with Alt, i.e. as part of AltGr.
Related issue: #4667
Some keymaps on Windows contain bogus mappings for Ctrl+key for certain
keys, e.g. Ctrl+Backspace = Delete, or Ctrl+[ = 0x1B. These are never
used on Windows, so we should ignore them.
Fixes#4667
This fixes nautilus crash and perhaps other callers issues.
Nautilus (and sometimes glib) crashes with malformed URI inside of the
bookmarks file .config/gtk-3.0/bookmarks when it has no LABEL.
This is result from the closed glib MR #2065 analysis and agreement.
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2065#note_1091979
Signed-off-by: Geyslan G. Bem <geyslan@gmail.com>
Fixes: #4643
The actual code that does the IM context code handling on Windows now uses the
native Windows APIs to handle keystrokes, so this patch is no longer needed, as
it was found that it instead caused issues.
Pointed out in issue #2865.
This reverts commit fd6ce9975e.
On Wayland it is a protocol violation to upload buffers with
dimensions that are not an integer multiple of the buffer scale.
Until recently, Mutter did not enforce this. When it started
doing so, some users started seeing crashes in GTK apps because the
cursor theme ended up with e.g. a 15x16 pixel image at scale of 2.
Add a small sanity check for this case.
Unref private spool_io of GtkPrintJob before setting it to a new one
in gtk_print_job_set_source_file() and gtk_print_job_set_source_fd()
to prevent a leak.
Fixes: #4627
For some users, GetKeyboardLayoutNameA() returns an alias instead of the
fully resolved keyboard layout identifier. In that case, we have to
query the registry to resolve the alias before we can look up the DLL
path.
See comments under #4610
Contrary to what you can read on the internet, SGCAPS keys don't work
by having capslock toggle the KBDCTRL bit, they actually have two
consecutive table entries, the first of which is for the normal
version and the second of which is for the capslocked version.
Background: SGCAPS is short for Swiss German caps because Swiss German
was the first layout to use this feature. For keys with the SGCAPS flag,
capslock has a different effect than pressing shift. For example:
Shift + ü = è, CapsLock + ü = Ü, CapsLock + Shift + ü = È
DLL loading failures should not happen under normal circumstances, but
we should at least try not to crash and and print better diagnostic
messages if they do happen.
See #4610
Previously, we treated CapsLock and KanaLock as part of the global
keyboard state, much like NumLock and ScrollLock, rather than using
the supplied modifier mask. This was because GDK does not have a
modifier mask for KanaLock, only for CapsLock, so it would not have been
possible to properly support it.
However, this approach ended up causing problems, with certain keyboard
shortcuts not registering when capslock was active. This was first
observed in Inkscape [0] and appears to affect shortcuts consisting of a
single key (like 'a') with no additional modifiers (wheareas shortcuts
like 'ctrl+a' work).
So now we are using the supplied GDK_LOCK_MASK instead, and dropped
support for KanaLock, which we probably don't need anyway (since regular
text input should be handled by the IME input module -- the keymap is
mainly for shortcuts and keybindings, where you don't really want
KanaLock).
[0] https://gitlab.com/inkscape/inkscape/-/issues/3082
GTK WIn32 theme - make buttons with .flat class appear flat and buttons in toolbar non-flat if they don't have said class
See merge request GNOME/gtk!4350
gdk_win32_keymap_get_entries_for_keycode() did not initialize n_entries,
which led to a wrong number of items being returned in some cases.
/fixes #4610
If we ended up on no output at all, keep the HiDPI scale as is, as it
likely means we were on a workspace that was switched away from. By
keeping the same scale, we avoid unnecessary scale changes that would
otherwise take place if the scale when on monitors would end up being
more than 1.
Improve the NMake Makefiles that is used to re-generate demos.h(.win32)
by re-generating the gtk3-demo Visual Studio projects, so that one would
no longer need to do that manually.
Update the build instructions accordingly.
Instead of relying on the ones that are currently shipped with the tarballs,
generate them from their .in counterparts prior to the build. This includes
the Resource Scripts (.rc) for libgdk/libgtk, as well as gtkversion.h, in
addition to gdkversionmacros.h which can now be generated during prebuild.
Rename the script as gen-version-items.py, and so make things more generic and
usable by other items in the build. We want to eventually to be able to
generate the .rc files and the *version*.h files from their *.in counterparts
using this script.
This improves the source generating process by:
* Generating the sources in the libgtk build directory, so that we do not
pollute the source tree.
* Support generating gtk[private]typebuiltins.[c|h] in the Visual Studio
projects by using NMake internally.
* Update the projects and the introspection build files so that the generated
sources and headers can be found.
This will enable us to share this list with the NMake Makefiles that will be
used to generate the gtk[private]typebuiltins.[c|h] in the Visual Studio
projects.
This will enable us to not confuse with the deprecated headers in
gtk/deprecated as those headers are also listed under deprecated_h_sources in
gtk/deprecated/Makefile.inc, when we include the makefile snippets in both
gdk/ and gtk/.
This makes the rest of the sources that are generated being put in GDK's build
directory for the Visual Studio projects, instead of being placed in GDK's
source subdir, so that:
* We can avoid polluting GDK's source tree.
* The Visual Studio builds won't interfere with the Meson builds.
Update the project files to look for the generated sources and headers in the
right places, as well as making the introspection builds look for the generated
sources as well.
Also remove the gtk3-gen-srcs property sheets and put the relevant parts in the
corresponding gtk3-build-defines property sheets, to clean things up a bit.
This way, we can have the introspection NMake Makefiles share more items
with the source generating bits.
Update the Visual Studio projects accordingly
The Pango headers prior to 1.44.0 do not include the HarfBuzz headers, so we
need to re-structure how we check for HarfBuzz 2.2.0 or later if we have Pango
1.44.x or later.
Fixes issue #4565.
Pango headers after 1.44.0 include hb.h automatically, but not before, so
re-structure the #if/#elif/#else checks for the availability of HarfBuzz 2.2.0
or later.
Pointed out in issue #4565.
Allows the application to handle "Dock icon > Quit" the same as
"Application menu > Quit".
Requires GtkApplication's `register-session` property.
Suitable replacement for gtk-mac-integration's
`NSApplicationBlockTermination` signal.
This will make introspection builds via the Visual Studio 2022 projects work as
the NMake Makefiles were looking for VS2019 builds, which most probably did not
exist
This reverts commit 749a58ab26.
This maintains feature parity with the autotools build. To achieve the
equivalent of --with-included-immodules=wayland,
-Dbuiltin_immodules=wayland,waylandgtk can be used instead.
We now have a boolean setting that determines whether the high-contrast
theme should be used. Support it by automatically setting the existing
`gtk-theme-name` and `gtk-icon-theme-name` properties when enabled.
With that, it is no longer necessary to change the regular theme settings
for high-contrast, so toggling between high-contrast and a non-default
theme finally works reliably.
`gdk_quartz_display_get_monitor_at_window` crashes when it tries to access the NSWindow on
an offscreen window. The attribute `toplevel` of `impl` is uninitialized and
causes a segfault.
This partially fixes: https://gitlab.gnome.org/GNOME/gimp/-/issues/7608
Windows keymaps contain some bogus mappings, e.g. Ctrl+Backspace=Delete.
Previously, we correctly identified the key as Backspace, but the Ctrl
was still consumed, so the Ctrl+Backspace keybinding did not work.
gdk_win32_keymap_translate_keyboard_state erroneously used the active
group rather than the specified group, which caused shortcuts not to
work in Inkscape when using a Cyrillic layout.
This consolidates the check for the running CPU in one single location,
to make things a bit cleaner, as:
* We can make use of IsWow64Process2(), if available, to check both
whether we are running on an ARM64 CPU, and whether we are running as
a WOW64 process. This is also the function to use to properly check
whether we are running as a WOW64 process on ARM64 systems, as
IsWow64Process() does not work as we want on ARM64 systems.
* If we don't have IsWow64Process2() (which is absent from Windows prior
to Windows 10 1511, where ARM64 Windows is introduced), we can fall
back to IsWow64Process(), which will tell us whether we are running
as an WOW64 process (but clearly not on an ARM64 system).
Also clean up things a bit so that we can reduce reliance on global
variables.
The old code used repeated calls to `ToUnicodeEx` to populate
the translation table, which is slow and buggy. The new code
directly loads the layout driver DLLs from Windows.
Associated issues: #2055#1033
Merge request: !1051
GdkWin32Keymap cleanup
Conform to C89, improve comments, whitespace
When a selection request fails to be converted to the requested format in the
GTK layers, the wayland backend would miss bumping the machinery to handle
further pending selection requests. Fix this by reacting to
GdkDisplay::send_selection_notify with target=GDK_NONE (i.e. a failed
conversion as hinted from the upper layers) to do that.
This ensures the clipboard handling doesn't lock up in the following
scenarios:
- GTK returned with a mismatching type to the one requested
- GTK fails to convert to the requested type
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4340
Setting variations to their default value causes
them to show up in the serialization of the font
description - a font description has no idea about
the default values, so can't filter them out.
Avoid that.
Rename README_EGL_MSVC.txt to README_FEATURES_MSVC.txt, as we now have
more features that can be included in the builds using the Visual
Studio projects, which require additional depedencies and manual
enabling.
Specifically, this outlines how the font tweaking feature in libgtk can
be enabled and for people who wish to do so, how to enable the Font
Features demo in gtk3-demo.exe.
...even if PangoFT2 is not present, provided that Pango 1.44.0+ and
HarfBuzz 2.2.0+ are installed. The demo now has added support for later
Pango versions that use HarfBuzz for shaping on all supported platforms.
...if Pango 1.44.0+ and HarfBuzz 2.2.0+ are available, otherwise we
stick on to the current code path.
This way, we can have people build and run the demo even without
PangoFT2 if Pango 1.44.0 or later and HarfBuzz 2.2.0 or later is
installed.
We can regenerate demos.h.win32 with or without the font features demo
by using the regenerate-demos-h-win32 target with or without secifying
the FONT_FEATURES_DEMO=1 flag on the NMake command line.
This way, we can share the demo listing to be used in other build
Makefile-based build systems, such as the auxiliary NMake Makefiles used
to generate the various sources.
...in the libgtk3 project, so that we can automatically link to
harfbuzz.lib if we have a sufficiently-new version of Pango and HarfBuzz
installed, so that the code to enable font features can be linked
properly, even if we don't explicitly put harfbuzz.lib in the list of
libraries that we feed into the linker in the project files.
If one is using pre-Pango-1.44.x and/or pre-HarfBuzz-2.2.0 and intends
to enable font features support, one still must update config.h.win32 to
make sure HAVE_PANGOFT2 and HAVE_HARFBUZZ is defined, and put
pangoft2-1.0.lib, harfbuzz.lib and freetype.lib (or so) in the
"Additional Libraries" under the linker settings in the projects
manually, as required before.
This is a backport of the code in GTK4 where we can use the font
features that is given to us via HarfBuzz if we have Pango 1.44.x and
HarfBuzz 2.2.0 or later installed, even if we do not have PangoFT2
aavilable.
Since Pango 1.44.x depends on HarfBuzz for all platforms after 1.44.0,
we could take advantage of that and build the support in
GtkFontChooserWidget.
Add a directive that is to be used by Visual Studio compilers via the
Visual Studio projects to link to harfbuzz.lib automatically, so that
this support can be linked properly if we have the required Pango and
HarfBuzz headers and lib's installed. Meson builds via Visual Studio
should handle this automatically, since pkg-config is being used there.
Since HAVE_PANGOFT2 and HAVE_HARFBUZZ is not defined by default in the
Visaul Studio projects, we will leave it up to the user to enable them
themselves and put in pangoft2-1.0.lib and harfbuzz.lib in the project
settings by themselves, or they could use Meson, as we did before.
When the compose file is a symbolic link, take the link itself's
modification time into account (in addition to its target's) in
determining whether to invalidate the compose cache.
This is useful e.g. on NixOS systems where the compose file might point
to a store path with an irrelevant modification time, and we want the
cache to expire when the symlink itself changes.
(cherry picked from commit 22f5236943)
Ping/pong serials are not meant to be interpreted as user input serials
(e.g. those given back later to the compositor on grabs). As a matter
of fact, Mutter uses a different count (i.e. timestamps) in these, so
using these serials may confuse the compositor into denying certain
operations like DnD.
In macOS-12.sdk CGContextConverSizeToDeviceSpace returns a negative
height and passing that to CGContextScaleCTM in turn causes the cairo
surface to draw outside the window where it can't be seen. Passing the
absolute values of the scale factors fixes the display on macOS 12 without
affecting earlier macOS versions.
Like the Visual Studio 2012+ projects, copy the Visual Studio 2010
projects and replace the items in there as needed, so that we can
obtain Visual Studio 2022 project files, since they are all in the
MSBuild format.
The rc.exe that comes with the Windows 11 SDK does not allow one to include
winuser.h directly in the .rc scripts, so make sure that we do not try to
generate the final gtk.rc with it, but instead include windows.h with
WIN32_LEAN_AND_MEAN defined.
The resource compiler in the Windows 11 SDK does not allow one to include
winuser.h directly in resource scripts (.rc) with a rather cryptic error
message, so fix generating the .rc file to embed the UAC manifest by including
windows.h with WIN32_LEAN_AND_MEAN instead.
Broadway is the only GTK+ backend that throws an error on stderr for a
"display server" connection failure.
This causes problems when gtk_init_check() is used and unexpected error
output is generated such as with hotdoc, which fails when generating a
GTK plugin's documentation instead of overlooking the issue.
"Unable to init server: Could not connect: Connection refused"
It is necessary to signal the search engine that we are finished and
that we found something for it to reliably show the results. It would
sometimes work anyway since it is sufficient if any backend signals
completion. However if GtkSearchEngineModel was the only backend
returning results then things would break.
MinGW-w64 CRT provides no 'hid.lib' file. Instead, it has 'libhid.a'
which can be linked with '-lhid' linker argument.
Also, we have to declare the '_LIBADD' variable and add 'LDADDS' to it,
or 'LDADDS' won't do anything for the build.
Note that gdk_monitor_get_geometry () returns DPI-scaled values,
while the screen offset should be unscaled, as scales are properties
of indivdual monitors.
An arithmetic operation involving a signed and an unsigned operand
of the same rank will have both operands converted to *unsigned*.
That's an issue if the signed operand actually has a negative value.
That was causing issues with the handling of monitor geometries that
had negative x / y positions.
Basically, I was building some packages on Guix. I figured out that
wayland-protocols was listed among propagated-inputs for gtk+ package
(gtk-3-24). propagated-inputs holds a list of runtime dependencies,
that should be available to any other package that depends on gtk+.
While discussing we clarified that wayland-protocols is not runtime
dependency. So I moved it to native-inputs of gtk+ package, which
means that, this dependency will be available only to gtk+ package and
only at build time. Once moved, building of other applications that
depening on gtk+ started to fail.
Investigation showed that, all .pc (pkg-config) files prepared by gtk+
package, was including:
Requires.private: ... wayland-protocols ...
Since it becomes requirement, other applications was failing with
missing dependency wayland-protocols of dependency gtk+, for instance:
-- Checking for module 'gtk+-3.0'
-- Package 'wayland-protocols', required by 'gdk-3.0', not found
While actually wayland-protocols is not even a build time dependency
of application that depends on gtk+. Advertisement of such
requirement, is a bit misleading, because one does not need it at
runtime, especially applications based on gtk.
Commit 68188fc948 introduces a workaround for clients that try to
change the size of a popup after it is created, but inadvertently
introduces an infinite loop of surface creation when the popup enters
two or more wl_outputs with different scales on creation.
This commit checks if the size actually changed before applying the
workaround and avoids the loop.
Gdk doesn't know the scale of output globals it didn't bind. This
keeps them from entering the output list and triggering erroneous
changes in surface scales.
gdkinternal-quartz.h isn't installed but the headers that included
it are, which which would cause the build to fail if an external
project included one of them.
Also changed the includes in gdkinteral-quartz.h to local for
faster loading.
...if GLES (libANGLE) support was enabled in the build. This way, we can
check whether the GL driver is capable enough to support the OpenGL
features that we use in GTK. If the driver is not capable enough, and
GLES support is enabled, we can try to create the GdkGLContext again as a
GLES context.
Group the WGL-specific code and GLES-specific code together, so that we
can reduce the number of #ifdef ... in the code, to make the code more
readable and easily maintained. This will pave the way to add a
fallback mode to use libANGLE (OpenGL/ES) in case the Desktop OpenGL
support is inadequte, if OpenGL/ES support is enabled in the build.
This is somewhat based on the updates that were done in GTK master, so
we are using one subclass for WGL-based GdkGLContexts, and another for
GLES-based GdkGLContexts.
Also remove the underscores in many of the functions in
gdkglcontext-win32.*.
Clean up the code a bit as a result.
When a popup is remapped, if the GdkWindow::x/y position is negative,
some best-effort hueristics used to ignore internal X11-style hackery
windows incorrectly scooped up remapped popup windows.
Avoid these hueristics by resetting the x and y fields of GdkWindow to 0
whe hiding a popup. It'll then appear as if it was newly initialized,
and escape the mentioned hueristics.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4071
Avoid diagnostics for gcc-11 false positive out of bounds accesses
See merge request GNOME/gtk!3064
(cherry picked from commit 5044031b53)
c514c41d Avoid diagnostics for gcc-11 false positive out of bounds accesses
While gtk-doc doesn't care, this isn't really valid Markdown as the
GtkBuilder custom XML tags will be considered valid markup and embedded
as they are, breaking the HTML output.
Like the recent updates in GTK4, the HWND that we use to obtain the HDC
that we need for OpenGL/GLES operations should really be tied to
GdkWindow, not GdkDisplay, as that is where the Win32 HWND where we
originate from is located, so stop storing the GL HWND in
GdkWin32Display, but just grab them from the GdkWindow that is bound to
the GdkGLContext.
We are more conservative about freeing up GL resources in GTK3, so we
will continue to call ReleaseDC() as we did before.
When a new sequence is added to a GtkGesture, its state is looked
in other gestures in the same group, and made to match in this
gesture. This however happened a bit too early, before the
gesture touchpoint was fully set up. As this may result in signal
emission and whatnot, it's a good idea to make it happen with a
fully set up touchpoint.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3946
(Cherry-picked from commit 53df32e6cf)
Set all settings to their default values, so we
are less dependent on the environment to be set
up just right. In particular, this fixes animations
being disabled when we happen to run in a vm.
It apparently worked by chance in the past, but now causes e.g.
alphanumeric characters to be interpreted as half-width katakana
when using the Japanese IME.
GtkContainerCellAccessible wasn't unsetting accessible
parents. Fix that.
By itself, this doesn't help for freeing a memory leak,
since AtkObject keeps a ref on its parent, so we never
free the GtkContainerCellAccessible as long as it has children.
Using pyatspi.utils.findDescendant() on the GtkFileChooserDialog using
just a role would return the Dialog, as they have the same "file
chooser" role. So we have to give it a name to distinguish between
them.
Given that the format changed, not to break current user history we can
keep using the old format for saving and reading the emoji-recent
gsettings key, by converting the new data to the old one at save time.
We loose information about the short name (not really relevant), even it
could be saved using the first keyword, but this isn't really relevant.
Differently from the meson case, here we just include the emoji data
files into the global gresources file, get_emoji_data() supports this
and it's just easier to handle in these build systems.
Use the data files from https://github.com/milesj/emojibase.git
as source for our Emoji data. Slightly change our data format by
adding a group to each item, in both the Emoji data and in the
setting for recent-emoji.
Install translated versions of the data as separate resource
bundles in $prefix/gtk-4.0/emoji, and load them when appropriate.
Currently, we have data for de, en, es, fr, zh, with data taken
from Unicode 13 and CLDR 13.
Fixes: #950#1511
Don't close the Emoji chooser when the Control
key is held while clicking. So you can insert
multiple Emoji without having to reopen the
chooser every time.
Fixes: #1002
If the recent section is empty, we want to hide
it, make its button insensitive, and select the
next section, initially. This was not working
properly, since nothing was ever setting the
section box to invisible.
Width and height of a GdkMonitor are derived via wl_output which
talks about physical dimensions of a device and compositors usually
implement this as the untransformed values (e.g. weston, wlroots).
Since the GTK client has no way to figure out if a monitor was rotated,
transform the physical dimensions according to the applied wayland
transform to have the physical dimensions match the logical ones.
Mutter flips the physical dimensions itself but doesn't announce the
transform so this shouldn't break anything there.
New release function _gdk_quartz_drag_source_context_destroy_gtk_only
gets called when drag fails to start or is cancelled as well as
when it successfully completes.
Some GL drivers such as Mesa-D3D12 do not allow one to call SetPixelFormat() on
a given HDC if one pixel format has been already set for it, so first check the
HDC with GetPixelFormat() to see whether a pixel format has already been set
with the HDC, and only attempt to acquire the pixel format if one has not been
set.
This will fix running with GL on Windows using the Mesa drivers.
The guards weren't working because we were accessing data inside the
arguments before checking them. Postpone data access until after the
guards.
0x00007ffff741203c in gtk_box_pack (box=box@entry=0x0, child=0xe0b1b0, expand=expand@entry=0, fill=fill@entry=0, padding=padding@entry=0, pack_type=pack_type@entry=GTK_PACK_START)
at /usr/src/debug/gtk3-3.24.28-2.fc34.x86_64/gtk/gtkbox.c:1530
1530 GtkBoxPrivate *private = box->priv;
(gdb) bt
#0 0x00007ffff741203c in gtk_box_pack (box=box@entry=0x0, child=0xe0b1b0, expand=expand@entry=0, fill=fill@entry=0, padding=padding@entry=0, pack_type=pack_type@entry=GTK_PACK_START)
at /usr/src/debug/gtk3-3.24.28-2.fc34.x86_64/gtk/gtkbox.c:1530
#1 0x00007ffff741223c in gtk_box_pack_start (box=box@entry=0x0, child=<optimized out>, expand=expand@entry=0, fill=fill@entry=0, padding=padding@entry=0)
at /usr/src/debug/gtk3-3.24.28-2.fc34.x86_64/gtk/gtkbox.c:2179
Previously it was impossible to compose characters on higher levels of
some keyboard layouts as pressing the level selection key would just
exit compose mode.
Examples for affected keyboard layouts include the Latvian
apostrophe-variant "lv(apostrophe)" (latched third level), the extended
German keyboard layout "de(e1)" (latched fifth level) as well as the
multilingual Canadian keyboard layout "ca(multix)" and the German
neo-layout "de(neo)" and its descendants (shifted fifth level).
To reproduce, set a compose key and select the Latvian apostrophe layout.
Notice that you now can input [ by pressing first the ' and then the 8-key.
Then pressing <compose>'8'8 should produce ⟦, but prior to this patch it
did not.
Some locations have to be mounted, but their mounts are not user-visible
(e.g. smb-browse). Though this is maybe a bit weird, it is how it works
for years. The problem is that the commit 267ea755, which tries to get the
default location for opening, caused regression as it doesn't expect such
possibility. Before this commit, such locations were opened without any
issue, but nothing happens currently after clicking to "Connect" except of
clearing the "Connect to Server" entry. Let's fallback to the original
location if the mount was not found to fix this regression.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1811
... if we're not using indicators and the policy may be visible. Not
doing this if the policy may be invisible is incorrect as we need to
reserve the space anyway in case the scrolledwindow is allocated at
minimum size and the child size increases to show the scrollbar.
Some applications need to access gdk_quartz_window_get_nsview,
gdk_quartz_window_get_nswindow, and gdk_quartz_event_get_nsevent
so move these from the private gdkquartz-gtk-only.h to a new
header gdkquartz-cocoa-access.h. Don't include this header in
gdkquartz.h so that user code that doesn't need to access these
functins isn't required to compile with Objective C/C++.
Closes https://gitlab.gnome.org/GNOME/gtk/-/issues/1737
We can just group the code for the desktop GL codepath and the EGL
codepath a bit so that we can just have a single location where we
return TRUE upon a successful setup of our WGL/EGL context, and avoid
the C4715 warning that is considered an error when building with
GLib-2.68.x or later using Visual Studio, when we are building without
EGL support.
Avoid passing through random key press or release
events while we are showing preedit. That prevents
'accidents' like typing Ctrl-. bringing up the
Emoji chooser during preedit, or hitting Ctrl-a
after the Compose key moving the 'dot' around in
vim in terminals.
The condition we check for to catch X servers going away
may not be accurate anymore, and the warning shows up in
logs, causing customers to be concerned. So, be quiet by
default, unless the user explicitly asked for a message.
GtkBox is not going away, so there's not point in making things more
confusing for those who are still porting their code from GTK2 to GTK3
10 years after GTK 3.0 was released.
Fixes: #3854
gtk_css_node_update_layout_attributes can cause us to
free priv->layout, and then bad things happen. Therefore,
we must call that function on a new layout *before* setting
priv->layout.
When we don't get stettings from the portal, the current
fallback is 'awful fonts'. There is no need for that. Instead,
set the fallback values to grayscale antialiasing with slight
hinting.
The preprocessor directives for proper OS version support are missing
their last digit, rendering the checks defunct.
Improves on https://gitlab.gnome.org/GNOME/gtk/-/issues/3592 but does
not fully fix as other issues have surfaced down the line.
This was breaking muscle memory of people with
the us intl keyboard layout, for important keys
such as '. The unfortunate side-effect is that
our handling of <dead_acute> is a bit hampered
by sequences that don't fit the pattern. But
such is life.
Fixes: #3807
If we scroll down in a list that's still being filled, we hit the edge and
initiate overshoot, and then the adjustment's upper value increases. This
leads to an unwanted bounce back.
Additionally, if in a similar situation the upper value decreases, the
overscroll glow gets stuck.
Update kinetic scrolling upper and lower value on changes, and immediately
cancel it if dimensions on that side change.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3752
... until all globals have been received.
The dependency tracking introduced in 4e9be39518 only allows to
specify required globals and processes the closures as soon as
the requirements have been met. There are, however, also optional
dependencies - most notably the primary_selection protocol.
Currently we rely on the fact that compositors like Mutter announce
it before `wl_seat`, even though the order is not specified in
the spec.
Process globals closures only after all globals have been announced,
so optional dependencies can be accommodated.
Closes https://gitlab.gnome.org/GNOME/gtk/-/issues/3791
The documentation states that GTK will load a Compose
file from ~/.config/gtk-3.0/Compose. Unfortunately,
backports changed this unintentionally to look in
the gtk-4.0 directory. Change it back.
Reshuffle things to allow for a limited amount of
dead key 'chaining'. We keep up to 2 dead keys in
the preedit, so you can type
<dead_acute> <dead_cedilla> <c>
to produce ḉ, while still getting ```c with
<dead_grave> <dead_grave> <dead_grave> <c>.
The DnD code for X11 adds the composite overlay window (aka COW) to the
cache.
Yet the X11 requests to get and release the COW may trigger XErrors that
we ought to ignore otherwise the client will abort.
Fixes: #3715
Update our compose sequences based on the current
update xorg Compose.pre file. Beyond that, remove
some deadkey sequences that we are now handling
(better) in code.
Make this script parse gtk-compose-remove.txt for
sequences to remove from the xorg Compose file.
This will be used for removing some deadkey combinations
that we can handle better in code.
Also, make this script explicitly python2. I tried
porting it to python3, but gave up in the end.
For sequences like ``, we want to commit the first
deadkey and then continue preedit with the second.
The alternative is to do chained deadkeys, where
entering ~~a yields ̃̀̃̃a. But we don't do that, and
I think that would be more controversial.
because filesystem readdir order is indeterministic.
Without this patch, building openSUSE's balsa package
had variations between builds in /usr/share/balsa/icon-theme.cache
(cherry picked from commit b364827a5b)
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
This can happen whenever the ::activate-link handler sets different
markup on the label, causing all links to be recreated. In this case,
the GtkLabelLink* passed to emit_activate_link is garbage after the
g_signal_emit call and we shouldn't try to do anything with it.
Fixes#1498
Partially fixes issue #2191 regarding switching to another app while
hovering a stylus over a drawing tablet causes subsequent mouse
clicks in the app to be ignored. I was not able to reproduce the
other behavior described in #2191 concerning tiling a window.
56f6ac5f introduced a 20px shadow for the '.tiled decoration:backdrop'
selector. This selector is more specific than the '.ssd decoration'
selector and caused unfocused tiled SSD windows to have a shadow that
focused ones did not have. The mutter code however assumes that the size
of the decoration does not change between the states and this was
causing a crash when clicking below the titlebar in unfocused tiled SSD
windows.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3716
It turns out that we we were sometimes emitting
preedit-end multiple times, and sometimes not at
all. Same for preedit-start. To fix this up, introduce
a in_compose_sequence flag, maintain it, and use it
in the right places.
After these changes, both
C-S-u 1 2 3 Enter
Compose a e
generate the right signals:
preedit-start, preedit-changed,..., preedit-end, commit
This will make GTK_HOST defined more like what it is on Meson builds, so that
we set the host string appropriately according to the build that is being
carried out, instead of defaulting to i686-pc-vsXX for all builds.
Like the previous commit on win32/config-msvc.mak.in, this now sets GTK_HOST
to be:
i686-pc-vsXX for 32-bit x86 builds
x86_64-pc-vsXX for x64 builds
aarch64-pc-vsXX for ARM64 builds (requires VS2017 15.9.x or later)
Currently, introspection is not well-supported for ARM64 Windows builds as:
* There is no official Python release for ARM64 Windows, but it is currently
possible to build it with sufficient support for G-I, however...
* The tooling in Python still needs to be updated to enable ARM64 Windows
builds for use with g-ir-scanner and friends, and...
* Introspection builds must be done on an ARM64 system, since we are running a
dumper binary to generate the .gir files
This will attempt to prepare things for building GTK's introspection files on
Windows ARM64, but will require a custom installation of Python as noted above,
for the time being
Instead, rely on the mechanism that we already have to set the platform string
appropriately, eg:
i686-pc-vsXX for 32-bit x86 builds
x86_64-pc-vsXX for x64 builds
aarch64-pc-vsXX for arm64 builds
Don't warn about Compose file constructs we don't
support. We haven't supported these for a long time,
and nobody has every complained. No need to wake
up sleeping dogs.
Tweak the preedit text we get from IBus (via the compositor) to
match what GtkIMContextSimple produces for Compose sequences now.
This provides a unified experience.
Tweak the preedit display for Compose sequences to
be not so distracting. We only show the Compose key
when it occurs in the middle of the sequence or is
the only key so far, and use · instead of ⎄ for it.
Also, make sure to display dead keys more adequately.
Use the infrastructure already available to look up keys, instead.
This does the right thing and looks up the setting across all
sources.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3680
- window resizing control area is implemented as where the shadows are drawn
- create a 'fake' shadow for the tiled case to allow easier resizing of
the tiled window ratio even if it's offset to the side of the border
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3670
X11 allows keysyms to be specified in addition to strings.
We only support the strings. In the past, we ignored everything
after the string. Go back to doing that, but issue a warning
that we've ignored the keysym.
This is useful when clients use subsurfaces independently of GDK.
For example if a client creates a subsurface that covers a GdkWindow
entirely. If this subsurface is opaque, Wayland compositors may not
emit callbacks for the surface of the GdkWindow any more.
Adding the covering subsurface via this new API ensures the
GdkWindow will continue to update in this case.
These shadows cause a significant draw performance drop for maximized
windows. Disabling them increases the chances we can have faster scroll
performance of text.
There is some risk here for systems where they have a dock and you expect
the shadow to draw beneath that dock for transparency reasons.
Improve compose sequence handling:
- Show preedit for compose seqences
- Support sequences of up to 20 code points
- Warn when ignoring Compose file features
- Support compose sequences producing multiple characters
- Support hex escapes
This commit unsubscribes CUPS backend from a DBus
signal in idle when listening for new items on Avahi.
Since GDBus emits gathered signals in idle while
checking whether the signal has been unsubscribed
it could happen that a signal was not processed
because it was removed from hash table of
subscribed signals.
This caused the situation where printers advertised
on Avahi were not listed in CUPS backend sometimes.
We need those signals since this happens when switching
from a general subscription which listens to signals
for all Avahi services to a specific one which listens
to just _ipp._tcp and _ipps._tcp (chicken and egg problem).
This change extends set of Avahi advertised printers which
works with Gtk's CUPS print backend.
It creates a temporary queue (local printer) for each
Avahi printer in CUPS instead of accessing them directly
(via CUPS library).
This makes some printers work which did not work before and
also gives users more options to change in the print dialog.
This also changes naming of printers to be in accordance with CUPS.
It uses '_' instead of '-' and has hostname appended for CUPS remote
printers.
As the program executable name has 'update' in its filename,
gtk-update-icon-cache.exe is considered to be an installer program on 32-bit
Windows [1], which will cause the program to fail to run unless it is running
with elevated privileges (i.e. UAC).
Avoid this situation by embedding a manifest file into the final executable
that tells Windows that this is not a program that requires elevation.
Also make the autotools build files dist the new script and use the new script
to generate the manifest and rc files, instead of hardcoding the generating
bits in gtk/Makefile.am
Fixes issue #3632.
[1]: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-vista/cc709628(v=ws.10)?redirectedfrom=MSDN,
under section "Installer Detection Technology"
Currently when GTK3 is compiled without G_ENABLE_DEBUG, the inspector
can't be opened with GTK_DEBUG=interactive because it doesn't parse
this env var without G_ENABLE_DEBUG.
Since the inspector is always good to have, this commit now always
parses the GTK_DEBUG env var but only keep the "interactive" flag if
G_ENABLE_DEBUG isn't defined.
Commit e6209de962 added some checks on TranslationEntry.valid in
order to figure out whether using the new font settings or the
old g-s-d ones. However that's only set in the non-sandboxed case.
This makes sandboxed applications fallback to the old (and also
non-existing with modern g-s-d) settings, possibly resulting in
ugly defaults being picked.
Fix this by also marking TranslationEntry elements as valid when
using the settings portal, precisely those entries that we are able
to read and match with our own table.
When destroying a wl_surface (e.g. when a window or menu is closed), the
surface may continue to exist in the compositor slightly longer than on
the client side. In that case, the surface can still receive input
events, which need to be ignored gracefully.
In particular, this prevents segfaulting on wl_surface_get_user_data()
in that situation.
Reported in
https://gitlab.gnome.org/GNOME/gtk/-/issues/3296
The same issue for pointers/keyboards was reported in
https://bugzilla.gnome.org/show_bug.cgi?id=693338
and fixed with in
bfd7137ffb3625f17857a8fc099a72
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
When the level does not include the style, we only
include one face of each family in the list. But we
were just choosing the first face (typically, a light
or extra-light style). Improve this by picking the
default face (normally, the regular face), which is
the expected behavior.
When setting a window's background to ParentRelative on X11, the window
depths must match to avoid a BadMatch error. Query the X server for the
parent window rather that relying on the parent passed to
gtk_window_new() to prevent crashes with reparented windows.
Fixes: #3288
The last event, matching lifting the finger/releasing the mouse button,
is important when there's a large delay between it and the previous events,
as in when performing a movement, stopping, then releasing fingers as
opposed to doing a swipe.
If this event is skipped, doing this will result in kinetic deceleration
matching the previous finger movement, while the expected behavior would
be no deceleration.
See also 97f540622a for a similar fix in
GtkEventControllerScroll.
When GtkApplication starts listening to the screensaver's D-Bus
status, the screensaver-active property is not initialised and
applications making use of the property are out of sync until the
first state change. Any application starting when the screensaver is
active will think it's inactive.
To fix this, we set the property when we first start monitoring the
screensaver.
See https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1091
epoxy_dep cannot be used in a configure time check when it comes from a
subproject. Use variables set in pc file instead.
This requires https://github.com/anholt/libepoxy/pull/231.
Remove all of the selectors. They just set the passthrough anyway so
there's not much point to maintaining them and they weren't the
complete set of possible selectors.
While it’s true that you can pass the results of
`gtk_file_chooser_get_filename()` straight to `open()` or `fopen()` on
Linux, you can’t do so on Windows as it expects the filename to be in
the ANSI codepage. Using the GLib wrappers `g_open()`/`g_fopen()`
instead means that the appropriate UTF-8 → UTF-16 → `wopen()`/`wfopen()`
conversions are done.
Spotted by Fabian Keßler in
https://gitlab.gnome.org/GNOME/glib/-/issues/2212.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When a plug is embedded in a socket, we need to also plug the at-spi
tree, so that screen readers can find the at-spi content of the plugged
widgets.
This change does this plugging automatically: on the plug widget, an
additional _XEMBED_AT_SPI_PATH property is set to provide the at-spi path
(just like we have _XEMBED_INFO for other X11 information), and when
embedding it, the socket reads it, and makes it as its only child.
Since GtkPlugAccessible can not inherit both from AtkPlug (a child of
AtkObject) and from GtkContainerAccessible (a child of AtkObject), we
actually make GtkPlugAccessible a child of an AtkPlug, and that's what
will be embedded (in at-spi terms) into an AtkSocket.
Similarly, GtkSocketAccessible can not inherit both from AtkSocket and
GtkContainerAccessible, so we make it a parent of the AtkSocket that
embeds the AtkPlug.
This change depends on atk 2.35.1 which implements the at-spi technical
details.
This separates out atk-bridge-2.0 dependency, which is not part of atk,
but of at-spi2-atk.
At least from GTK v3.22.30, the code disallows attempts to print PDF and
PS files using the LPR backend. Although it is not easy or possible for
GTK to determine if the printer can print these formats by querying lpr,
the print backend should allow lpr to try.
There are two uses cases:
- A filter is being used by lpr, specified in the printcap file, to process the
files prior to printing them.
- The printer can print PDF and PS files directly. There are many printers that
can print these formats, so GTK should allow for the possibility.
This implementation is based on gtk_text_view_scroll_to_iter() and
thus shares its limitations for the sake of simplicity.
A single offset is opportunistically picked to build the iterator
needed for gtk_text_view_scroll_to_iter(). That means that substrings
spanning over multiple lines or larger than the current window might
not be displayed optimally after scrolling.
Partially closes#1625, the toPoint() variant has been discarded.
_gtk_settings_get_style_cascade() checks for the given GtkSettings to be
non-NULL, but does so after using the pointer to get the
GtkSettingsPrivate.
Make sure we use the GtkSettings pointer only after the precondition is
verified.
https://gitlab.gnome.org/GNOME/gtk/-/issues/2780
On gdk_display_close(), the GtkSettings attached to the display are
freed.
Yet the gtk CSS code may still be called from the widget unparent,
leading to a segfault.
Check if the GtkSettings is not NULL and bail out nicely if not.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2780
Additionally to gtk_primary_selection, the gtk-private predecessor,
support the upstream unstable protocol.
This allows the primary selection to work on Kwin and potentially
other compositors, as well as dropping the private version eventually.
Closes https://gitlab.gnome.org/GNOME/gtk/-/issues/2591
When installing the scroll cursor, add a weak ref to scrolled_window
that clears it if finalised. Unset the weak ref when the uninstalling
the cursor, and when the widget is destroyed.
Patch by Michael James Gratton
Fixes: #749
If a GtkScrollable uses a different scale than pixels the offset from a
drag must be adjusted to match this scale. This fixes issues like this
https://gitlab.gnome.org/GNOME/vte/-/issues/283 where the terminal
widget uses rows instead of pixels as its scale for each GtkAdjustable
thus causing a 1 pixel vertical drag to scroll 1 row.
In gtk_tree_view_build_tree with recurse=TRUE, the TEST_EXPAND_ROW
signal might invalidate the child iterator. Getting the iterator after
the signal (instead of before) fixes the issue.
Fixes https://gitlab.com/inkscape/inkscape/-/issues/1879
Path concatenation is much nicer than the unwieldy format method.
Since paths returned by get_option are relative to prefix, they will be joined as before.
As a bonus, this fixes weird platforms like NixOS that actually pass absolute includedir under a different prefix.
Due to the deprecation in gtkshow.h, there is proper deprecation warning
for C code. But, for bindings (python in one case), there is no warning,
due to missing "Deprecated:" annotation in gtkshow.c
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3166
When a fixed size is active (e.g. the window is maximized),
gtk_window_resize() shouldn't take immediate effect, so the request was
dropped. This made GTK unhappy if this happened, it will freeze updating
the window until it received the new size it demanded.
Handle this by being nice and emitting a dummy GDK_CONFIGURE event with
the old size where we previously ignored it. It won't resize the window
immediately, so it shouldn't have a visible effect, and the size GTK
requested is still saved away for when the window is unmaximized, but
emitting the event will make GTK receive the event it expects.
We still drop the request on the floor, e.g. if we still haven't seen
the initial configuration, just as we do when actually doing the resize.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2907
This is not only a GdkEventButton but can also be a GdkEventTouch.
Having this annotation wrong causes bindings code to fail whenever a
wrongly typed event comes through.
Given it does seem likely Tracker is going to miss the goal to get all
applications ported to Tracker 3, the scenario where there's applications
linking to Tracker 2.x while GTK was built with Tracker 3 support becomes
more likely.
Avoid the upcoming GType clashes if that were the case, and resort to the
good (I lie) old Tracker 2 search engine.
This device may go away, which means we have a pointer to a possibly
stale object. Keep a reference here, and let future events bring this
accounting up-to-date when the mouse pointer is next updated via other
device.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/855
When using the gdk_display_close(), the handle to the Wayland compositor was not released.
This could cause the consumption of all available handles, preventing other processes from accessing the display.
Fixing this by calling wl_display_disconnect() when releasing the GdkWaylandDisplay object.
Signed-off-by: Julien Ropé <jrope@redhat.com>
Handle both these settings, and the older settings-daemon ones for
backwards compatibility. The keys are already checked for existence
in the schema, so it will just use the existing ones.
Prefer this location, but also look for the old location in
settings-daemon for backwards compatibility. This applies to both
direct settings lookups and via the settings portal.
Previously, a GDK application handled the Wintab cursors (stylus,
eraser, etc.) only during app initialization. If new cursors were
recognized by Wintab during app execution, the app would not know
about them.
This fix still handles Wintab cursors known during app initialization.
In addition, when Wintab recognizes new cursors and notifies the app
via a WT_CSRCHANGE message, the app handles the new cursors, creating
new Wintab device objects for them.
Closes#1549
CUPS uses resource paths in the form of "printers/printer_name"
or "classes/class_name" so it is enough to remove the "printers/"
or "classes/" prefix and use the string behind it as a name.
There was recently introduced a wrong check for the prefix.
This commit fixes it in the way it was originally intended.
This may need to be changed next year, it depends on what Apple
decides to do with version numbers going forward.
Also updated GdkOSXVersion to include Catalina and Big Sur.
When asking for a password, the message string is split on primary
and secondary if it contains a newline character. However, the newline
character is currently part of both strings, which creates weird
spacing between the GtkLabels. I suppose this is bug, which was not
visible as in most cases (if not all) the message string hasn't
contained the new line characters so far. But we are going to change
that now, see GNOME/gvfs!82. Let's drop the new line character similarly
as it is done when asking for a question, or showing processes in order
to fix the weird spacing.
Update the NMake Makefiles to invoke glib-compile-resources with
'start /min' so that when gdk-pixbuf-pixdata, json-glib-format
and xmllint are invoked by glib-compile-resources, cmd.exe windows
will not popup whenever these auxiliary tools are invoked, when one
builds GTK with the Visual Studio projects.
This will reduce the distraction that is caused during the time the
source files are generated, as a popup cmd.exe window will disrupt the
window focus as they appear, and will make the process a bit quicker.
This avoids the build from erroring out on C4819 (Unicode handling issue in
Visual Studio compiler), notably when running on Chinese, Japanese and
Korean locales.
Instead of using the incomplete GTK-internal emulation, use the WM_CHAR
messages sent by Windows. Make the IME input method the default for all
languages on Windows.
This code made use of isnan(), which is not provided by pre-2013 Visual
Studio, so fix the build by including fallback-c89.c in place of math.h,
and update fallback-c89.c to include the implementation of isnan() for
Visual Studio, which is copied from the fallback-c89.c in gdk/.
When a window receives a resize request, it might ignore this new size and
use the compositor's size hints instead to restore to floating mode.
This commit changes that behaviour in that a window will always prefer
the manually resized dimensions over the compositor's hint.
On Visual Studio, Cairo could have been found manually by looking for the .lib
files, and the previous update to fix this was incorrect, as it added the
libraries to the required packages instead of the required libraries. This
fixes this mishap
The 'select-all' signal requires a boolean argument to specify
whether to select all or none. So explicitly pass TRUE to select
all text instead of letting the demons choose one for us.
This makes the desired behaviour explicit, and matches the behaviour
seen with Meson, where "external : false" is the default.
Before GNOME/glib!1468, not passing --internal to the resource compiler
meant "no special export attribute, do what you would normally do",
so these symbols were not exported due to our global use of
-fvisibility=hidden.
However, since GNOME/glib!1468, not passing --internal to the resource
compiler results in the symbols being decorated with G_MODULE_EXPORT,
which overrides -fvisibility=hidden. This was necessary because Windows
DLLs normally behave a bit like the equivalent of ELF libraries with
-fvisibility=hidden.
Signed-off-by: Simon McVittie <smcv@debian.org>
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/2919
Add --enable-tracker3 option (off by default, like in meson) and
hook the tracker3 search engine to build. Also, make sure it's part
of dist.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2912
Input devices such as stylus pens have additional axes besides (x,y)
coordinates. In order for these devices to work properly, their additional
axes need to be mimicked from the physical device to the associated
virtual pointer when they become active.
If GLES support is enabled on Windows, force GLES mode if we are running
on a ARM64 version of Windows (i.e. Windows 10 for ARM).
This is required as ARM64 versions of Windows only provide a software
implementation of OpenGL 1.1/1.2, which is not enough for our purposes.
Thus, we could make instead use the GLES support provided via Google's
libANGLE (which emulates OpenGL/ES 3 with Direct3D 9/11), so that we
can run GtkGLArea programs under OpenGL/ES in ARM64 versions of Windows.
Note that eventually we could update the libepoxy build files for Windows
to not check nor enable WGL when building for ARM64 Windows, as the WGL
items do not work, although they do build.
For some reason modules/input adds the C code that is generated by
wayland-scanner to EXTRA_DIST. This results in a race where depending
on the timestamps of the tarball and the timestamp of the system
wayland-protocols either the generated source in the tarball or a
regenerated source will be used.
This doesn't actually impact the code generated, but it does break
reproducible builds as the list of source files changes.
When making changes above the current visible region, we might need to
invalidate the pixelcache as the Y positions will no longer match. This
usually is not needed because changes are made interactively and are made
onscreen.
Other cases, though, can include an application changing the first line
of the buffer automatically. We lose the ability to pixelcache well in
this scenario, but that is unlikely an issue since rapid Y geometry resize
or scrolling is less likely to be occuring. For situations where this is
an issue, you can avoid removing the \n from the buffer so line heights
are uneffected.
Fixes#2882
The pkg-config variables have been added in GLib 2.62.0. Let's fallback
to default names for these tools in such case (`pkg-config` still
returns a 0 return value, but with empty output for absent variables).
Some distributions are renaming Glib/GIO utilities for multi-arch
reasons so pkg-config variables have been added to find the correct name
of a tool. GTK+ should use these variables instead of searching in PATH.
See glib#1796.
The Quartz Window Manager adds to the Windows menu all NSWindows with
titles. Since we assign a default title to all windows that produced a
rather cluttered Windows menu containing among other things dialogs.
Setting aside that dialogs don't belong in the Windows menu, if
a dialog was hidden for reuse instead of destroyed it would persist in
the Windows menu and if clicked there would show, but because it wasn't
running wouldn't respond to events and so couldn't be hidden again and
would remain on top of its parent window.
Ref: https://bugs.gnucash.org/show_bug.cgi?id=797807
This patch implements the openFiles delegate which is required
to open files which are associated with an application via the
Finder or via open on the command line. The patch has been
proposed by jessevdk@gmail.com.
See: https://gitlab.gnome.org/GNOME/gtk/-/issues/463
I tested the patch with the GNU pspp application on MacOS with
the quartz backend.
gtk_file_chooser_get_filter Make gtk_file_chooser_get_filter work for the non-portal GtkFileChooserNative (issue #1820)
See merge request GNOME/gtk!1959
Fix scheduling of the frame clock when we don't receive "frame drawn"
messages from the compositor.
If we received "frame drawn" events recently, then the "smooth frame
time" would be in sync with the vsync time. When we don't receive frame
drawn events, the "smooth frame time" is simply incremented by constant
multiples of the refresh interval. In both cases we can use this smooth
time as the basis for scheduling the next clock cycle.
By only using the "smooth frame time" as a basis we also benefit from
more consistent scheduling cadence. If, for example, we got "frame
drawn" events, then didn't receive them for a few frames, we would still
be in sync when we start receiving these events again.
When an animation is started while the application is idle, that often
happens as a result of some external event. This can be an input event,
an expired timer, data arriving over the network etc. The result is that
the first animation clock cycle could be scheduled at some random time,
as opposed to follow up cycles which are usually scheduled right after a
vsync.
Since the frame time we report to the application is correlated to the
time when the frame clock was scheduled to run, this can result in
uneven times reported in the first few animation frames. In order to fix
that, we measure the phase of the first clock cycle - i.e. the offset
between the first cycle and the preceding vsync. Once we start receiving
"frame drawn" signals, the cadence of the frame clock scheduling becomes
tied to the vsync. In order to maintain the regularity of the reported
frame times, we adjust subsequent reported frame times with the
aforementioned phase.
GTK+ 3.0 was currently using GL_EXT_framebuffer_object, which is
deprecated as the ARB version has been merged into OpenGL 3.0 as well as
OpenGL ES 2.0, and provides laxer requirements.
This adds a "release" destructor for the gtk_surface1 interface which
signals to the server that a surface has been destroyed on the client
side, which the current "destroy" does not do.
Ideally the protocol would have specified a destroy request marked as
destructor to handle this automatically, however this is no longer
possible due to the destroy method being implicitly generated in the
absence of an explicit request in the protocol. Adding a destroy request
marked as destructor now would generate a new destroy method that
unconditionally would send the request to the server, which would break
clients running on servers not supporting that request.
`gtk_builder_get_parameters()` is a hot path, being called twice for
each object in each UI file in an application. The majority of objects
have ≤ 8 properties, which are each filtered into either `parameters` or
`filtered_parameters`.
Unfortunately, both of those arrays are created as empty `GArray`s, and
adding 8 elements to an empty `GArray` hits the worst possible case of
reallocating and `memcpy()`ing the array 3 times. As the array size is
doubled with each reallocation, the cost is not particularly well
amortised when the array size is small.
From the `ObjectInfo`, we actually know how many properties there are in
total, so just allocate the arrays at the right size to begin with.
This saves 7% of the instruction cycles needed to start up
gnome-software to the point where it’s showing its main window,
according to callgrind. gnome-software is making around 5500 calls to
`gtk_builder_get_parameters()`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This makes 'gtk_file_chooser_get_filter' work for the
portal native file chooser by handling the corresponding
'current_filter' argument in the response retrieved via
D-Bus.
In order to try to map the retrieved 'current_filter' to one
of the existing list of filters, use the retrieved filter's name,
similar to how xdg-desktop-portal-gtk does it when evaluating the
'current_filter' input parameter in 'options'.)
Note: This depends on the following merge/pull requests
which fix the filter handling in gtk for native file choosers
and introduce the 'current_filter' handling for FileChooser portal.
* https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1959
* https://github.com/flatpak/xdg-desktop-portal/pull/493
* https://github.com/flatpak/xdg-desktop-portal-gtk/pull/311
This fixes#1820 for desktop portal case.
Fixes: #1820
When the application does not receive "frame drawn" signals we schedule
the clock to run more or less at intervals equal to the last known
refresh interval. In order to minimize clock skew we have to aim for
exact intervals.
(cherry picked from commit f5de46670b)
We try to step the frame clock in whole refresh_interval steps, but to
avoid drift and rounding issues we additionally try to converge it to
be synced to the physical vblank (actually the time we get the
frame-drawn message from the compositor, but these are tied together).
However, the convergence to vsync only really makes sense if the new
frame_time actually is tied to the vsync. It may very well be that
some other kind of event (say a network or mouse event) triggered
the redraw, and not a vsync presentation.
We used to assume that all frames that are close in time (< 4 frames
apart) were regular and thus tied to the vsync, but there is really no
guarantee of that. Even non regular times could be rapid.
This commit changes the code to only do the convergence-to-real-time
if the cause of the clock cycle was a thaw (i.e. last frame drawn and
animating). Paint cycles for any other kind of reason are always
scheduled an integer number of frames after the last cycle that was
caused by a thaw.
(cherry picked from commit 91af8a705b)
When we get to a paint cycle we now know if this was caused by a
thaw, which typically means last frame was drawn, or some other event.
In the first case the time of the cycle is tied to the vblank in some
sense, and in the others it is essentially random. We can use this
information to compute better frame times. (Will be done in later
commits.)
(cherry picked from commit 82c314f1af)
When we run the frameclock RUN_FLUSH_IDLE idle before the paint,
then gdk_frame_clock_flush_idle() sets
```
priv->phase = GDK_FRAME_CLOCK_PHASE_BEFORE_PAINT
```
at the end if there is a paint comming.
But, before doing the paint cycle it may handle other X events, and
during that time the phase is set to BEFORE_PAINT. This means that the
current check on whether we're inside a paint is wrong:
```
if (priv->phase != GDK_FRAME_CLOCK_PHASE_NONE &&
priv->phase != GDK_FRAME_CLOCK_PHASE_FLUSH_EVENTS)
return priv->smoothed_frame_time_base;
```
This caused us to sometimes use this smoothed_frame_time_base even
though we previously reported a later value during PHASE_NONE, thus
being non-monotonic.
We can't just additionally check for the BEGIN_PAINT phase though,
becasue if we are in the paint loop actually doing that phase we
should use the time base. Instead we check for `!(BEFORE_PAINT &&
in_paint_idle)`.
(cherry picked from commit a36e2bc764)
The included fribidi header is not used in gdkkeys-wayland.c and already
included in gdk.c which causes linker issues due to the header defining
a global variable.
Currently .tile style is required for the larger blue checkboxes.
The .tile style is removed since it adds unwanted style to elements.
Also the selector to ignore list elements has been modified since
it currently checks for checkboxes that are not lists.
Before I tried this change, I thought it might break apps that do
transparent window background. So I checked a few that did this:
gnome-terminal, tilix, kgx. It worked, so it must work everywhere, right?
However, it just so happens that vte is drawn using CAIRO_OPERATOR_SOURCE
operator rather than CAIRO_OPERATOR_OVER like everything else. This means
that if vte widget is transparent, anything below it, like a black
decoration background, won't be shown.
So really it is still broken, so reverting it.
A call to frame gdk_frame_clock_get_frame_time() outside of the paint
cycle could report an un-error-corrected frame time, and later a
corrected value could be earlier than the previously reported value.
We now always store the latest reported time so we can ensure
monotonicity.
(cherry picked from commit a27fed47e0)
In commit c6901a8b, the frame clock reported time was changed from
simply reporting the time we ran the frame clock cycle to reporting a
smoothed value that increased by the frame interval each time it was
called.
However, this change caused some problems, such as:
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1415https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1416https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1482
I think a lot of this is caused by the fact that we just overwrote the
old frame time with the smoothed, monotonous timestamp, breaking
some things that relied on knowing the actual time something happened.
This is a new approach to doing the smoothing that is more explicit.
The "frame_time" we store is the actual time we ran the update cycle,
and then we separately compute and store the derived smoothed time and
its period, allowing us to easily return a smoothed time at any time
by rounding the time difference to an integer number of frames.
The initial frame_time can be somewhat arbitrary, as it depends on the
first cycle which is not driven by the frame clock. But follow-up
cycles are typically tied to the the compositor sending the drawn
signal. It may happen that the initial frame is exactly in the middle
between two frames where jitter causes us to randomly round in
different directions when rounding to nearest frame. To fix this we
additionally do a quadratic convergence towards the "real" time,
during presentation driven clock cycles (i.e. when the frame times are
small).
(cherry picked from commit 9ef3e70040)
On my X11 + nvidia setup gnome-shell doesn't report presentation times.
However it does report refresh rate. We were mostly using this in our
calculation except when computing predicted presentation time, were
it fell back on the default 60Hz.
(cherry picked from commit f1215d2d77)
'gtk_file_chooser_get_filter' did not work for GtkFileChooserNative,
since the previous way did not properly handle the delegate dialog,
s.a. commit a136cbae8f
("filechoosernative: forward current_filter to delegate dialog",
2018-11-29) for details, wich basiscally fixed the same thing for
the 'gtk_file_chooser_set_filter' case.
This fixes#1820 for the fallback dialog. A solution for the portal
one (which also requires changes to xdg-desktop-portal and
xdg-desktop-portal-gtk as well) will be suggested in a subsequent step.
Bug: #1820
Trash monitor queries info from gvfsd-trash after each file monitor
change which can be problematic when too many changes happen in
a short time. Let's rate limit the number of queries...
Fixes: #1010
- Remove various unnecessary overrides for linked buttons.
- Add missing outline styles to the %linked_vertical ones.
- Consistently use :not(.vertical) instead of :dir(ltr|rtl) for linked
combo buttons.
- Remove :only-child styling from the messagedialog button. The
:only-child is equivalent to :first-child:last-child, so we don't need
the styling there specially.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/2752
Closes https://gitlab.gnome.org/GNOME/gtk/-/issues/2549
Provide the minimal info necessary. Improves apparent responsiveness
(since we don't visibly clear and repopulate the list) and saves doing
file stat/reads on every file in the result set.
The filechooser tries to figure out whether it got results by poking
the model, but all files might go through the async GFileInfo querying
state.
Make all search engines (and the composite one) just notify about this
fact, so the file chooser can behave appropriately without waiting for
the async operations to finish.
The tablet device is the source device of the event. We must use
the source device to properly detect what kind of source we must
use to properly set the color.
If the tablet gets removed/freed while there are pad events in flight,
we leave a dangling pointer from the pad to the tablet, which may
lead to invalid reads/writes when handling the pad event(s).
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2748
Once upon a time, there was a function called gdk_event_get_scroll_deltas().
It returned %TRUE when an event had scroll deltas and that was used as the
condition to decide whether to push scroll deltas to the scroll history,
even when the both deltas are 0 for the stop event at the end of scrolling.
When GtkScrolledWindow kinetic scrolling code was adapted for
GtkEventControllerScroll, it was replaced with a (dx != 0 && dy != 0)
check. This prevented the stop event from getting into the history, and
instead allowed non-smooth scrolling to affect the history as they have
synthetic deltas with one of the values being -1 or 1 and the other on 0.
Instead, check the direction as we already have it as a local variable.
To avoid making this mistake again, add a static assertion that the
enum is in sync with gtk_license_info, and use the length of
gtk_license_info for the precondition check.
Signed-off-by: Simon McVittie <smcv@debian.org>
Resolves: #2734
Reading form the back buffer is not allowed on software renderers,
and this is reported by the buffer age, so reading from GL_BACK
should not be done when the age is 0
Closes#64
On touch, the popup shown shall contain the 'select-all' button
only if a selection is in progress and if the entry is editable.
Let the button be shown always if selectable so that it’s more helpful.
When the code for this was copied from nautilus,
we forgot to adapt it for running in a library
instead of an application - gettext() doesn't work
in a library.
Fixes: #2690
Commit 07beb6dba2 made GtkAppChooserWidget useful with no content-type,
however when used in a GtkAppChooserDialog, this will lead to a confusing
"Opening (null) files" subtitle.
Fix this by omitting the subtitle altogether in that case.
currently when mouse clicking on a column header
to sort it it is grabbing keyboard focus, this
should not happen, keyboard focus should remain
where it was before. This can be seen on the
GtkFileChooser widget, when having the keyboard
focus on the file list items and clicking on a
column header to sort it the keyboard focus is
now on the header.
GtkMenu under X11 cannot handle touch events properly,
so just disable touchscreen grabbing for it, which makes
it fallback to pointer emulation.
Closes https://gitlab.gnome.org/GNOME/gtk/-/issues/945
menu: Fix grab on other backend
They use powershell instead of cmd.exe, use the tag win32-ps instead of win32,
and run Windows 2016 instead of 2012r2.
The old runners will be switched off in the comming weeks.
This is a possible fix for https://gitlab.gnome.org/GNOME/gtk/-/issues/2657
Use a NULL return from g_file_query_info_finish() to detect cancellation
of the query, and avoid derferencing a stale pointer.
Instead of hardcoding gtk-xft-antialias, use SPI_GETFONTSMOOTHING to
determine whether antialiasing is enabled.
Make gtk-xft-rgba query more complex - try to determine display
orientation, then use that to rotate subpixel structure. This
won't help with monitors that have naturally vertical subpixels,
but should improve things for monitors that are rotated (as long
as Windows display settings are adjusted accordingly).
Partially fixes#1774
This reverts commit fc2008f240.
Turns out, we *don't* have code to maintain Z-order. Restacking
code is not doint that, it just enforces a few weird Z-order-related
behaviours.
'window' is not the only toplevel css name, there are also 'dialog' etc.
Move it before .solid-csd style so that .solid-csd background takes
precedence.
Do also the async file info query for remote files when they
are not bookmarked, because otherwise "None" will be shown as
file name (and fallback text generic icon will be used).
The remote file was already browsed by the file chooser
instance when selecting it, so querying the display name
again should be using gio cache and not be slow.
Even if it's were slow it's better than showing 'None'
which makes it seem as if nothing was selected.
Fixes#1966
Since we're shipping both Meson and Autotools build systems for GTK3,
and both of them have a version field, it's bound to happen that the
GTK version defined in either build systems will go out of sync.
Let's add a check in both builds so that something will fail before
doing a release in case the versions do not match.
which could happen after confirming the "file overwrite"
dialog and may result in a different file being overwritten
causing data loss.
The oblivious file selection can be done by a mouse
click or keyboard press sent inadvertently just after
confirming the "file overwrite" dialog.
Fixed by adding a flag to ignore any button/key press
events sent to the file list. We set this flag just
after the user accepts the "file overwrite" dialog,
which means the enclosing GtkfilechooserDialog is about
to get closed. And we restablish the flag when the dialog
is shown again (in its map() handler).
Fixes data loss issue #2288
This comment was added in 93bcca7f02 but missed a
colon so it never actually generated documentation and the nullable annotation
never made it into GObject-introspection language bindings.
This crude regex does not catch any other instances of this mistake. The @
symbol is used to disambiguate signal doc comments from property doc comments,
since property docs usually don't have parameters.
$ pcre2grep -rM '\\* [A-Z][A-Za-z]*:([a-z\-]*):\n +\* @' gtk/
Various files are in git but not in dist tarballs. Some of them look
like potentially useful references for downstream distributors.
Signed-off-by: Simon McVittie <smcv@debian.org>
The order in which the resources get embedded matters for reproducible
builds. In the Meson build system, gen-gdk-gresources-xml already sorts
the list, but in the Autotools build system they were previously taken
in readdir() order.
Signed-off-by: Simon McVittie <smcv@debian.org>
This means it'll always be as up to date GdkWindow::width/height. We
still skip the resize for non-configured windows though, to avoid
mapping with the wrong size.
The commit f06ee688fe also accidentally
removed the unconfigured size setting completely, so this essentially
adds it back, but always sets it.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2582
So now we essentially only inhibit the premature resize for toplevel
windows, where it is most crucial. For popups, this didn't work for two
reasons: we relied on the owner of the popup (application) to resize
according to the configured size. For custom popup operators like
Epiphany and LibreOffice, this didn't work out well, since they simply
didn't.
Making gdk do it for them in case they didn't themself did make the
popups show up properly, but there were still some weirdness in
LibreOffice where tooltips didn't still didn't get the right size. So,
even though the size set by application may be different from the one
later configured by the display server, let the applications have their
way and see their resize result immediately. It's fairly likely to be
what they eventually get anyway.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2583
Who knows who might use this for something, so lets make the
unconfigured size slightly more predictable. This doesn't fix anything
known to be broken though.
With the fixes from !1638, it shouldn't be possible for this to happen
any more. However, non-positive sizes make no sense regardless, so if
this does somehow happen, let's make sure *something* reasonable happens.
The practical result of this assertion being hit is that we emit a
critical warning and then behave the same as if !1634 had been merged,
which is known to solve the issue for the submitter.
Signed-off-by: Simon McVittie <smcv@debian.org>
We get the unconfigured size request either with or without the shadow
margin already configured, so to get some consistency with the 'saved
size', cut away any potential shadow margin from the size before
storing.
Then when using, add it back, so we always create a configure event with
the correct size.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2576
There is no way for custom Wayland surfaces to get configure events, so an
initial configure event should not be required to resize a custom surface.
Fixes#2578.
With C compilers defaulting to -fcommon, this isn't an issue, but
upcoming compilers (GCC 10 and Clang 11) will default to -fno-common,
ending up with duplicate definitions of this variable.
In the paths where len > MAX_LEN and cursor/anchor are separated by
at least MAX_LEN from text edges, we were clamping the right end of
the surrounding string at MAX_LEN. Oops.
This end anchor may go as far as the string length, although just
up to len - MAX_LEN in real terms (due to the condition above that
caches cursor/anchor positions being near enough the text end).
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2565
When we `Alt+Tab` away from a GTK application, it loses keyboard focus.
If we don't clear the modifiers, events from other devices that we
receive while unfocused will assume `Alt` is still pressed. This results
in e.g. Firefox navigating through the history instead of scrolling the
page when using the mouse wheel on it.
We don't get any information about modifiers while we are missing
keyboard focus, so assuming no modifiers are active is the best we can
do.
The shell sends us a modifier update immediately before we regain
keyboard focus, so the state shouldn't get out of sync.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/2112
We're normally going from a fixed size to a floating state when we're
using the saved size, meaning we're practically always going towards a
state where the shadow margin will non-empty. However, if we don't
include any margin when creating a new configure request, we'll end up
resizing to a slightly smaller size as gtk will cut off the margin from
the configure request when changing the window widget size.
This wasn't visible when e.g. going from maximized to floating, as we'd
add the shadow margin at a later point, which would effectively "grow"
the widnow size, but when we're going from tiled to floating, we both
start and end with a non-empty shadow margin, meaning we'd shrink ever
so slightly every time going between tiled and floating.
We should never save a size when we're tiled, just as we shouldn't when
we're maximized. This fixes returning to the correct floating size after
having been tiled or maximized.
If a window is configured with a fixed size (it's tiled, maximized, or
fullscreen), ignore any resize call that doesn't respect this. The set
size will instead be saved, when appropriate, so that the new size is
used when e.g. unmaximizing.
This makes it possible to call 'gtk_window_resize()' while the window is
maximized, without the window actually changing size until it's
unmaximized. Changing size to a non-maximized size is a violation of the
xdg-shell protocol.
An application may want to set a fallback size of a window while still
mapping maximized. This is done by calling gtk_window_resize() before
gtk_window_maximize() and before gtk_window_show(). When the window is
mapped, it should have a maximized size, and if it eventually is
unmaximized, it should fall back to the size from the earlier
gtk_window_resize() call.
What happens before this commit is that the initial window size ends up
respecting the first gtk_window_resize() dimensions, and not the window
dimension configured by the Wayland display server (i.e. maximized
dimensions).
Fix this by postponing any configure events until we received our
configuration from the display server. If we got one with a fixed size
(e.g. we're maximized, tiled etc), we use that, otherwise we look at the
one that was previously configured by gtk which corresponds to the
"preferred" size when not being maximized.
This fixes Firefox being started in a maximized state when using the
Wayland backend.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2538
In addition to the traditional library directory lib and the 64-bit
multilib directory lib64, this will cover Debian-style multiarch
(lib/x86_64-linux-gnu etc.), Arch Linux 32-bit (lib32), x32 and
various others.
Signed-off-by: Simon McVittie <smcv@debian.org>
As general rule, all buttons that launch a menu should
not grab focus on click, because otherwise when the menu
is closed the focus goes back to the button instead of
the previously focused widget, which is the one the user
was interacting with.
GtkScaleButton and GtkVolumeButton set focus-on-click
to FALSE for this same reason.
Fixes#2557
As general rule, all buttons that launch a menu should
not grab focus on click, because otherwise when the menu
is closed the focus goes back to the button instead of
the previously focused widget, which is the one the user
was interacting with.
So this is also the case for the 'New Folder' button on
the filechooser.
Fixes#2557
because otherwise this second[1] popover will not be
able to save the filechooser default widget (the 'save'
button) because the first popover has not yet restablish
it (as will be done on popover's unmap handler).
[1] second because 'Rename' popover is launched from inside
the 'file properties' popover.
Fixes#2555
If we have never seen a GtkTextTag in the GtkTextTagTable with the
invisible bit set, then we do not need to go through the process of
checking the accumulated tags.
Not using invisible tags is overwhelmingly the common case.
gtk+-3.24.14 with quartz backend fails to compile on macOS when using
a case-sensitive file system. The cause for the compilation error is a
simple typo in line 26 of `gdk/quartz/gdkquartz-gtk-only.h`. The
AppKit framework is included there with `<Appkit/Appkit.h>` instead of
`<AppKit/AppKit.h>`, which is fixed with this commit.
References: https://trac.macports.org/ticket/60168
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/2503
The 'selection-changed' signal is emitted unconditionally, even in the case
when there is no selection to be cleared. As a result, the subscriber receives
the initial signal and if he calls gtk_file_chooser_get_uri(), no value is
currently selected.
This might happen for slow filesystems where a fast-content-type might
be provided instead. Don't try to manipulate that content_type if it's
NULL, otherwise we'll either throw warnings (at best) or crash (at
worse).
If NULL is returned, probably the client shouldn't advertise the
mimetype. Make it sure we forget entirely about the attempt to
cache this mimetype, as it'll be mistaken as pending otherwise.
Dropping this cached selection will in consequence close the fd
of all pending readers, which seems appropriate for NULL content.
https://gitlab.gnome.org/GNOME/gtk/issues/2456
The only way to have G_IO_ERROR_CANCELLED in the write callback
goes through having the array of pending writers already cleared.
It should not access the invalid AsyncWriteData and StoredSelection
in that case.
.osd suggests a particular color/background/hover style, while .circular
only suggests roundness. So for buttons that use both classes, make sure
the former takes precedence with regard to background/hover.
gdk_window_impl_quartz_release_context () can be called with a NULL CGContextRef. This causes CoreGraphics assertion failures when debugging a Gtk application in Xcode, as the code was blindly passing that NULL to CGContextRestoreGState () and CGContextSetAllowsAntialiasing (). Given that the matching pair of CGContextSaveGState () and CGContextSetAllowsAntialiasing () calls are already checking for a NULL CGContextRef, it seems reasonable to wrap these calls in a NULL check.
Cache separately the selection contents for each given window/selection/atom
combination, and keep the requestors separate for each of those.
This allows us to incrementally request multiple mimetypes, and dispatch
the requestors as soon as the data is up. This stored selection content is
cached until the selection owner changes, at which point all pending readers
could get their transfers cancelled, and the stored content for the selection
forgotten.
We want expander arrows to be vertically centered in their row, so we
pass the cell area's height to the renderer.
However, if the cell area's height is an odd number while the
"expander-size" style property is an even number, or vice versa, the
arrow will be centered in a half pixel, and fuzzily rendered.
So, round the render height to the same parity as the expander-size.
(This is not necessary for the arrow width because it's assumed equal
to the "expander-size" style-property.)
An expander arrows's render width is supposed to be derived from the
"expander-size" style property.
However, we are actually rendering it for a width equal to
expander-size + 1. This results in ugly blurry rendering.
There is a comment justifying this "+ 1", which has been there for
almost 2 decades. But the justification doesn't seem to apply to
the current code, so the original motivation is likely obsolete.
Let's remove this "+ 1" to render the arrow to a width exactly equal
to the "expander-size" style property.
This reverts commit d6a29e1b8c.
It fixed blurry rendering of expander arrows.
However, it also introduced a regression in that the arrows are no
longer vertically centered if rows are taller than twice the
expander-size style property.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1464
For a given OpenGL context, macOS in particular does not support enumeration / detection of OpenGL features that have been promoted to core OpenGL functionality. It is possible other drivers are the same. This change assumes support for GL_ARB_texture_non_power_of_two with OpenGL 2.0+, GL_ARB_texture_rectangle with OpenGL 3.1+ and GL_EXT_framebuffer_blit with OpenGL 3.0+. I failed to find definitive information on whether GL_GREMEDY_frame_terminator has been promoted to OpenGL core, or whether GL_ANGLE_framebuffer_blit or GL_EXT_unpack_subimage have been promoted to core in OpenGL ES. This change results in a significant GtkGLArea performance boost on macOS.
Closes#2428
Call gtk_widget_set_allocation after chaining up to parent class
to ensure that GtkInfoBar has correct allocation. Otherwise x and y
is set to zero causing wrong window position in gtk_info_bar_realize.
This fixes info-bar-message-types.ui reftest.
https://gitlab.gnome.org/GNOME/gtk/merge_requests/1428
Epiphany is doing something weird after calling gtk_window_close(),
because by the time the callback executes, the window has no GdkWindow.
Frankly, I don't know what's happening there, but we should probably not
crash.
Fixes#2424
This reverts commit ee448db031.
The `name_suffix` argument is already set, and by setting it twice we're
just getting a warning at configuration time from Meson.
link target uses `$selected_bg_color` and `$selected_fg_color` for the
definition of some selectors (e.g. selected).
While `$link_color` and `$link_visited_color` are based on
`$selected_bg_color`, this does not seem coherent.
Replacing `$selected_*g_color` in link target style with link colors
defined in `_colors.scss file`.
When a device is added, there are two references to it by the device
manager, the initial one and the one used for the id_table. Removing a
device only removed the reference added by the id_table resulting in the
GdkDevice being leaked.
https://gitlab.gnome.org/GNOME/gtk/merge_requests/1359
GTK caches the settings per display in a static `GArray`, keeping a
reference to the `GdkDisplay` as the key.
However, when closing the display, the corresponding entry is not
removed from the cache in `GtkSettings`.
So when reopening again a `GdkDisplay`, if the new address matches one
of the previously closed display, the cache will return the existing
`GtkSettings` from the cache, which still holds a reference to the old
`GdkScreen` which was freed along the `GdkDisplay`.
To avoid the issue, make sure to remove the `GdkDisplay` and
corresponding `GdkSettings` when closing the `GdkDisplay`.
Also, care must be taken not to recreate the `GdkSettings` and re-add
the `GdkDisplay` to the cache once the display is closed, and make sure
callers of `gtk_settings_get_for_display()` can deal with a returned
value being `NULL` if the display is closed.
Fixes: commit 360a3c1690 - "Use a cheaper way to store settings per
display"
On Wayland, opening and closing a `GdkDisplay` generates a coupe of
warnings at runtime:
```
GLib-GObject-WARNING **:
invalid cast from 'GdkWindowImplWayland' to 'GdkWindow'
GLib-GObject-WARNING **:
invalid cast from 'GdkWaylandWindow' to 'GdkWindowImplWayland'
```
This is from `gdk_window_impl_wayland_finalize()` which tries to cast
the given GObject to a `GdkWindow` while it's a `GdkWindowImplWayland`.
Use the correct type casting of objects to avoid the warnings.
printer_name_compressed_strv is NULL-terminated array
of gchar*, which means N+1 memory should be allocated.
Otherwise, if the printer name has no empty components
(which is usually the case), printer_name_compressed_strv[N],
which should contain the NULL sentinel, will actually lie
just outside of allocated memory, which is UB.
In my case, it led to crashes inside g_strjoinv
when Print... dialog is opened in evince.
#0 0x00007fad2ce1bad7 in __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:96
#1 0x00007fad2d04d88d in g_strjoinv (separator=separator@entry=0x7fad0c9bc508 "-", str_array=str_array@entry=0x556b017f0200) at ../glib-2.60.7/glib/gstrfuncs.c:2585
#2 0x00007fad0c9b8a89 in avahi_service_resolver_cb (source_object=<optimized out>, res=<optimized out>, user_data=0x7fad08020ee0) at /var/tmp/portage/x11-libs/gtk+-3.24.13/work/gtk+-3.24.13/modules/printbackends/cups/gtkprintbackendcups.c:3223
#3 0x00007fad2d1f8ed3 in g_task_return_now (task=0x556b017a8b00 [GTask]) at ../glib-2.60.7/gio/gtask.c:1209
#4 0x00007fad2d1f987d in g_task_return (task=0x556b017a8b00 [GTask], type=<optimized out>) at ../glib-2.60.7/gio/gtask.c:1278
#5 0x00007fad2d1f9dec in g_task_return (type=G_TASK_RETURN_SUCCESS, task=<optimized out>) at ../glib-2.60.7/gio/gtask.c:1678
#6 0x00007fad2d1f9dec in g_task_return_pointer (task=<optimized out>, result=<optimized out>, result_destroy=<optimized out>) at ../glib-2.60.7/gio/gtask.c:1683
#7 0x00007fad2d24b6af in g_dbus_connection_call_done (source=<optimized out>, result=0x556b017a8bc0, user_data=0x556b017a8b00) at ../glib-2.60.7/gio/gdbusconnection.c:5747
#8 0x00007fad2d1f8ed3 in g_task_return_now (task=0x556b017a8bc0 [GTask]) at ../glib-2.60.7/gio/gtask.c:1209
#9 0x00007fad2d1f8f09 in complete_in_idle_cb (task=0x556b017a8bc0) at ../glib-2.60.7/gio/gtask.c:1223
#10 0x00007fad2d02d2c0 in g_main_dispatch (context=0x556b00eee090) at ../glib-2.60.7/glib/gmain.c:3189
#11 0x00007fad2d02d2c0 in g_main_context_dispatch (context=context@entry=0x556b00eee090) at ../glib-2.60.7/glib/gmain.c:3854
#12 0x00007fad2d02d658 in g_main_context_iterate (context=context@entry=0x556b00eee090, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib-2.60.7/glib/gmain.c:3927
#13 0x00007fad2d02d6df in g_main_context_iteration (context=context@entry=0x556b00eee090, may_block=may_block@entry=1) at ../glib-2.60.7/glib/gmain.c:3988
#14 0x00007fad2d22248d in g_application_run (application=0x556b0116f130 [EvApplication], argc=<optimized out>, argv=<optimized out>) at ../glib-2.60.7/gio/gapplication.c:2519
#15 0x0000556b002e55a1 in ()
#16 0x00007fad2ccd6f1b in __libc_start_main (main=0x556b002e50d0, argc=2, argv=0x7ffe1057fa88, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe1057fa78) at ../csu/libc-start.c:308
#17 0x0000556b002e567a in ()
(gdb) p printer_name_compressed_strv[0]
$4 = (gchar *) 0x556d4a4be430 "Brother"
(gdb) p printer_name_compressed_strv[1]
$5 = (gchar *) 0x7f9dbc011090 "MFC"
(gdb) p printer_name_compressed_strv[2]
$6 = (gchar *) 0x556d4a51ba50 "7860DW"
(gdb) p printer_name_compressed_strv[3]
$7 = (gchar *) 0x401 <error: Cannot access memory at address 0x401>
- many moons and some iterations later, these are the suggested
general typographic styles. Already being referenced in apps like
Banner Viewer (for now shipping custom definitions)
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1808
Touchpad gestures have only a single event sequence. The current
'center' of the gesture is the starting point + accumulated deltas.
Update gtk_gesture_get_bounding_box_center() accordingly.
When we have a default action set on the infobar, activate it
for clicks anywhere in the infobar. Also add an .action style
class in this case, so we can add a hover highlight to the infobar
just for this case.
When a remote instance of a GTK application implementing the Startup
Notification protocol gets spawned it will pass the startup sequence
ID as "platform data" to the main instance. Thus, we need to make sure
that the startup sequence gets completed in that case, since the remote
instance won't do it by itself, since it won't map any top level window.
Checking for this "platform data" in the implementation of the after_emit()
virtual method in the primary instance should be a good place to do so, since
the existence of such data proves that a remote instance has been spawned.
https://gitlab.gnome.org/GNOME/gtk/issues/1084
The sed -i flag is non-standard, and may not be available in all
implementations.
The meson build already requires wayland >= 1.14.91 and uses
private-code, so just do that in the autotools build as well.
In a4fe15d9f0, the wayland-scanner command was changed to use
`private-code`, which was first introduced in wayland-1.14.91. This
was synced from master commit a2a99d27c9, which *did* include a
corresponding wayland version requirement bump, but it appears that
this was lost in the sync.
The problem is caused by gtk_im_multicontext_set_slave(), which forgets
to disconnect these signal handlers:
* gtk_im_multicontext_retrieve_surrounding_cb
* gtk_im_multicontext_delete_surrounding_cb
If slave GtkImContext emits signal after GtkIMMulticontext context is
destroyed, this leads to reading freed memory, sometimes causing a crash.
Fixes: #2365
The default location (obtained over g_mount_get_default_location) is
opened after mounting volume, or when opening mounts from sidebar, but
not after mounting over "Connect to Server". Let's unify the behavior
and always open the default location.
https://gitlab.gnome.org/GNOME/nautilus/issues/1319
(cherry picked from commit 267ea7552b)
Window scale can change at runtime. If cairo_surface is already
created for root window gdk_pixbuf_get_from_window will return
wrong image.
_gdk_x11_screen_set_window_scale already updates window_scale for
root window, update also cairo_surface device scale.
https://gitlab.gnome.org/GNOME/gtk/merge_requests/1208
Always insist on at least 1px, even if the thumbnail we're turning into
an icon was 256 * 3 and should be scaled to 32 * 3/8.
(cherry picked from commit 6769db160d)
It's currently used only to not include the insert emoji option in the
context menu, but it's still possible to show the emoji chooser in both
GtkEntry and GtkTextView using the key bindings.
See also https://bugs.webkit.org/show_bug.cgi?id=205609.
On touchpads gtk_gesture_get_sequences() was called without a
corresponding g_list_free(). The same was true for touchscreens
if due to some reason only a single sequence was found.
GtkIMContext get_preedit_string should return cursor position counted
in characters, but cursor_begin here is counted in bytes. This add the
missing conversion.
Create printer name from name of the advertised service
for standalone IPP printers as opposed to CUPS printers
advertised via Avahi which get name from their
resource path.
This is similar to what cups-filters does.
Pass GtkPrinter class to request for printer info
so that it does not need to be searched for
(such search could fail for standalone IPP printers).
https://gitlab.gnome.org/GNOME/gtk/issues/1509
Set reasonable default values for printers discovered
by Avahi which do not have 'printer-type' attribute.
This is the case for network printers which were not
published by CUPS.
Related to the issue #1509.
We also need to force redraw of the whole window when we are using
EGL/ANGLE during un-fullscreen, so that we do not get glitches in the
resulting window.
Use RemoveClipboardFormatListener() and AddClipboardFormatListener().
These APIs remove the need for us to maintain the integrity of the
clipboard chain, which turned out to be problematic for some reason
that is yet to be identified.
Fixes#2215Fixes#442
Use existing create_page_setup() function to make a GtkPageSetup
object out of the GtkPrintSettings (which we shuttled out of W32
DEVMODE) and apply it to GtkPrintOperation is the default page
setup.
Applications (such as gedit) retrieve page setup from GtkPrintOperation
by calling gtk_print_operation_get_default_page_setup (). Therefore,
we have to set it, otherwise they will get the same page setup that
we had before the dialog was shown, and will later feed that page
setup to us again, which will cause paper size and orientation to
be always reset back to whatever the hardcoded default values were.
2019-04-01 07:28:08 +00:00
899 changed files with 211318 additions and 191826 deletions
# YourProject_HEADERS_EXCLUDES = ... # <list of headers to exclude from installation, separated by '|', wildcards allowed; use random unsed value if none>
#
# dist-hook: \ # (or add to it if it is already there, note the vs9 items will also call the vs10 items in the process)
@for %%f in (..\..\gtk\cursor\*.png)do @echo ^<file^>cursor/%%~nxf^</file^>>> $@
@for %%f in (..\..\gtk\gesture\*.symbolic.png)do @echo ^<file alias='icons/64x64/actions/%%~nxf'^>gesture/%%~nxf^</file^>>> $@
@for %%f in (..\..\gtk\ui\*.ui)do @echo ^<file preprocess='xml-stripblanks'^>ui/%%~nxf^</file^>>> $@
@for %%s in (16222432 48)do @(for %%c in (actions status categories)do @(for %%f in (..\..\gtk\icons\%%sx%%s\%%c\*.png)do @echo ^<file^>icons/%%sx%%s/%%c/%%~nxf^</file^>>> $@))
@for %%s in (scalable)do @(for %%c in (status)do @(for %%f in (..\..\gtk\icons\%%s\%%c\*.svg)do @echo ^<file^>icons/%%s/%%c/%%~nxf^</file^>>> $@))
@for %%f in (..\..\gtk\inspector\*.ui)do @echo ^<file compressed='true'preprocess='xml-stripblanks'^>inspector/%%~nxf^</file^>>> $@
for %%s in (16 22 24 32 48 256) do ((mkdir $(CopyDir)\share\icons\hicolor\%%sx%%s\apps) & (copy /b ..\..\..\demos\gtk-demo\data\%%sx%%s\gtk3-demo.png $(CopyDir)\share\icons\hicolor\%%sx%%s\apps))
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
