The way we were loading data into a CoglTexture, then pulling it out
and manipulating it on the CPU, then loading it back into a texture
was a bit lame.
Clean things up a bit here by loading directly into the CPU, doing
the fading, then creating a texture.
Also cache the faded data in StTextureCache.
https://bugzilla.gnome.org/show_bug.cgi?id=612759
Brute force merge these two by essentially replacing St.TextureCache
with a (renamed) Shell.TextureCache.
One function was added for convenience, namely "st_texture_cache_load_file_simple".
St.TextureCache had a function to load a texture from a filename, and it
returned NULL on error but only half the callers actually checked this. This
function is better.
https://bugzilla.gnome.org/show_bug.cgi?id=607500
In case of duplicate infos structures with the same id, the
info structures we get from looking up the id in app_id_to_info
aren't necessarily the same as those we used to match, so we
can't rely on matching to implicitly initialize info->casefolded_name.
Since the name collation key isn't used in matching results,
just in sorting, init it on-demand in the sorting which is also more
efficient.
The high level goal is to separate the concern of searching for
things with display of those things; for example in newer mockups,
applications are displayed exactly the same as they look in the
AppWell.
Another goal was optimizing for speed; for example,
application search was pushed mostly down into C, and we avoid
lowercasing and normalizing every item over and over.
https://bugzilla.gnome.org/show_bug.cgi?id=603523
The two parts were mapping windows to applications, and
recording application usage statistics. The latter part
(now called ShellAppUsage) is much more naturally built on top of
the former (now called ShellWindowTracker).
ShellWindowTracker retains the startup-notification handling.
ShellWindowTracker also gains a focus-app property, which is
what most things in the shell UI are interested in (instead of
window focus).
ShellAppSystem moves to exporting ShellApp from more of its
public API, rather than ShellAppInfo. ShellAppSystem also
ensures that ShellApp instances are unique by holding
a hash on the ids.
ShellApp's private API is split off into a shell-app-private.h,
so shell-app.h can be included in shell-app-system.h.
Favorites handling is removed from ShellAppSystem, now inside
appFavorites.js.
Port all of the JavaScript for these changes.
https://bugzilla.gnome.org/show_bug.cgi?id=598646
Clean up the vendor prefix handling a bit, and add "mozilla" so that
we pick up "mozilla-firefox.desktop" from Firefox's (recent?) change
to have a WM_CLASS of "Firefox".
This is a start at the "Active Appliction Item" component of the
shell design. Currently we just show the currently focused
application. When launching a new application, we show that as well.
The implementation here is not complete; basically when launching
we de-focus the active one, and the application well shows the
most recent startup sequence.
This kind of fails in the case of multiple sequences, and we
also don't correctly de-focus the current window in other
launch paths.
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.
