| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
| |
Outline a contribution workflow, and how GdkPixbuf is logically split.
|
| |
|
|
|
| |
It's desolate, at the moment, and free software projects without a
decent README are a bit sad.
|
| |
|
|
| |
We cannot expand those, as Xlib does not come with a gtk-doc index.
|
| | |
|
| |
|
|
|
|
|
| |
The "handling an expose event" example is badly outdated, referencing
concepts and practices that were deprecated halfway through the GTK 2.x
development. These days, it's going to confuse people more than help
them.
|
| | |
|
| |
|
|
|
| |
Instead of using a template, use Meson's pkgconfig module to generate
the pkg-config file for us from the build targets.
|
| |
|
|
|
| |
We really only care about it as a library in order to build a test. We
can simply include the sources into the main shared library.
|
| |
|
|
|
|
|
| |
Avoid a bunch of array iterations.
The get_supported_link_arguments() call is gated on a Meson version
check, to avoid requiring a bleeding edge stable version.
|
| |
|
|
| |
Use a less ancient baseline.
|
| |
|
|
| |
Add myself as a maintainer.
|
| |
|
|
| |
Like we did for Meson, do this for the Autotools build.
|
| | |
|
| |
|
|
|
|
|
| |
If we're installing gdk-pixbuf ourselves, we should generate the loaders
cache file — unless DESTDIR is set or we're cross-compiling, in which
case we assume that there's a packaging system hook in place to do this
at the end of a full build.
|
| |
|
|
|
|
| |
Like the Autotools build allows us to decide whether the tests should be
installed in a known location, we should have this option for the Meson
build.
|
| |
|
|
|
| |
Remove long since gone intra-library links, and point to the API
reference website instead.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
We have two "set but unused variable" warnings coming from
gdk-pixbuf-xlib. The first is caused by an unnecessary variable used to
hold the return value of XGetWindowAttributes(); we don't do anything
with it, and it's way too late for changing the behaviour of the
function to bail out on error. The second is caused by a variable that
is only used when a debugging printf() is compiled in; to avoid the
warning without creating even more complex macro hell, we tell the
compiler that the variable is unused.
|
| |
|
|
|
|
|
|
| |
If there are no built-in modules, the `builtin_module` variable is not
used, and the compiler will warn about it.
Since we're already using the variable inside a macro, we can just
declare it inside the macro block and save us the trouble altogether.
|
| |
|
|
| |
A text file should not have the executable bit set.
|
| |
|
|
|
| |
We dropped it with the Meson build port, and I'm not entirely sure it's
still tested, but it doesn't cost us anything to re-enable the check.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Use two loops to traverse the array of arrays `DM`, i.e. use `DM[y][x]`
instead of `DM[0][i]`.
This resolves a warning about undefined behavior when compiling with GCC
with aggressive loop optimizations enabled.
While we are at it: Move the variable definitions into the body of the
outer if-statement.
https://bugzilla.gnome.org/show_bug.cgi?id=748211
|
| |
|
|
|
| |
Same as commit fc2d02ed908c524cc2831e5404d5f06b02e3f9fd, but for the
Meson build.
|
| |
|
|
|
|
|
| |
The generated marshalers are public API, and the header needs to be
installed, even though nobody should be using them.
https://bugzilla.gnome.org/show_bug.cgi?id=795213
|
| |
|
|
|
| |
We need to re-generate the gdk-pixbuf.types in order to include all
public types; this requires fixing the list of ignored headers.
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=794872
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
|
| |
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=795210
|
| |
|
|
|
|
| |
gdk_pixbuf_composite_color_simple
https://bugzilla.gnome.org/show_bug.cgi?id=789935
|
| |
|
|
|
|
|
| |
Calling g_bytes_unref_to_data() will copy the contents of the bytes
buffer, so we need to free the data.
https://bugzilla.gnome.org/show_bug.cgi?id=787626
|
| |
|
|
|
|
|
|
| |
We're currently installing the test launchers and parts of the test
data, but we're not installing the binaries and the whole suite of
image data we have.
https://bugzilla.gnome.org/show_bug.cgi?id=795527
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Relocation works by recognizing paths in the loaders cache
which start with the built time prefix and extract the relative
path from that.
This leads to the following problem when updating the cache:
In case the package is build on another machine one has to
either match the build directory layout or adjust the
cache by hand for the resulting cache to stay relocatable.
This commonly occurs with msys2 where mostly pre-build packages
are used which are built on another machine and the cache gets
generated at install time. Another case is updating the cache
in a separate deployment environment.
This patch takes the package installation directory as a base
and writes relative paths into the cache when relocation
is enabled. When loading the cache a relative path is made
absolute by prepending the package base again.
https://bugzilla.gnome.org/show_bug.cgi?id=776081
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
We should not be using cross-compilation to gate the generation of
introspection data; it's perfectly possible to use a helper binary
to run g-ir-scanner when cross-compiling — in fact, that's what
projects like Yocto already do.
We should also return a target for the introspection data, to allow
using gdk-pixbuf as a sub-project.
|
| | |
|
| | |
|
