Adds a content type to the application information to indicate the application is capable of opening files with the given content type.
Obtains the information whether the #GAppInfo can be deleted. See g_app_info_delete().
Checks if a supported content type can be removed from an application.
Tries to delete a #GAppInfo.
Creates a duplicate of a #GAppInfo.
Checks if two #GAppInfos are equal.
Get the main Gtk struct
Gets the commandline with which the application will be started.
Gets a human-readable description of an installed application.
Gets the display name of the application. The display name is often more descriptive to the user than the name itself.
Gets the executable's name for the installed application.
Gets the icon for the application.
Gets the ID of an application. An id is a string that identifies the application. The exact format of the id is platform dependent. For instance, on Unix this is the desktop file id from the xdg menu specification.
Gets the installed name of the application.
Retrieves the list of content types that @app_info claims to support. If this information is not provided by the environment, this function will return %NULL. This function does not take in consideration associations added with g_app_info_add_supports_type(), but only those exported directly by the application.
Launches the application. Passes @files to the launched application as arguments, using the optional @launch_context to get information about the details of the launcher (like what screen it is on). On error, @error will be set accordingly.
Launches the application. This passes the @uris to the launched application as arguments, using the optional @launch_context to get information about the details of the launcher (like what screen it is on). On error, @error will be set accordingly.
Removes a supported type from an application, if possible.
Sets the application as the default handler for the given file extension.
Sets the application as the default handler for a given type.
Sets the application as the last used application for a given type. This will make the application appear as first in the list returned by g_app_info_get_recommended_for_type(), regardless of the default application for that content type.
Checks if the application info should be shown in menus that list available applications.
Checks if the application accepts files as arguments.
Checks if the application supports reading files and directories from URIs.
#GAppInfo and #GAppLaunchContext are used for describing and launching applications installed on the system.
As of GLib 2.20, URIs will always be converted to POSIX paths (using g_file_get_path()) when using g_app_info_launch() even if the application requested an URI and not a POSIX path. For example for an desktop-file based application with Exec key `totem %U and a single URI, sftp://foo/file.avi`, then /home/user/.gvfs/sftp on foo/file.avi will be passed. This will only work if a set of suitable GIO extensions (such as gvfs 2.26 compiled with FUSE support), is available and operational; if this is not the case, the URI will be passed unmodified to the application. Some URIs, such as mailto:, of course cannot be mapped to a POSIX path (in gvfs there's no FUSE mount for it); such URIs will be passed unmodified to the application.
Specifically for gvfs 2.26 and later, the POSIX URI will be mapped back to the GIO URI in the #GFile constructors (since gvfs implements the #GVfs extension point). As such, if the application needs to examine the URI, it needs to use g_file_get_uri() or similar on #GFile. In other words, an application cannot assume that the URI passed to e.g. g_file_new_for_commandline_arg() is equal to the result of g_file_get_uri(). The following snippet illustrates this:
|[ GFile *f; char *uri;
file = g_file_new_for_commandline_arg (uri_from_commandline);
uri = g_file_get_uri (file); strcmp (uri, uri_from_commandline) == 0; g_free (uri);
if (g_file_has_uri_scheme (file, "cdda")) { // do something special with uri } g_object_unref (file); ]|
This code will work when both cdda://sr0/Track 1.wav and /home/user/.gvfs/cdda on sr0/Track 1.wav is passed to the application. It should be noted that it's generally not safe for applications to rely on the format of a particular URIs. Different launcher applications (e.g. file managers) may have different ideas of what a given URI means.