On 24.04.2014 18:42, Alejandro J. Cura wrote: > On Tue, Apr 22, 2014 at 11:47 AM, Michał Sawicz > <michal.saw...@canonical.com> 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.saw...@canonical.com> Canonical Services Ltd.
signature.asc
Description: OpenPGP digital signature
-- Mailing list: https://launchpad.net/~ubuntu-appstore-developers Post to : ubuntu-appstore-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-appstore-developers More help : https://help.launchpad.net/ListHelp
