If code creates a GDesktopAppInfo via g_desktop_app_info_new_from_keyfile(),
we'd try to send a NULL pointer down into GVariant.
Since in this case we don't have a filename, just send the empty
string. In the future we should either:
1) Change panel to use g_desktop_app_info_new_from_filename(), and
take the hit of parsing the file twice.
2) Add a g_key_file_get_origin_filename()
3) Add g_desktop_app_info_new_from_keyfile_and_name()
https://bugzilla.gnome.org/show_bug.cgi?id=638838
Add missing properties in the GDummyTlsConnection class. Also add
namespaces to property enumerations to avoid conflicts between classes.
Reviewed-by: Dan Winship <danw@gnome.org>
This property is now a GList of GByteArray values. Each
GByteArray contains the raw DER DN of the certificate authority.
This is far more useful for looking up a certificate (with the
relevant issuer) than a string encoded DN.
https://bugzilla.gnome.org/show_bug.cgi?id=637262
A new GDesktopAppInfo specific function which provides more control
over launched processes. Intended basically only for use in GNOME
Shell, where we want:
*) To directly know the GPid for each launched program, without
having to listen to a DBus signal emitted in our own process
*) Possibly control over the process environment; for example,
we may want to call setsid() or redirect file descriptors.
And in the future:
*) To avoid recursively calling ourself via DBus, when a later
patch causes g_app_info_launch() to indirect via the shell.
https://bugzilla.gnome.org/show_bug.cgi?id=606960
This signal contains the full path of the .desktop file, along with
the process id, which allows multiple interested components (like
GNOME Shell) to better know the state of the system (which processes
correspond to which .desktop files).
https://bugzilla.gnome.org/show_bug.cgi?id=606960
Due to changes in the GIO APIs/headers, the glib.vsprops
is updated to reflect that in the "install" phase, namely:
-removal of the gperiodic.h header
-addition of GPollable I/O Stream, GTCP Connection and
GTLS headers
Use `git describe` to fill out the <revision> node, if we're using a
git checkout; otherwise, for tests ran from a released tarball, use
the version.
https://bugzilla.gnome.org/show_bug.cgi?id=631980
In order to distinguish reports generated from a specific revision of a
projects it would be good if gtester-report handled a <revision> node in
the XML.
The payload is free-form, just like for the other nodes under <info>.
https://bugzilla.gnome.org/show_bug.cgi?id=631980
