Previously, this was done at the time of spawning the subprocess, which
meant the g_subprocess_launcher_*_environ() functions could not be used
to modify the parent process’ environment.
Change the code to copy the parent process’ environment when
g_subprocess_launcher_set_environ(NULL) is called. Document the change
and add a unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=778422
Since GtkApplication auto-loads some well-known resource paths. Add a
cross-reference to its documentation. (The cross-reference won’t be
linked if the GTK+ documentation isn’t available at build time, but this
is probably good enough. It is likely to be available.)
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=782336
The OpenURI portal has a separate method to handle local
files now. Use it.
At the same time, split out the openuri helpers into separate
files, and generate code for the OpenURI portal.
https://bugzilla.gnome.org/show_bug.cgi?id=783193
In addition to code, gdbus-codegen can also generate docbook
documentation for DBus interfaces. There's no good reason why
the newly added --output-directory option shouldn't apply to
those generated files as well.
https://bugzilla.gnome.org/show_bug.cgi?id=783201
When we call org.freedesktop.Application.Open to activate
an application and pass file uris, the application may not
be able to see the files due to a flatpak sandbox.
Flatpak puts the flatpak app-id in the X-Flatpak key in
desktop files that it exports, so we can easily recognize
applications that may be affected by this.
In this case, call the document portal to export the files
and pass the resulting uri's instead of the original ones.
https://bugzilla.gnome.org/show_bug.cgi?id=783130
gen-casefold-txt.pl and gen-casemap-txt.pl are licensed under GPLv2+, so
they are not touched by this commit.
A lot of *.c files in tests/ don't have a license header.
https://bugzilla.gnome.org/show_bug.cgi?id=776504
All glib/*.{c,h} files have been processed, as well as gtester-report.
12 of those files are not licensed under LGPL:
gbsearcharray.h
gconstructor.h
glibintl.h
gmirroringtable.h
gscripttable.h
gtranslit-data.h
gunibreak.h
gunichartables.h
gunicomp.h
gunidecomp.h
valgrind.h
win_iconv.c
Some of them are generated files, some are licensed under a BSD-style
license and win_iconv.c is in the public domain.
Sub-directories inside glib/:
deprecated/: processed in a previous commit
glib-mirroring-tab/: already LGPLv2.1+
gnulib/: not modified, the code is copied from gnulib
libcharset/: a copy
pcre/: a copy
tests/: processed in a previous commit
https://bugzilla.gnome.org/show_bug.cgi?id=776504
Use the new gen_util_scripts.py script to generate the glib-mkenums and
gdbus-codegen scripts with the proper info in them so that they can be
used properly by other build systems such as Meson, during "install".
This will allow the utility scripts glib-mkenums and gdbus-codegen be
generated with the proper info in them, as build systems such as Meson
might look for shebang lines to determine the commands that need to be
called to invoke the scripts (which is necessary for calling these
scripts on standard Windows cmd.exe)
Add $XDG_DATA_HOME/glib-2.0/schemas as a schema source, after (higher
priority than) $XDG_DATA_DIRS/glib-2.0/schemas but before
$GSETTINGS_SCHEMA_DIR. This is per the XDG Base Directory Specification,
which states that user specific versions of data in $XDG_DATA_DIRS can
be created in $XDG_DATA_HOME.
https://bugzilla.gnome.org/show_bug.cgi?id=741335
We need mnt_unref_table() in order to use libmount, but we also need to
keep the fallback code for installations of libmount without a
pkg-config file.
https://bugzilla.gnome.org/show_bug.cgi?id=782628
It is possible, when using GTK-Doc, to mark sections of an enumeration
type as "private": the values are there, but they are not documented,
and GTK-Doc won't complain about missing symbols:
typedef enum {
/*< private >*/
MY_FOO_PRIVATE,
/*< public >*/
MY_FOO_VALUE_A,
MY_FOO_VALUE_B,
/*< private >*/
MY_FOO_VALUE_C,
MY_FOO_VALUE_D
} MyFooValue;
The glib-mkenums parser also allows skipping enumeration values, using a
slightly different syntax:
typedef enum P
MY_BAR_PRIVATE, /*< skip >*/
MY_BAR_VALUE_A,
MY_BAR_VALUE_B
} MyBarValue;
The annotation must sit on the same line as the enumeration value.
Both GTK-Doc and glib-mkenum use the same trigraph syntax, but slightly
different keys. This makes combining them slightly redundant, but
feasible.
All would be well and good, except that glib-mkenum will generate a
warning for lines it does not understand — and that includes the GTK-Doc
annotation trigraph, which, when confronted with the MyFooValue
enumeration above, will result in a warning like:
glib-mkenums: myfoo.h:2: Failed to parse ` /*< private >*/ '
glib-mkenums: myfoo.h:5: Failed to parse ` /*< public >*/ '
glib-mkenums: myfoo.h:9: Failed to parse ` /*< private >*/ '
Of course, we could make glib-mkenum ignore any trigraph comment on a
stand alone line, but it would probably be better to ensure that both
glib-mkenums and gtk-doc behave consistently with each other, and
especially with the maintainer's intent of hiding some values from the
user, and reserving them for internal use.
So we should ensure that glib-mkenums automatically skips all the
enumeration values after a "private" flag has been set, until it reaches
a "public" stanza.
https://bugzilla.gnome.org/show_bug.cgi?id=782162
Currently, all mime types are considered subclasses of
application/octet-stream, but according to the freedesktop
standard, everything but the inode/* types is a subclass of
application/octet-stream.
Update the special case for application/octet-stream so that all
types but inode/* will match with it and add unit test for it.
https://bugzilla.gnome.org/show_bug.cgi?id=782311
g_dbus_connection_call_internal() accesses the user data it passes to
g_dbus_connection_send_message_with_reply() after the call. That data
might be freed already in the case that the callback is called
immediately.
Fix this by removing the 'serial' field from the user data altogether
and fetch the serial from the message in the callback.
https://bugzilla.gnome.org/show_bug.cgi?id=748263
