You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I guess that'd be ok... or alternatively, perhaps the ThumbnailFile should be built with knowledge of the options it was generated with, allowing for a filter with no required options.
I just want to comment on my design decision to make it a filter. First of all I think im.margin is ugly, is that really an explicit attribute for an image abstraction? Having the image abstraction to know of its requested size as well as the actual size also leads to some ugly coupling. As a filter you get one downside if you must and that is to have to set the size for the bounding box. The pros are:
Its doesn't clutter the image abstraction.
The filter is not tied to a thumbnail, it could be any image.
Yep, i'm not sold on im.margin, but I think giving the ThumbnailFile information so that you could optionally use the filter without an argument would be a fair enough use-case.
the new sorl thumbnail has a margin filter, which is all very nice but requires me to duplicate the size specification.
Would be nice if the ThumbnailFile also knew the requested size so it knew what the margin had to be to make the image centered on the requested size.
Something like:
The text was updated successfully, but these errors were encountered: