With the shader approach to symbolic recoloring, we must
not recolor the svgs anymore as we're loading them. Instead,
load them the same way that gtk-encode-symbolic-svg does.
This fixes the rendering of large symbolic icons e.g. the
'no search results found' page in the file chooser.
This is just lots of renaming.
The interface remains private, so the public API does not change, apart
from removing the definition of the Interface object to avoid
subclassing.
The gtk_tools variable is an array of arrays; adding a new element
requires to maintain the same type, or we'll get a build failure when
we try to extract the newly added element.
Add the necessary machinery into the Meson definition files so that we
can build for Windows.
Since we don't have Wayland or X support for our use case here, disable
them once we know that we are building for Windows, as they are
(otherwise) enabled by default, and enable the items that need to be
built for Windows builds.
Exclude gtk4-launch from Windows builds as that is something that
is not supported on Windows.
As we won't have gio-unix on Windows, and PangoFT2 is optional, don't use
fallbacks for them when we are on Windows (but do use fallbacks for
gio-win32, as it will be used).
Also, clean up meson.build a bit as we can just force-include
msvc_recommended_pragmas.h from GLib since we depend on GLib, and so we
can handle these warnings from msvc_recommended_pragmas.h instead.
https://bugzilla.gnome.org/show_bug.cgi?id=785210
This is a GtkEventController implementation to handle mouse
scrolling. It handles both smooth and discrete events and
offers a way for callers to tell their preference too, so
smooth events shall be accumulated and coalesced on request.
On capable devices, it can also emit ::scroll-begin and
::scroll-end enclosing all ::scroll events for a scroll
operation.
It also has builtin kinetic scrolling capabilities, reporting
the initial velocity for both axes after ::scroll-end if
requested.
This will allow further cleanups and optimizations in capture/target/bubble
event delivery. For simplicity, ATM every widget will receive its own
GtkEventControllerLegacy, it could be desirable to add finer control over
this in the future, so widgets that fully use event controllers for input
management can do away without this legacy piece.
Add integration of the libcloudproviders DBus API to the
GtkPlacesSidebar by showing name and sync status of the cloud providers.
The exported menu is rendered as a GtkPopover.
The sidebar will be updated if the list of cloudproviders changes e.g.
by adding or removing an account. If any cloud provider changes detailed
information like sync status only the individual sidebar row gets
updated.
Co-authored-by: Carlos Soriano <csoriano@gnome.org>
Co-authored-by: Daniel Boles <dboles@src.gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=786123
Copy the PangoCairoRenderer into GTK+, rename it to GskPangoRenderer,
and strip it down far enough to build without private pango apis.
This means we currently don't support hexboxes or shapes.
Currently, this lives in gtk, but it might be nicer to put it
in gsk eventually.
GSK has various enumeration types that are currently not used; while
they may go away, currently they are built and introspected. If we want
the introspection machinery to work, and still use static libraries to
build GDK and GSK into the GTK shared library, then we need to reference
the get_type() function of these enumeration types somewhere, to avoid
the linker discarding it, and thus breaking the build.
As luck would have it, we have an autogenerated bit of C that refers to
all the get_type() functions in the library; if we add the GSK types to
it, then we get the reference we're looking for, and the build succeeds.
We're mixing a lot of styles in the Meson build files. This is an
attempt at making everything slightly more consistent in terms of
whitespace and indentation.
We need to check if the linker flags we use are available, depending on
the platform, and we need to ensure that the shared library is
versioned appropriately.
We have to work around some ordering problems here. We still
manage to keep most of the guts in modules/input/meson.build,
so it's not too ugly overall.
(The autotools build solves this with a 'make -C ../../input/modules'
inside gtk/Makefile, but that's not something we can or want to do.)
Add back dependencies on libgdk_dep and libsk_dep which are declared
dependencies. We removed this before because these declarations had
link_with: lines that dragged in the static libgdk.a and libgsk.a libs
which are linked into libgtk-4.so anyway and thus shouldn't be used
when linking internal exes/tools against libgtk-4. Remove the static
libs from the declared dependencies and have libgtk link those in
explicitly, so that the declared deps now just provide all the built
dependencies and include dirs and such for declared libgtk_dep users
such as the internal exes/tools, which want all the generated gsk/gdk/gtk
headers to exist before attempting to compile anything against the
gtk+ headers.
gdk and gsk are no longer separate libs but part of gtk now, so any
Gtk+ user should just link to gtk, there's no need to additionally
link against all those static helper libs that go into the gtk lib.
This means we need to specifically add confinc to include_directories
in more places to make sure the right config.h (i.e. ours) gets
included and not a subproject's like graphene's config.h.
Not dragging in static libs also fixes the issue of all executables
having to be relinked for any and all changes. With this change
it's super-fast now and can be skipped for most changes that don't
touch the external ABI.
This is how it's done in the autotools build. Also avoids problems
with multiple source files having the same name (gdkeventsource.c).
Also move broadway backend code into broadway subdir.
Add libgdk_dep as dependency to the libgtk_dep declare_dependency(), so
that the generated gdk includes are generated before anything is built
that tries to include gtk headers (such as various tests that don't depend
on gdk directly).
This is needed for the Meson port, a file name .c that's included
and shouldn't be compiled into an object is difficult to manage
otherwise. And it's not actually a valid .c file anyway.
