ubuntu-appstore-developers team mailing list archive

[Michał Sawicz <michal.sawicz@xxxxxxxxxxxxx>]

On 24.04.2014 18:42, Alejandro J. Cura wrote:
> On Tue, Apr 22, 2014 at 11:47 AM, Michał Sawicz
> <michal.sawicz@xxxxxxxxxxxxx> wrote:
>> On 22.04.2014 16:40, Alejandro J. Cura wrote:
>>> Now, what would be the best place in our software stack to choose
>>> among the available icon sizes?
>>> We do not want the webservice to be sending the list of all available
>>> icon urls with each result, and we don't want the scope or dash to
>>> have hardcoded icon sizes to choose from, so my suggestion is:
>>>
>>> - the dash tells the scope the requested width when doing a search
>>> - the scope passes that to the webservice
>>> - the webservice uses that as a hint to select the next-biggest size
>>> and return the appropriate url.
>>
>> I'm afraid that's not an option. The UI only knows the size of the image
>> needed when creating the delegate for it, since it doesn't know what
>> will the layout be when searching. I agree pushing the whole set of
>> available sizes isn't good, either.
> 
> How is that size calculated, and how many possible sizes there are for
> a given device?
> Looking at http://bit.ly/scopes-json I'm hopeful that there are a few
> ("small", "medium" (default), "large"), and that we calculate them
> when changing the device orientation or the output screen, and can
> pass all three of them in the search hints.
> Though I see that they may change on category-layout (they already do
> for vertical-journal), and in that case this is not feasible either.
> 
> The other option I see is adding a call from the scope to the dash to
> fetch the icon sizes for a given json.

In general s/m/l corresponds to 12/18.5/38 grid units wide. That means
it's static until grid unit size changes, which should rarely happen -
unless you override it yourself, or connect a display with a different
size. But it also depends on aspect ratio, see spec¹.

Another exception is the carousel, where the currently focused card is
anything between 18 and 26 grid units.

And then there's fill mode - "fit" requires a different size than "crop".

So yeah, in theory we could calculate it (at the moment only variables
are grid unit size and view width), but it doesn't feel future-proof
regardless of which side of the wire we put the calculations on :/.

>> I think the best way would be for the requested size to actually be part
>> of the URL that the UI can then mangle to include the minimum size it
>> wants the image to be - the webservice would then return the next-bigger
>> size.
> 
> What does the webservices team think of this option?
> The problem our team sees with this is that this mangling will depend
> on each type of scope, so the url mangling for the app store will be
> different than the one for the wikipedia scope, etc.

What's worse it might not be possible at all unless it gets proxied by
something, when the "upstream" API only supports a few sizes, and URL to
the image might not even contain it.

¹
https://docs.google.com/a/canonical.com/document/d/1n880Fih5KyGPcoP5chidnHDG_8TxXUgSuij7f4rHpuk/edit#heading=h.h4wb37stljq3
-- 
Michał (Saviq) Sawicz <michal.sawicz@xxxxxxxxxxxxx>
Canonical Services Ltd.

Attachment: signature.asc
Description: OpenPGP digital signature