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
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
Rather of calling .exists() synchronously for all documents, use
ShellDocSystem's async API to only stat docs we're showing.
Use the doc opening functionality in ShellDocSystem.
Also, more intelligently do redisplay(); don't recreate actors
for recent docs if we already have one for that URI. We may
need more intelligent caching here; if e.g. just the associated
application changes, we should probably reread the info.
https://bugzilla.gnome.org/show_bug.cgi?id=603522
This should not be required, since glib correctly deals with such
applications by giving them the local gvfs path, and those
applications which do support URIs keep being able to use the URIs in
GFiles.
Based on original work by Guido Günther <agx@sigxcpu.org>.
https://bugzilla.gnome.org/show_bug.cgi?id=601287
Fix to not trigger a warning like:
JS ERROR: !!! WARNING: 'anonymous function does not always return a value'
by adding a return ""; at the end of the anonymous function.
https://bugzilla.gnome.org/show_bug.cgi?id=595661
Add String formatting by extending the String object with a
format method.
Now we can do stuff like "Text: %s, %d".format(somevar, 5)
This is required for proper translation of some strings.
https://bugzilla.gnome.org/show_bug.cgi?id=595661
The design has smaller icons in two columns. Add a new
custom display to docDisplay for it.
Clean up some of the texture cache handling for recent URIs so
it's not size-dependent, since the dash size is now different
from the default GenericDisplay size.
Extend ShellTextureCache by adding the concept of a policy, which
we expose to the public API for loading URIs.
This lets us have the shell tell the cache to keep the information
icon texture around forever.
Secondly, fix the caching of recent info; we shouldn't always be
loading the backup pixbuf. Move recent info loading entirely
into ShellTextureCache.
Move thumbnail creation into ShellTextureCache. It's now asynchronous,
and we cache the result.
Create a DocManager class which keeps around the DocInfo objects between
invocations. This is also where we ensure we remove thumbnails for
recent items not known anymore.
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.
Clutter no longer allows using a clone of an actor that is not a part of
the scene graph. This is what used to happen when we created a clone for
the icon of the item that was being dragged, and then closed the More panes
with the original item, removing the icon from the scene graph. This was
also when happened when the user hit Esc while dragging, which prompted the
overlay to close, removing the original icon from the scene graph.
Rename getIcon() methods to createIcon() to better reflect on the fact that
a new icon is created each time the method is called (we do use cache in
some cases).
Remove a stray log message in overlay.js
Fixes http://bugzilla.gnome.org/show_bug.cgi?id=585490
and http://bugzilla.gnome.org/show_bug.cgi?id=585489
The new class AppWell implements the application favorite well
in the Dash component. The previous AppDisplay remains for use
in the More... mode now.
Delete DEFAULT_APPLICATIONS; this is now in GConf.
Rename getMostUsedApps to getTopApps since we now have the
idea of explicit favorites.
Delete some GenericDisplay-related calls from overlay related
to the seletion - we'll reimplement keyboard nav in a more
coherent way later.
We achieve this with two changes:
- Move the Shell.get_thumbnail call in DocInfo from _init
to getIcon, so that it isn't executed until it's actually
needed.
(If caching the output of said call permanently is desired
we could still do it on the first getIcon invocation, but
I don't believe this is necessary given that looking up an
already generated icon is pretty fast and this also gives
us an updated icon in case the file changes.)
- More importantly, we ommit the get_thumbnail call in case
the URI doesn't start with file://. Looking up, for example,
an http:// URI is very slow, and doesn't give us an icon anyway.
http://bugzilla.gnome.org/show_bug.cgi?id=586539
With commit a3d35af444 variable
itemInfo in js/ui/appDisplay.js was changed to a new object
(AppInfo from js/misc/appInfo.js) but some of the code in
js/ui/appDisplay.js wasn't updated accordingly. This commit
fixes that and makes the search box in the overlay usable
again.
This lets us share the recent-app-tracking, recent-file-tracking, and
icon-drawing code between the overlay and the sidebar, without the
sidebar having to poke into AppDisplayItem and DocDisplayItem's guts.
