- Adds attribution variable to Image model
- In mmv.ui.metadataPanel and mmv.EmbedFileFormatter, display
attribution line instead of author and credit when it is set
- Update junit tests for mmv.model.Image and mmv.EmbedFileFormatter
Bug: T67445
Change-Id: Idfe542a1542d28cf8d27c1720ab0bd54324b2f37
* use the same text for plain and HTML format
* use the same text whether or not a deed URL is set
Bug: T76030
Change-Id: Iea53766b2e2031206d707838551bd82dba29e8c4
Adds site link, license link and long name, replaces internal license name
(we don't have it for most licenses) with short name.
Also fixes some problems in previous changesets that I stumbled on,
renames things to be more consistent/less misleading, and makes
EmbedFileInfo a thin container for existing classes. (That results
in a lot of Demeter's law violations, but it means one less model
to remember, which is a good thing since our property names are
often not very informative (e.g. EmbedFileInfo.url and
Image.url which had completely different meanings))
We always have the site information for embed texts (comes from the repo
API); that part of the tests was pointless, but now that EmbedFileInfo
depends on Repo they became impossible to maintain, hence the
deletion of half the test cases in getThumbnailHtml().
Change-Id: I94e1d0aca14e2a7d5fad983412090add8ad6bfa3
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/369
This takes care of several minor annoyances:
* centralizes all the text processing functions which have been
floating all around the code, and adds proper tests
* filters out invisible elements (sometimes used for metadata)
* avoids merging separate words on HTML->text transformation
* adds caching since doing all this transformations could be
processing-intensive for big chunks of HTML. (This might or
might not be a good idea. I haven't done performance tests, so
this might be premature optimization, and increases memory use.
OTOH these functions are often called in situations where an
immediate UI response is expected (such as selecting a size
from the list) so even small delays would be perceivable.
Bug: 63126
Change-Id: I1ef1e3a33efdfea17612df00da6b629bf39e07aa
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/388
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/369
Last round of fixes and refactorings regarding resize issues
and the Canvas component:
* Consolidate all the width calculation logic inside the Canvas component
* Consolidate image resizing logic in the Canvas component
* Fix size problem with SVG images
* Clean up comments and tests
Change-Id: I0198cc1e3a45f7287b9a7494f73a8f158303f886
Bug: 56454
Mingle: 239
When the lightbox is opened, or prev/next pressed, preloads the
previous/next N images.
Technical debt introduced:
* initialization is a mess, with the viewer and the interface
randomly setting properties on each other in different phases of
execution. That got in the way and I shuffled things around
until they worked, which is obviously not the way to have a
robust system, but hopefully it will get scrapped soon anyway
in favor of a clean top-down dependency injection.
Change-Id: Idcb5c40de1ac0b3e482decd66e56c4de8ec71b6b
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/155
A simple task queue which can be processed or cancelled.
Will be used to handle preloading in a more robust way.
Change-Id: Ib33f9b2d814a35538f9d4f3691fce5ba5cdc82c1
* moves generic logic into ThumbnailSizeCalculator class
* moves UI-specific logic into interface class
* fixes bug where non-bucketed sizes were served on devices with
non-standard pixel density
* fixes bug where bucketed size was compared to css size instead of screen size
for resizing
Change-Id: I8ba3380b74fcc8fb0a6ecc3f3140627411851ad0
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/196
Interface code is its own class which does not depend on the main
interface class it can be unit tested (and eventually moved into its
own file to make browsing the code easier). IMO we should aim to
eventually break up the interface into similar classes (with a simple
init/empty/set interface + custom events where it makes sense).
Also, sneak-introducing LESS!
API usage could be more effective (globalusage is a separate API call;
it needn't be), but we will have to rewrite that part soon anyway, so
it should pass for now.
Bug: 60087
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/44
Change-Id: Ibe5c323cdeab4a378316925f0c3efb3dc7ef5997
