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(). Since 2.20
Checks if a supported content type can be removed from an application.
Tries to delete a GAppInfo. On some platforms, there may be a difference between user-defined GAppInfos which can be deleted, and system-wide ones which cannot. See g_app_info_can_delete(). Virtual: do_delete Since 2.20
Creates a duplicate of a GAppInfo.
Checks if two GAppInfos are equal.
Gets the commandline with which the application will be started. Since 2.20
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. Since 2.24
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. Note that the returned ID may be NULL, depending on how the appinfo has been constructed.
Gets the installed name of 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. To launch the application without arguments pass a NULL files list. Note that even if the launch is successful the application launched can fail to start if it runs into problems during startup. There is no way to detect this. Some URIs can be changed when passed through a GFile (for instance unsupported uris with strange formats like mailto:), so if you have a textual uri you want to pass in as argument, consider using g_app_info_launch_uris() instead. On UNIX, this function sets the GIO_LAUNCHED_DESKTOP_FILE environment variable with the path of the launched desktop file and GIO_LAUNCHED_DESKTOP_FILE_PID to the process id of the launched process. This can be used to ignore GIO_LAUNCHED_DESKTOP_FILE, should it be inherited by further processes. The DISPLAY and DESKTOP_STARTUP_ID environment variables are also set, based on information provided in launch_context.
Launches the application. Passes 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. To lauch the application without arguments pass a NULL uris list. Note that even if the launch is successful the application launched can fail to start if it runs into problems during startup. There is no way to detect this.
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.
Creates a new GAppInfo from the given information.
Gets a list of all of the applications currently registered on this system. For desktop files, this includes applications that have NoDisplay=true set or are excluded from display by means of OnlyShowIn or NotShowIn. See g_app_info_should_show(). The returned list does not include applications which have the Hidden key set.
Gets a list of all GAppInfos for a given content type.
Gets the GAppInfo that corresponds to a given content type.
Gets the default application for launching applications using this URI scheme. A URI scheme is the initial part of the URI, up to but not including the ':', e.g. "http", "ftp" or "sip".
Gets a list of fallback GAppInfos for a given content type, i.e. those applications which claim to support the given content type by MIME type subclassing and not directly. Since 2.28
Gets a list of recommended GAppInfos for a given content type, i.e. those applications which claim to support the given content type exactly, and not by MIME type subclassing. Note that the first application of the list is the last used one, i.e. the last one for which g_app_info_set_as_last_used_for_type has been called. Since 2.28
Utility function that launches the default application registered to handle the specified uri. Synchronous I/O is done on the uri to detect the type of the file if required.
Removes all changes to the type associations done by g_app_info_set_as_default_for_type(), g_app_info_set_as_default_for_extension(), g_app_info_add_supports_type() or g_app_info_remove_supports_type(). Since 2.20
the main Gtk struct
Description 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; // FALSE 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.