The first time this function is called we load all of the keyfiles in
the directory, ignoring the 'Hidden' ones and build an index out of the
interesting fields using g_str_tokenize_and_fold().
We do prefix matching on the tokens to find relevent desktop files.
Right now this is implemented as a hashtable that we iterate over,
checking prefixes on each token. This could possibly be sped up by
creating an array, but it's already pretty fast...
https://bugzilla.gnome.org/show_bug.cgi?id=711557
In each DesktopFileDir, store a list of desktop files for that
directory. This speeds up opening desktop files by name because we can
skip statting in directories that we know don't have the file and also
speeds up _get_all() because we can avoid enumeration.
This also improves our support for dealing with names like
'kde4/kate.desktop' (equivalent to kde4-kate.desktop) since we find out
about all of these files are the start and don't need to guess about
which '-' to change to a '/'. It also means that we can easily deal
with more than one level of such prefixes.
We use a file monitor to watch for changes, invalidating our lists when
we notice them.
https://bugzilla.gnome.org/show_bug.cgi?id=711520
Fix up a lot of whitespace issues in this file since we're about to do
some pretty serious rewriting here anyway...
Add some fold markers while we're at it.
Change the search path to be a global array of 'DesktopFileDir' structures and
change the 'get' function to an 'ensure' function.
This is just a straight-up refactor. Future patches will expand the
DesktopFileDir structure.
Rather than always calling out to g_file_get_path() (which
might block, whatever the documentation might say), postpone
the call until we actually need it.
https://bugzilla.gnome.org/show_bug.cgi?id=708753
A previous version of the patch had OnlyShowIn support for desktop file
actions. This was removed from the spec and the patch rewritten, but
this bit of documentation slipped through. Remove it.
For some time, the desktop file specification has supported "additional
application actions". This is intended to allow for additional methods
of starting an app, such as a mail client having a "Compose New Message"
action that brings up the compose window instead of the folder list.
This patch adds support for this with a relatively minimal API.
In the case that the application is a GApplication and DBusActivatable,
desktop actions are translated into GActions that have been added to the
application with g_action_map_add_action(). This more or less closes
the loop on being able to activate an application with an action
invocation (instead of 'activate').
https://bugzilla.gnome.org/show_bug.cgi?id=664444
There are two benefits to this:
1) We can centralize any operating system specific knowledge of
close-vs-EINTR handling. For example, while on Linux we should never
retry, if someone cared enough later about HP-UX, they could come by
and change this one spot.
2) For places that do care about the return value and want to provide
the caller with a GError, this function makes it convenient to do so.
Note that gspawn.c had an incorrect EINTR loop-retry around close().
https://bugzilla.gnome.org/show_bug.cgi?id=682819
gnome-session needs to know the startup id that was given to
a started app; this was not available via GAppLaunchContext.
This commit adds a ::launched signal to get this information.
At the same time, turn the launch_failed vfunc into a signal
as well.
https://bugzilla.gnome.org/show_bug.cgi?id=688497
gnome-session still uses EggDesktopFile, since GDesktopAppInfo is
missing a handful of APIs that are needed to implement the
autostart spec. This patch adds the minimum that is required.
https://bugzilla.gnome.org/show_bug.cgi?id=688497
Many (if not "almost all") programs that spawn other programs via
g_spawn_sync() or the like simply want to check whether or not the
child exited successfully, but doing so requires use of
platform-specific functionality and there's actually a fair amount of
boilerplate involved.
This new API will help drain a *lot* of mostly duplicated code in
GNOME, from gnome-session to gdm. And we can see that some bits even
inside GLib were doing it wrong; for example checking the exit status
on Unix, but ignoring it on Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=679691
We need to ignore the defaults.list item only when there
was a mimetype handler found in a previous mimetype, not
if one was found for the same mimetype as the one that
is listed in defaults.list (same for the new-style defaults).
There was an issue when looking up the default handler
for a type where a supertype was listed in defaults.list.
We would pick the default for the parent type even if
there was a handler for the more specific type.
In the case of the new-style defaults marking (
"Default Applications" in mimeapps.list) we were already
checking for a more specific handler befor using a default,
but we also need to do a similar check for the defaults.list
case.
https://bugzilla.gnome.org/show_bug.cgi?id=678944
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
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
Add new macros to disable -Wdeprecated-declarations around a piece of
code, using the C99 (and GNU89) _Pragma() operator. Replace the
existing use of #pragma for this in gio, and suppress the warnings in
gvaluearray.c as well.
https://bugzilla.gnome.org/show_bug.cgi?id=669671
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
