Pass the error variable to g_key_file_load_from_data_dirs in
Shell.AppSystem.get_default().load_from_desktop_file again, and
use a try/catch in places.js.
- Avoid error '"iconname" may be used uninitialized in this function'
by initializing said variable to NULL.
- Define shell_util_get_file_description as static (like the other
similar functions) to avoid another compiler error.
- Don't save errors from g_key_file_load_from_data_dirs into the
variable "error" (ie. pass NULL to it instead). Without this,
gnome-shell crashes if the key file can't be found (with message
"Error invoking Shell.load_from_desktop_file: Valid key file could
not be found in search dirs").
- Check the result of the load_from_desktop_file() call in places.js,
as it may be null.
Previously, ShellAppSystem only loaded (and cached) the set of
.desktop files from applications.menu and settings.menu, using
the gnome-menus library. The ShellAppInfo structure was
a "hidden typedef" for GMenuTreeEntry.
But we need to support loading an arbitrary .desktop file. Thus,
refactor the ShellAppInfo into a real struct, with a refcount,
and allow it to point to either a GMenuTreeEntry or a GKeyFile.
Also, in the case where we fail to lookup an icon for an
application, ensure we return a 0 opacity texture.
For both of these, because of optimizations a few patches ago, we
ended up relying on hash table ordering which caused instability
in the application well among other things. Define an ordering
for both.
The favorites is just the order of the GConf keys, and new items
get appended. In the future we should allow insertion at any
point which the grid could use.
For running applications order, define a new "initially_seen_sequence"
transient variable which is just an monotonically incrementing
integer assigned to an application for the first time we saw it
running in this session. When an application is closed, it's reset.
Before, we looked up application data in several ways; the ShellAppSystem
exported just application ids (though it parsed the .desktop files internally),
and we'd create a Gio.DesktopAppInfo object (reparsing the desktop file again),
wrapping that inside a JavaScript AppInfo class, and finally the AppDisplay
would again parse the .desktop file to get the categories.
Also, to look up applications by id previously, we traversed the entire
menu structure each time.
Some qualities such as the NoDisplay flag were not easily exposed in the old
system. And if we wanted to expose them we'd have to change several different
application information wrapper classes.
All in all, it was quite suboptimal.
The theme of this new code is basically "just use libgnome-menus". We do
not call into Gio for app lookups anymore. The new Shell.AppInfo class
is a disguised pointer for the GMenuTreeEntry item.
To fix the caching, we keep a simple hash table of desktop id -> ShellAppInfo.
Searching across NoDisplay desktop items can produce weird
results to the user (including duplicates, and items that
aren't really applications at all.) So, don't include them
normally.
But continue including NoDisplay items when we look up the
desktop file for a window, since we want to catch applications
like Evince and Nautilus which are otherwise NoDisplay.
http://bugzilla.gnome.org/show_bug.cgi?id=587548
Add a GConf key for favorites, and API for retrieving them.
Also add shell_app_system_lookup_basename, which we use from
the app monitor to look up WM_CLASS ids.
To avoid loading applications from two different systems, use
ShellAppSystem solely. This unifies the initial load and the
reload.
Extend ShellAppSystem to also load settings/preferences, and
ensure they appear in the search.
