Some applications support running in a mode where they present
themselves as a different application to the user (for example web
browsers or terminals).
To facilitate this, add an option --gapplication-app-id which allows
users to override an application's id from desktop files or similar.
Applications need to opt-in to this by setting the
G_APPLICATION_CAN_OVERRIDE_APP_ID flag.
https://bugzilla.gnome.org/show_bug.cgi?id=743933
currently schema_list will iterate over the default SchemaSource
list, and not the one associated with the passed in Schema. This
means schema_list can give incorrect results for a Schema fetched
from a non-default SchemaSource, like via new_from_directory.
https://bugzilla.gnome.org/show_bug.cgi?id=757506
Perform conversion before writing a value out of the cache into the registry,
and convert back when reading a value into the cache out of the registry.
The registry holds UTF-8 strings.
This is a flag used to understand if a key exists on the registry
and if it is readable. It makes more sense to rename it as readable
since anyway a key that does not exists anymore is a key that is
not readable.
The documentation of g_file_info_copy_into() was misleading. The
attributes are not just copied, @dest_info is also cleared at the
beginning. So any previously set attributes in @dest_info are lost.
There was a bug in gedit about this function, where some metadata were
not saved. So it might make sense to change the implementation to not
clear @dest_info, and copy one by one the attributes from @src_info to
@dest_info.
https://bugzilla.gnome.org/show_bug.cgi?id=747927
I'm tired of seeing 'No such file or directory' in the logs without
a hint as to what is actually wrong. Including the filename here
may help me tracking down a bug in the continuous infrastructure.
Visual Studio, at least the older versions, cannot use L on macros which
are defined as a constant string, plus the L must be applied to all string
literals here. This does not look nice, but this is life...
Rather than calculating it at configure time. This means it can expand
$libdir properly, and use the Make $(realpath) function rather than
invoking the non-portable `readlink -f`.
This fixes problems where `readlink` would be called on an invalid path
(due to a variable not being expanded) and would evaluate to "", which
would then cause things to be installed in the wrong place.
https://bugzilla.gnome.org/show_bug.cgi?id=744772
Add a new GDtlsConnection interface, plus derived GDtlsClientConnection
and GDtlsServerConnection interfaces, for implementing Datagram TLS
support in glib-networking.
A GDtlsConnection is a GDatagramBased, so may be used as a normal
datagram socket, wrapping all datagrams from a base GDatagramBased in
DTLS segments.
Test cases are included in the implementation in glib-networking.
https://bugzilla.gnome.org/show_bug.cgi?id=752240
We changed the behaviour of this API to adapt to a change in the D-Bus
specification. Document the new behaviour, along with the time of the
change.
https://bugzilla.gnome.org/show_bug.cgi?id=755421
gdbus sets NO_REPLY_EXPECTED when no callback is given to
g_dbus_connection_call(). It makes sense that it also handles the server
side correctly by discarding replies to clients that don't want one.
https://bugzilla.gnome.org/show_bug.cgi?id=755421
This causes several problems:
- Compilation in FreeBSD with --enable-gtk-doc broke
- Modules that still use the AM_GLIB_GNU_GETTEXT macro
doesnt compile anymore because /usr/share/glib-2.0/gettext
is not filled with the correct files, as this was done in
the glib custom po/Makefile.in.in
See https://bugzilla.gnome.org/show_bug.cgi?id=622991
This reverts commit e5c752371c.
I think it is a recursion from the GUnixMountMonitor constructor, to a
GLocalFileMonitor on /etc/fstab, and into GUnixMountMonitor again, now
with a mutex already held, so it deadlocks.
https://bugzilla.gnome.org/page.cgi?id=traceparser/trace.html&trace_id=235354
That mutex in glocalfile.c:g_local_file_find_enclosing_mount() doesn't
seem necessary any more IMHO. Inside it, only 'mount' is modified, but
that's just a stack variable local to this function. When
klass->get_mount_for_mount_path is called, it's given one const
parameter and the other is unused, so they're unchanged. 'klass'
doesn't seem it could be modified either inside that function.
It doesn't recurse infinitely, but seems to work correctly and pass the
testsuite after this change.
The FreeBSD project already applied my patch in their ports tree, and
their users seem happy with it.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712848#64
and https://bugzilla.gnome.org/show_bug.cgi?id=753378
As g_win32_get_command_line() calls CommandLineToArgvW() to acquire the
arguments passed into a GApplication program, it actually returns the
whole command line which is used to invoke the program, including the
script interpreter and its flags when a script using GNOME bindings
(e.g. PyGObject and so on) is being invoked.
The issue here is that g_application_run() would most probably have
trouble in the scripts scenario on Windows as it is likely unable to
"recognize" the script interpreter, causing such scripts to fail to run.
Largely based on the patch by Ray Donnelly <mingw.android@gmail.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=734095
Otherwise, we'll acquire it on every loop iteration, which can leave us
vulnerable to racing another thread for the acquisition of the main
context.
This can break methods like g_main_context_invoke, which try to acquire
a context to figure out if it can invoke the method synchronously or
need to defer to an idle. In these cases, it isn't guaranteed that the
invocation function will be invoked in the default main context,
e.g. the one that GApplication is holding.
This also matches what GMainLoop is doing.
https://bugzilla.gnome.org/show_bug.cgi?id=752983
* On W32 use a real directory (SYSTEMROOT) instead of '/etc/'
* Disable test_symbolic_icon() as it can't be passed (symbolic icons are not
really supported)
* PowerPoint/Gettext test still fails, presumably because msvcrt qsort() moves
the entires (both have the same priority)
https://bugzilla.gnome.org/show_bug.cgi?id=735696
Allocate an empty cache object, check cache objects for being empty
before using them.
Otherwise the code will re-read cache every 5 seconds, as NULL cache
does not trigger the code that stores mtime, which makes the cache
file appear modified/unloaded permanently.
https://bugzilla.gnome.org/show_bug.cgi?id=735696
As per #578363, "if one requests e.g. strings via GOptionEntry.arg_data
then those are strduped and needs to be free'ed by the application."
Fixes following leak:
=================================================================
==29426==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 10 byte(s) in 1 object(s) allocated from:
0 0x7f3ab783d37a in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x9437a)
1 0x7f3ab70f7c82 in g_malloc /home/lebedevri/src/glib/glib/gmem.c:94
2 0x7f3ab70f7f60 in g_malloc_n /home/lebedevri/src/glib/glib/gmem.c:330
3 0x7f3ab713258e in g_strndup /home/lebedevri/src/glib/glib/gstrfuncs.c:425
4 0x7f3ab709c86b in strdup_len /home/lebedevri/src/glib/glib/gconvert.c:864
5 0x7f3ab709c966 in g_locale_to_utf8 /home/lebedevri/src/glib/glib/gconvert.c:905
6 0x7f3ab7103c32 in parse_arg /home/lebedevri/src/glib/glib/goption.c:1276
7 0x7f3ab71066fb in parse_long_option /home/lebedevri/src/glib/glib/goption.c:1670
8 0x7f3ab7108047 in g_option_context_parse /home/lebedevri/src/glib/glib/goption.c:1997
9 0x408532 in main /home/lebedevri/src/glib/gio/glib-compile-resources.c:629
10 0x7f3ab6c72b44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b44)
https://bugzilla.gnome.org/show_bug.cgi?id=757299
It's theoretically possible (and see in the wild) for D-Bus messages to
come in to the application after shutdown() has been called and while
we're draining out the lingering events in the main context.
Prevent this from happening by ensuring we unregister our objects on
D-Bus during the shutdown process.
https://bugzilla.gnome.org/show_bug.cgi?id=757372
Bug 13403 introduced support for the non-POSIX variants of these APIs
found on a system called "DG/UX". Meanwhile, the complicated checks
here are breaking cross-builds on systems that we actually care about.
Remove the complicated checks and replace them with AC_CHECK_FUNCS.
Remove the resulting dead code from a couple of .c files.
https://bugzilla.gnome.org/show_bug.cgi?id=756475
Add various (nullable) and (optional) annotations which were missing
from a variety of functions. Also port a couple of existing (allow-none)
annotations in the same files to use (nullable) and (optional) as
appropriate instead.
Secondly, add various (not nullable) annotations as needed by the new
default in gobject-introspection of marking gpointers as (nullable). See
https://bugzilla.gnome.org/show_bug.cgi?id=729660.
This includes adding some stub documentation comments for the
assertion macro error functions, which weren’t previously documented.
The new comments are purely to allow for annotations, and hence are
marked as (skip) to prevent the symbols appearing in the GIR file.
https://bugzilla.gnome.org/show_bug.cgi?id=719966
Commit 8ece2de964 transplanted a block of
code that contained an early-exit-on-error case which freed several
variables.
Because of the move, the normal-path unconditional free of one of these
variables is now above this early exit case, so if this block is hit, it
will now be a double-free.
Remove that.
https://bugzilla.gnome.org/show_bug.cgi?id=757693
It was removed, apparently accidentally, in commit 5b48dc4.
This had the side-effect that it wasn't included in tarball releases,
which means that commit ab7b4be doesn't work when building a package.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=734469
Reviewed-by: Colin Walters <walters@verbum.org>
The new "slowly add more task threads" code doesn't fully deal with
apps that queue lots and lots of tasks which then block on tasks from
their task threads. Fix this by bringing back the "task is blocking
other task" check and making sure that such tasks get bumped to the
front of the queue.
https://bugzilla.gnome.org/show_bug.cgi?id=687223
