touch-packages team mailing list archive
-
touch-packages team
-
Mailing list archive
-
Message #45571
[Bug 1324142] Re: Support providing fallback images
It looks like, over time, a number of additional fields have crept into
the JSON, most likely because scope authors and the shell have made
gentlemen's agreements. This includes (at least), mascot, emblem,
attributes, summary, background, and overlay-color. It also looks like
there are result-specific settings (such as mascot) that are
undocumented, and for which there is no accessor/setter in the Result or
SearchResult classes.
We need to construct a definitive list of which fields are used by the
shell, both per-category and per-result, so we can document them.
Otherwise, all these features will remain inaccessible to outside scope
authors.
As discussed with Saviq on IRC, he'll find someone who can construct
this list by inspecting the shell code, so we can update the scopes
documentation accordingly.
In future, whenever the shell interprets something new in the JSON, or
changes the meaning of an existing entry, we'll need to raise a bug with
scopes-api so we can update the doc.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unity-scopes-shell in
Ubuntu.
https://bugs.launchpad.net/bugs/1324142
Title:
Support providing fallback images
Status in Thumbnail generator for all kinds of files:
New
Status in unity-scopes-api package in Ubuntu:
In Progress
Status in unity-scopes-shell package in Ubuntu:
New
Status in unity8 package in Ubuntu:
Triaged
Bug description:
If the URI for a scope result icon can not be loaded, the scope result
is not easily visible.
To counter this, the shell should replace the result image with a
fallback image if the Image QML component changes to the Error state.
At a minimum a single standard fallback image would be sufficient, but
letting the scope pick a custom fallback via the category renderer
template would be better.
One reason I'd like to see this is so we can switch the album art
image provider to stop returning a fallback image. This has been
requested by the music-app guys, and seems sensible since we might
want different fallbacks in different contexts:
https://code.launchpad.net/~jamesh/thumbnailer/no-fallback-
albumart/+merge/219460
It might also be useful for remote scopes using http: URIs for result
icons.
To manage notifications about this bug go to:
https://bugs.launchpad.net/thumbnailer/+bug/1324142/+subscriptions