Add functions for manipulating the environment under which a
GAppLaunchContext will launch its children, to avoid thread-related
bugs with using setenv() directly.
FIXME: win32 side isn't implemented yet
https://bugzilla.gnome.org/show_bug.cgi?id=659326
With search gaining traction as being the preferred way to locate
applications, the existing .desktop file fields meant for browsing
often produce insufficient results.
gnome-control-center introduced a custom X-GNOME-Keywords field for
that purpose, which we plan to support in gnome-shell as well.
https://bugzilla.gnome.org/show_bug.cgi?id=661763
Previously, we took the default application for a particular mimetype
from the system and copied it into the user's configuration as the
default there.
Instead of doing that we leave the user's default unset, and at time of
use, if the user has no explicitly-set default value, we use the system
default.
This avoids complicated situations where inappropriate applications were
being set as the default in the user's configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=658188
* Do not ignore the system default
* Do not exclude the last used being set from the default list
This fixes the default applications dialog in control-center.
https://bugzilla.gnome.org/show_bug.cgi?id=658188
g_desktop_app_info_set_as_default_for_type() and
g_desktop_app_info_set_as_last_used_for_type () require the
application's ID, but depending on how the GAppInfo was created,
we might not be have one, and would thus silently fail to set
the default application, or last used application.
https://bugzilla.gnome.org/show_bug.cgi?id=657445
GDesktopAppInfo violates the GObject rule that your C constructors
should just be thin wrappers around g_object_new(). While GKeyFile
isn't introspctable, this patch allows from JavaScript:
var app = new Gio.DesktopAppInfo({ filename: '/path/to/foo.desktop' });
https://bugzilla.gnome.org/show_bug.cgi?id=648425
We were considering explicitly configured defaults for parent types
after we already got results for the specific type we're interested in.
This resulted in the explicit default for text/plain to override all
system defaults for subtypes of text/plain, for example. The explicit
default should not apply to subtypes that have a system default.
https://bugzilla.gnome.org/show_bug.cgi?id=642797
This will help applications such as zeitgeist's datahub to collect
more complete information about application launches, as the "actor"
of a launch is important for zeitgeist's magic to work properly.
If we were the initial connection owner, unref will destroy the
connection immediately, and we may lose messages. Asynchronously
flush to avoid that.
https://bugzilla.gnome.org/show_bug.cgi?id=641411
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
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
We want to be compatible with the following situation:
- there's no explicit default set in mimeapps.list
- we add support for a content type to a specific application, and that
list is empty
- the default should be picked from the system list, not overridden by
the user-added application.
So we make the default explicit in this case, by adding it to the
relevant section in mimeapps.list.
https://bugzilla.gnome.org/show_bug.cgi?id=637675
This commit also changes (maintaining compatibility) the way
user-specified default applications are stored (as in, those for which
g_app_info_set_as_default_for_type() has been called.
We now store the default application for a content type in a new group
in the mimeapps.list keyfile, and "Added Associations" tracks only the
applications that have been added by the user, following a
most-recently-used first order.
This is useful in GtkAppChooser-like widgets to pre-select the last used
application when constructing a widget.
https://bugzilla.gnome.org/show_bug.cgi?id=636311
Otherwise you break the fallback + recommended distinction for a content
type, as you end up adding support for a given content type to *all* of
the applications claiming to support the supertype.
This ways UIs can differentiate between them, and show them in different
section.
- a recommended app is an application that claims to support a content
type directly, not by a supertype derivation.
- a fallback app is an application that claims to support a supertype of
a given content type.
Removing an extension point is an API and ABI break. In particular, it
causes (older) gvfs versions to fail loading with a linkage error from
ld which in turn makes the desktop unusable.
So this reinstate the extension point and API provided by it, but
deprecates and does not use it. So no functionality is changed.
This reverts parts of commit 9b262f1c5f.
Complaints-Also-To: Ryan Lortie <desrt@desrt.ca>
Move all the annotations over from gobject-introspection.
They will not be used directly by the introspection scanner for now,
instead they will be extracted by a script and updated manually
until introspection is properly integrated into the glib build
