gcc gets upset when we do "((GDestroyNotify) destroy) (_p)" because
it's non-portable. But we don't care; we already know glib wouldn't
work on any platform where different pointer types have different
calling conventions. So tweak the code to avoid the warning.
https://bugzilla.gnome.org/show_bug.cgi?id=674634
This essentially adds an accessor for the MimeType field in desktop files,
to retrieve the list of all mime types supported by an application.
The interface though is part of GAppInfo, so it could be implemented
in the future by other backends.
https://bugzilla.gnome.org/show_bug.cgi?id=674111
The logic here is pretty twisted, but basically we were leaking a ref
for each non-existent parent. The clearest way to fix this was to
move to more explicit refcounting logic; when a variable is pointing
to an object, it holds a ref.
https://bugzilla.gnome.org/show_bug.cgi?id=675446
Not doing so is an evil trap, sadly. This patch has been
compile-checked on Fedora 16, and I've verified that the generated
config.status and config.h is exactly the same.
https://bugzilla.gnome.org/show_bug.cgi?id=674483
This way any prerequisites for e.g. AC_CHECK_HEADER are always executed
before the 'if'.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
https://bugzilla.gnome.org/show_bug.cgi?id=674483
-Make up for the missed DLL_EXPORT-it's actually needed for all GLib DLL
builds, omitting this caused problems to surface due to recent works to
make GDBus work on Windows.
-Also use the FFI_BULIDING macro for GObject builds as the suggessted
workaround for using static LibFFI builds (as we do now)-please see
ffi.h(.in). This will fix the build of GObject against LibFFI 3.0.11,
but it is probable that this will change at some point for LibFFI.
If action-if-found is not specified, AC_CHECK_LIB will append the library
to LIBS. As we don't want to link everything against libelf, reset LIBS
after doing the checks.
Provide public access to the GDBusConnect and object path that
GApplication is using. Prevents others from having to guess these
things for themselves based on the application ID.
https://bugzilla.gnome.org/show_bug.cgi?id=671249
g_output_stream_write_async() was not initializing the newly-added
members of the WriteData structure, causing various problems.
Also, g_input_stream_read_async() was now leaking its cancellable. Fix
that as well.
https://bugzilla.gnome.org/show_bug.cgi?id=674612
If the launch context is a GAppLaunchContext, and not a
GdkAppLaunchContext, then g_app_launch_context_get_display will return
NULL because the get_display virtual method is undefined. The DISPLAY
might still be inherited from the parent process, in which case
overwriting it with NULL breaks the launch.
This is a regression introduced in:
de834bed30
Fixes: https://bugzilla.gnome.org/672786
Commit f084b60377 incorrectly set
DIST_SUBDIRS for the toplevel Makefile.am. In general actually we
don't need to set it, because modern automake automatically sets
it by looking at conditionals for SUBDIRS.
Tested-by: Rico Tzschichholz <ricotz@t-online.de>
https://bugzilla.gnome.org/show_bug.cgi?id=667806
