PICARD-1000: Show album/cluster cover art #642

antlarr · 2017-03-05T19:26:19Z

This PR adds support to show album/cluster cover art on the CoverArtBox.
I think it's better shown with an example, so...
When an album is looked up and the cover image has changed (slightly, but it has change) it shows up as http://i.imgur.com/M6dFXna.png
When one track is selected, and a different cover image is dropped for that track: http://i.imgur.com/W6xfS2L.png
Then when the user clicks on the album... http://i.imgur.com/ITX4e3g.png
Another file from another album (which has a different cover art) is added to track 9 of that album: http://i.imgur.com/jAt7ZLJ.png
And then another file is added to another track and other covers are dropped to other tracks on that album: http://i.imgur.com/XSig6BS.png

https://tickets.metabrainz.org/browse/PICARD-1000

samj1912 · 2017-03-06T05:37:19Z

picard/album.py

+        orig_images = []
+        for track in self.tracks:
+            for file in list(track.linked_files):
+                for image in file.metadata.images:


This same for loop has been repeated 4 times, maybe you can make a private function and call it instead?

samj1912 · 2017-03-06T05:49:01Z

picard/ui/coverartbox.py

-        self.setPixmap(cover)
+                pixmap = pixmap.scaled(w, h, QtCore.Qt.KeepAspectRatio, QtCore.Qt.SmoothTransformation)
+                self.setPixmap(pixmap)
+                pixmap = None


Why are we setting pixmap to None here?

IHMO we can move the if clause below to the top and move the above block to an else.

samj1912 · 2017-03-06T05:52:26Z

picard/ui/coverartbox.py

-                    data = image
-                    break
-            else:
+            log.debug("%s using images:" % (self.name), metadata.images)


If we are adding a debug log, maybe an additional parameter display the display string of the related object will be more beneficial than just "new cover art" and "original cover art".

Also the above changes on each selection update, it might clutter the log a bit too much.

On that, maybe we can cache the pixmap. Since it is updated each time the selection is updated, it can lead to too much wasted processing and I/O. Especially since a call to self.data[i].data involves I/O.

zas · 2017-03-06T09:55:52Z

picard/ui/coverartbox.py

@@ -94,6 +95,19 @@ def __eq__(self, other):
    def show(self):
        self.set_data(self.data, True)

+    def decorate_cover(self, pixmap):
+        offx, offy, w, h = (1, 1, 121, 121)


Just an unrelated note: I wonder about the future of this (hardcoded values), especially since we want to add high dpi compatibility in 2.x releases.

zas · 2017-03-06T09:57:23Z

picard/ui/coverartbox.py

-                painter.drawPixmap(x, y, pixmap)
+                pixmap.loadFromData(self.data[0].data)
+            else:
+                stack_width, stack_height = (w + displacements * (len(self.data) - 1), h + displacements * (len(self.data) - 1))


displacements * (len(self.data) - 1) should be stored in a variable instead of repeating it

zas · 2017-03-06T10:10:50Z

picard/ui/coverartbox.py

                data=data
            )
        except CoverArtImageError as e:
            log.warning("Can't load image: %s" % unicode(e))
            return
        if isinstance(self.item, Album):
            album = self.item
-            album.metadata.append_image(coverartimage)
+            album.metadata.set_front_image(coverartimage)


Can you explain this ?

I'm low on coffee, but it seems to set_front_image() is actually removing other images having is_front_image set to True. How does this work when a release has multiple front images (currently only possible with CAA provider).

Sure, when an user drags an image and drops it on the cover art box, I think the natural thing he/she wants to do is to replace the cover art with something different, not add another image to a list of images. Maybe in the context menu (check my cover-art-context-menu branch) I can add a "radio button" where user can select between "Append images on drop" or "Replace images on drop". Would that be better? Still, I think the default should be "replace" since it's more intuitive.

Instead of radio buttons in the context menu, maybe an option in the "user interface" section of the options dialog would be better.

I implemented the radio buttons on the context menu not to clutter the options dialog with a new option, so this will be addressed by this branch:
https://github.com/antlarr/picard/compare/album-cover-art...antlarr:cover-art-context-menu?expand=1
You can see the result here: http://i.imgur.com/lyI9SNs.png
I'll create the pull request for the cover-art-context-menu branch as soon as this one is merged (the work there is already finished) since the commits in that branch depend on this PR.

But, depending on chosen option, the other front images should be kept imho. What about either prepending dropped image, or replacing only the first one ? And keep the rest as is.

mineo · 2017-03-06T18:31:08Z

picard/ui/coverartbox.py

-                    data = image
-                    break
-            else:
+            log.debug("%s using images:" % (self.name), metadata.images)


This line also doesn't work because not all arguments to log.debug are converted during string formatting.

I will just remove that line. As samj1912 said, that would clutter the log too much. I just added while I was working on that and thought it would be ok to keep it, but it doesn't really give any information once this works as expected.

samj1912 · 2017-03-07T16:01:24Z

picard/ui/coverartbox.py

@@ -28,6 +28,36 @@
 from picard.util import encode_filename, imageinfo


+class LRUCache(dict):


Since this can be used by other modules too, mind moving this to a new utils.cache module?

samj1912 · 2017-03-07T16:02:18Z

picard/ui/coverartbox.py

        super(CoverArtThumbnail, self).__init__(active, drops, *args, **kwargs)
        self.data = None
+        self.name = name


Is there any use for the name attribute?

you're right. Not anymore, so I'll remove it

zas · 2017-03-07T17:29:03Z

picard/ui/coverartbox.py

+                pixmap.loadFromData(self.data[0].data)
+                pixmap = self.decorate_cover(pixmap)
+            else:
+                stack_width, stack_height = (w + displacements * (len(self.data) - 1), h + displacements * (len(self.data) - 1))


Please change this to:

offset = displacements * (len(self.data) - 1) stack_width, stack_height = (w + offset, h + offset)

zas · 2017-03-07T17:48:11Z

picard/metadata.py

@@ -55,6 +55,11 @@ def __nonzero__(self):
    def append_image(self, coverartimage):
        self.images.append(coverartimage)

+    def set_front_image(self, coverartimage):
+        # First remove all front images
+        self.images[:] = [ img for img in self.images if not img.is_front_image() ]


Please remove spaces at start and end of list comprehension:

self.images[:] = [img for img in self.images if not img.is_front_image()]

mineo · 2017-03-07T17:38:00Z

picard/util/lrucache.py

+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+
+"""


This comment block should be on the class itself, not somewhere before it.

mineo · 2017-03-07T17:48:26Z

picard/util/lrucache.py

+"""
+
+
+class LRUCache(dict):


PyQt provides a QPixmapCache class, is that something we could use instead of rolling our own? (If we need an lru cache in the future, we can use the one in functools if that future involves python 3).

@antlarr I didn't know about this but it seems like the way to go. It has all the functionality we need.

Update: See https://chatlogs.metabrainz.org/brainzbot/metabrainz/2017-03-07/?msg=3848492&page=5

samj1912 · 2017-03-07T18:53:35Z

picard/ui/infodialog.py

@@ -101,7 +102,7 @@ def __init__(self, obj, parent=None):
        self.ui = Ui_InfoDialog()
        self.display_existing_artwork = False
        if isinstance(obj, File) and isinstance(obj.parent, Track) or \
-                isinstance(obj, Track):
+                isinstance(obj, Track) or isinstance(obj, Album):


Better to use isinstance(obj, (File, Track, Album))

Hmmm, I can merge Track and Album but isinstance(obj, File) has an "and" with isinstance(obj.parent, Track), so I would leave it as:

if isinstance(obj, File) and isinstance(obj.parent, Track) or \ isinstance(obj, (Track, Album)):

Deal?

Remove the "\" for a pair of parentheses and you got it! :P

mineo

The order in which the covers are stacked seems wrong: the frontmost is the cover of the last track that does not have the same cover as the first track. I would have expected the covers to follow the track order, with the frontmost one being the cover of the first track.

One other thing that I really don't like is how this album-level view of the cover art is different from the album-level view of track metadata: the latter one shows (different across x items), even if x-1 items have the same value for a tag, the cover art now looks as if all tracks of an album have the same y pictures. Is this the direction we want to go?

mineo · 2017-03-07T18:12:03Z

picard/album.py

+                for image in file.orig_metadata.images:
+                    if image not in orig_images:
+                        orig_images.append(image)
+            except AttributeError:


Under which circumstances does this raise an AttributeError? Assuming that file is always a File, it will always have orig_metadata and that will always have images.

file is not always a File, but can be a Track too, and tracks don't have orig_metadata. Should I change that to "obj" ?

If it isn't always a File, yes, better change it to obj.

mineo · 2017-03-07T18:13:04Z

picard/album.py

+
+        for track in self.tracks:
+            process_file_images(track)
+            for file in list(track.linked_files):


Is linked_files ever not a list?

mineo · 2017-03-07T18:15:48Z

picard/album.py

+            process_file_images(track)
+            for file in list(track.linked_files):
+                process_file_images(file)
+        for file in list(self.unmatched_files.files):


Is unmatched_files.files ever not a list?

I had a reason for those, but I forgot... so ok, I'll change it (and the other case)

In fact, there are other previous cases in album.py where linked_files is converted to a list, so I'm not so sure that's not needed

mineo · 2017-03-07T18:22:28Z

picard/coverart/image.py

@@ -70,6 +70,9 @@ def __init__(self, data, prefix='picard', suffix=''):
    def __eq__(self, other):
        return self._hash == other._hash

+    def hash(self):


Why isn't this __hash__?

Because IMHO that function doesn't return the hash of that object, but the hash of the CoverArtImage stored in that DataHash object.

mineo · 2017-03-07T18:39:56Z

picard/ui/infodialog.py

@@ -296,6 +297,20 @@ def _display_info_tab(self):
            tabWidget.setTabText(tab_index, _("&Info"))
            self.tab_hide(tab)

+class TrackInfoDialog(InfoDialog):


Maybe something's wrong on my end, but it doesn't seem to be possible to access this dialog from the Info button in the toolbar or the context menu of tracks without files?

hmm, I tested it with zas' example release with 3 images (e5e80fb7-f6b7-3c51-9183-5af44a6c6195) and there it works, but you're right, for single image albums it's not accesible. I'll try to fix that

This should be fixed now

mineo · 2017-03-07T18:48:50Z

picard/ui/mainwindow.py

@@ -944,6 +948,10 @@ def update_selection(self, objects=None):
                        }
                    self.set_statusbar_message(msg, mparms, echo=None,
                                               history=None)
+            elif isinstance(obj, Album):
+                obj.update_metadata_images()


Does this really need to be called every time an album is selected? It really feels like this should be done after the images on the metadata objects are updated.

I didn't find any way to call an album's update_metadata_images when the images are changed in any track/file related to that album. Do you have any suggestion?

We can simply recursively update the parent's orig_metadata/new_metadata on addition of a new image

Hmm, the parent of a file is the track, not the album, right? I think I prefer your previous solution (emitting a signal from track/files and have the album's update_metadata_images called). Would that be ok?

antlarr · 2017-03-08T07:23:28Z

The order in which the covers are stacked seems wrong: the frontmost is the cover of the last track that does not have the same cover as the first track. I would have expected the covers to follow the track order, with the frontmost one being the cover of the first track.

It's strange but for me, the current implementation follows track order. Imagine that you have the track's covers in your hands. First, the first track's cover is laid down, then, the second track's cover is laid down (thus over the first one), and so on. Can someone else vote here which one looks more natural for you?

In any case, if everyone else votes to have the first track at the top, I would arrange the stack from bottom-left to top-right instead of the current top-left to bottom-right, so at least the tracks order is somehow "left to right". Although that's probably cultural and some countries with other writing systems would prefer something else :(.

One other thing that I really don't like is how this album-level view of the cover art is different from the album-level view of track metadata: the latter one shows (different across x items), even if x-1 items have the same value for a tag, the cover art now looks as if all tracks of an album have the same y pictures. Is this the direction we want to go?

I guess you have a point there. Would it be ok if we show the album cover art only when all tracks have the same front images and if any is different we show one of the following options?

The default disc shadow with a red tint
A split screen-like pixmap of the different covers (as opposed to the current stack of covers)
The current stack with some symbol in one of the corners

I think I prefer 1 or 3.

antlarr · 2017-03-08T10:06:57Z

Please review again

zas · 2017-03-08T11:30:55Z

It's strange but for me, the current implementation follows track order. Imagine that you have the track's covers in your hands. First, the first track's cover is laid down, then, the second track's cover is laid down (thus over the first one), and so on. Can someone else vote here which one looks more natural for you?

First track cover image on top, second under it, etc....

I guess you have a point there. Would it be ok if we show the album cover art only when all tracks have the same front images and if any is different we show one of the following options?
The default disc shadow with a red tint
A split screen-like pixmap of the different covers (as opposed to the current stack of covers)
The current stack with some symbol in one of the corners
I think I prefer 1 or 3.

Adding symbols is a bad idea imho (it complicates things, needs explanations, etc...). So i'll not go for 3.

When all tracks share the same image, just display this image for the release.

When one or more tracks have different images, display the one shared among most tracks or the first one on top, plus a special shadow showing there are more images (like a stack of images).

antlarr · 2017-03-08T20:31:16Z

When the tracks/files have no common images, a yellow glow (same color as used in the MetadataBox) is added to the front image: http://i.imgur.com/aXF4lUO.png
When there are four images to show, they are shown normally (in this case, with a glow, because there are different images in different tracks): http://i.imgur.com/RU3M4B0.png
When there are five (or more) images to show, only 3 are shown and a "grey stack" is added to represent "there are more": http://i.imgur.com/5TlkS2o.png
I think that should satisfy everyone

zas · 2017-03-09T10:29:24Z

picard/ui/coverartbox.py

+                pixmap.loadFromData(self.data[0].data)
+                pixmap = self.decorate_cover(pixmap)
+            else:
+                limited = len(self.data) > 4


Please store this 4 in an uppercased variable (constant).

zas · 2017-03-09T10:39:29Z

picard/ui/coverartbox.py

+                    for k in range(border_length):
+                        color.setAlpha(255 - k * 255 / border_length)
+                        painter.setPen(color)
+                        painter.drawLine(x, y - k - 1, x + 121 + k + 1, y - k - 1)


Isn't there Qt methods to draw such shadow ? Also i wonder about high dpi scaling of the whole cover art box, not sure such code will give good visual results.

AFAIK, there isn't any method in Qt for that. I think there may be methods in kde frameworks in some style library like breeze, but that's definitely of no use here. About high dpi scaling, that's "not supported" on Qt4, Qt5 brings support for hidpi devices from Qt 5.6.0, but that's definitely something to worry about with picard 2.0 . In the meantime, since the coverartbox is fixed to use 128x128 covers, that means users with hidpi devices will see small covers and small cover stacks (which Qt5 will scale automatically)

With respect to the drawing, I tried saving an image for the glow under the resources directory and just loading/painting it. Since the resolution is fixed, it's doable, but I found my drawing skills suck, so I ended up making the glow in code, mainly because we can experiment with making it bigger, changing color or whatever. But if you think it's better to stick to that glow, it's also possible to store the glow and the cover stack as images and just use them as is done with CoverArtShadow.png . Only note that I would still use code to generate the images instead of having a svg image as source. Since there are not many cases (afaik) with so many cover art images and anyway the generated images are cached, I'm not sure it's worth to change that.

zas · 2017-03-09T11:00:06Z

picard/ui/coverartbox.py

+            if hasattr(metadata, 'has_common_images'):
+                text += '<br />'
+                if has_common_images:
+                    text += _(u'<i>Common images on all tracks</i>')


I would exclude tags from translatable string here:

if has_common_images: note = _(u'Common images on all tracks') else: note = _(u'Tracks contain different images') text += '<br /><i>%s</i>' % note

zas · 2017-03-09T11:03:20Z

picard/ui/infodialog.py

-        if isinstance(obj, File) and isinstance(obj.parent, Track) or \
-                isinstance(obj, Track):
+        if (isinstance(obj, File) and isinstance(obj.parent, Track) or
+                isinstance(obj, Track)):


While at it, move operators in front:

if (isinstance(obj, File) and isinstance(obj.parent, Track) or isinstance(obj, Track)):

samj1912 · 2017-03-09T11:33:14Z

picard/ui/coverartbox.py

@@ -73,6 +73,7 @@ def dropEvent(self, event):


 class CoverArtThumbnail(ActiveLabel):
+    MAX_COVERS_TO_STACK = 4


Move this to picard.const

Sorry, I didn't know about picard.const. I moved it there.

samj1912 · 2017-03-09T11:34:45Z

Please don't include any merge commits in a PR. Always rebase against the master :)

zas · 2017-03-09T15:58:30Z

since the coverartbox is fixed to use 128x128 covers, that means users with hidpi devices will see small covers and small cover stacks (which Qt5 will scale automatically)

That's exactly my point, current cover art box code (and the one you are adding) are far from being "scalable", with all those fixed numbers, so a complete rewrite will be needed.

To make it clear: 128x128 on a 4k screen is a small icon, not a thumbnail, scaling it up will increase the size but quality will be awful, since we have 500x500 pixels images from CAA we could at least use those without the downscale/upscale process.

I was just wondering if we could avoid to rewrite the code here in one month...

antlarr · 2017-03-09T16:34:53Z

Yes, that has to be rewritten anyway for Qt5 (just like the previous code in there had to be rewritten too) as everything not managed by layouts has to use "device-independent pixels". I'll try to help with that once the port to Qt5 starts.

zas · 2017-03-11T10:48:41Z

@antlarr : please fix conflicts and sort out this PICARD-1000 / description / whatever @mineo reported
@mineo : are changes you requested done ? If yes, please approve

This make CoverArtImage objects hashable

This commit implements a LRU cache for generated pixmaps so they're not generated each time the function is called (saving a lot of I/O and CPU). The cache is shared by cover_art and orig_cover_art objects and currently is configured to contain a maximum of 40 pixmaps.

Instead of raising an exception, now it's possible to see all images of tracks with no linked file.

Retrieve the images from tracks, since an album that doesn't have any linked file, can still have images defined in its tracks.

Moved the LRUCache class to its own module in utils, in case it's useful in other parts of the code.

Remove spaces at start/end of braces

And remove an unused variable in TrackInfoDialog

I changed it in e9fa6c8 so a track is passed to that function some times, so better reflect that in the variable name too.

In order to fix tracks without files not having the info button available, I changed it to allow 0, 1 or multiple files. If the track doesn't have any linked file, only the cover art is shown (if available). If the track has n files, the info tab shows information from the all the files.

I forgot to add the changes from this file to the previous commit (6544900)

Add a signal to Files/Tracks that gets emitted when the images change (or might have changed), and update the album's metadata images on such signals instead of each time the album is selected in the user interface.

Disable/enable the update of images also before/after setting a dropped image

If all tracks/files have a common set of images, show the stack of cover art images as usual. If any track/file has a different set of images, the front image is painted with a darkgoldenrod glow (the same color used for the MetadataBox for tags with different values). Also, fixed the draw of the stack so the bottom cover is drawn correctly.

If there are more than 4 images, draw only three and a kind of "grey stack of covers" that can be easily identified with "and more covers"

Add a constant to hold the maximum number of covers to draw in a stack. Extract html tags out of a translated message. Reformat an if expression to move overators to front. Remove an unneeded comment.

antlarr · 2017-03-11T12:10:50Z

I think the only thing reported by mineo I didn't address is that DataHash.hash should be __hash__, but I was waiting for him to agree or disagree with my opinion that it doesn't feel ok that hash(image) would be equal to hash(image.datahash). But if it's necessary, I can of course change that.

6 days old, no answer, let's move on

samj1912 requested changes Mar 6, 2017

View reviewed changes

zas reviewed Mar 6, 2017

View reviewed changes

zas requested changes Mar 6, 2017

View reviewed changes

mineo reviewed Mar 6, 2017

View reviewed changes

samj1912 requested changes Mar 7, 2017

View reviewed changes

antlarr changed the title ~~Show album/cluster cover art~~ PICARD-1000: Show album/cluster cover art Mar 7, 2017

zas requested changes Mar 7, 2017

View reviewed changes

samj1912 approved these changes Mar 7, 2017

View reviewed changes

zas requested changes Mar 7, 2017

View reviewed changes

mineo reviewed Mar 7, 2017

View reviewed changes

zas approved these changes Mar 7, 2017

View reviewed changes

samj1912 requested changes Mar 7, 2017

View reviewed changes

mineo previously requested changes Mar 7, 2017

View reviewed changes

samj1912 approved these changes Mar 8, 2017

View reviewed changes

zas requested changes Mar 9, 2017

View reviewed changes

samj1912 requested changes Mar 9, 2017

View reviewed changes

antlarr force-pushed the album-cover-art branch from 27ec41e to 83feed7 Compare March 9, 2017 11:53

samj1912 approved these changes Mar 9, 2017

View reviewed changes

zas approved these changes Mar 9, 2017

View reviewed changes

antlarr force-pushed the album-cover-art branch 3 times, most recently from 7f5dcd5 to fb3be80 Compare March 10, 2017 18:48

antlarr added 25 commits March 11, 2017 13:04

Update file status after dropping images

c67decd

Move duplicate code to a common private function

42dad80

Implement CoverArtImage.__hash__

fdb3ae4

This make CoverArtImage objects hashable

Remove unuseful/broken debug message

b3726f2

Allow to open an info dialog of a track with no linked file

a6614ee

Instead of raising an exception, now it's possible to see all images of tracks with no linked file.

Fix album cover art for album with no files

53afbb5

Retrieve the images from tracks, since an album that doesn't have any linked file, can still have images defined in its tracks.

Remove CoverArtThumbnail.name variable which is not used anymore

9ff5434

Move LRUCache to picard/utils/lrucache.py

7370819

Moved the LRUCache class to its own module in utils, in case it's useful in other parts of the code.

Cleanup the calculations

77fbaae

PEP8 fixes

269b7f0

Remove spaces at start/end of braces

Enable cover artwork diff for albums

1982d03

And remove an unused variable in TrackInfoDialog

Slightly improve the readability of the code

5e14e08

Move documentation inside class definition

f9befdd

Rename file variable to obj

0710a0d

I changed it in e9fa6c8 so a track is passed to that function some times, so better reflect that in the variable name too.

Start the correct InfoDialog

0dd1e8d

I forgot to add the changes from this file to the previous commit (6544900)

Update album metadata images when Files/Tracks emit signal

e2e2ca3

Add a signal to Files/Tracks that gets emitted when the images change (or might have changed), and update the album's metadata images on such signals instead of each time the album is selected in the user interface.

Reduce the number of metadata image updates when dropping an image

270b07d

Disable/enable the update of images also before/after setting a dropped image

Show cover stack from front-to-bottom and from bottom-left to top-right

3599f74

Add information about common/different images on tooltip

8057f2b

Limit the number of images to draw in a stack to 4

f5c82ad

If there are more than 4 images, draw only three and a kind of "grey stack of covers" that can be easily identified with "and more covers"

Small fixes

6549926

Add a constant to hold the maximum number of covers to draw in a stack. Extract html tags out of a translated message. Reformat an if expression to move overators to front. Remove an unneeded comment.

Move MAX_COVERS_TO_STACK to picard.const

0992a6c

antlarr force-pushed the album-cover-art branch from fb3be80 to 0992a6c Compare March 11, 2017 12:06

Fix unneeded broken import from a bad rebase merge

879a86e

zas merged commit cb1ff1d into metabrainz:master Mar 13, 2017

		@@ -28,6 +28,36 @@
		from picard.util import encode_filename, imageinfo


		class LRUCache(dict):

		@@ -73,6 +73,7 @@ def dropEvent(self, event):


		class CoverArtThumbnail(ActiveLabel):
		MAX_COVERS_TO_STACK = 4

PICARD-1000: Show album/cluster cover art #642

PICARD-1000: Show album/cluster cover art #642

Conversation

antlarr commented Mar 5, 2017 • edited by zas

Choose a reason for hiding this comment

Choose a reason for hiding this comment

samj1912 Mar 6, 2017 • edited

Choose a reason for hiding this comment

samj1912 Mar 6, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

samj1912 Mar 7, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

samj1912 Mar 7, 2017 • edited

Choose a reason for hiding this comment

mineo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

samj1912 Mar 7, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

antlarr commented Mar 8, 2017 • edited

antlarr commented Mar 8, 2017

zas commented Mar 8, 2017

antlarr commented Mar 8, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

samj1912 commented Mar 9, 2017

zas commented Mar 9, 2017

antlarr commented Mar 9, 2017

zas commented Mar 11, 2017

antlarr commented Mar 11, 2017 • edited

antlarr commented Mar 5, 2017 •

edited by zas

samj1912 Mar 6, 2017 •

edited

samj1912 Mar 6, 2017 •

edited

samj1912 Mar 7, 2017 •

edited

samj1912 Mar 7, 2017 •

edited

samj1912 Mar 7, 2017 •

edited

antlarr commented Mar 8, 2017 •

edited

antlarr commented Mar 11, 2017 •

edited