Review Request 118961: Treat video thumbnails the same as image thumbnails

[Emmanuel Pescosta]

> On June 26, 2014, 9:15 p.m., Emmanuel Pescosta wrote:
> > Thanks for the patch!
> > 
> > Applying a shadow frame to video thumbnails really makes sense, but I think we should go even further and apply it to other thumbnails as well.
> 
> Diego Soenens wrote:
>     Which ones are you thinking of? There are some that shouldn't have it I think like .exe and .ico files because more often than not they have transparency.
>     Also, what would be the best way to discriminate between them (checking dozens of mime types would get ugly really fast)?
>     
>     Sorry I'm new to all this :).
> 
> Emmanuel Pescosta wrote:
>     > they have transparency.
>     Transparency is no problem, we only use the bounding rect for the shadow effect.
>     
>     I think of PDFs, (odf, txt, ...) documets and so on - almost all thumbnails.
>     IMHO mixing flat thumbails with shadow applied thumbnails looks bad (hee before.png).
>     
>     So why not applying it to all thumbnails? 
>     
>     > checking dozens of mime types would get ugly really fast
>     Yep whitelisting a lot of types is a no-go, but if we apply the shadow to all
>     thumbnails we only need to check if the current item is a directory.
>     
>     > Sorry I'm new to all this
>     Np, feel free to ask questions and just write down your thoughts ;)
>     
>     We should better wait for Frank.
> 
> Diego Soenens wrote:
>     > So why not applying it to all thumbnails?
>     
>     Most ThumbCreator's return the ThumbCreator::DrawFrame flag in their flags() function to draw a 1px frame around the image to give them a depth/3d-ish effect for example.
>     This causes the preview to appear blurry around the edge when combined with the shadow frame (see http://i.imgur.com/TfRqFmN.png).
>     I guess those preview plugins could be updated afterwards to change the flag they return to ThumbCreator::None?

> Most ThumbCreator's return the ThumbCreator::DrawFrame flag in their flags() function to draw a 1px frame around the image to give them a depth/3d-ish effect for example.
In my opinion this should be changed. A thumbnail shoud only be an image of the actual data without a frame because drawing shadows and so on should definitely be 
part of the application. This "always" draw an frame around some thumbnails is also bad in the information panel.

But please wait for Franks opinion ;)


- Emmanuel


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118961/#review61039
-----------------------------------------------------------


On June 26, 2014, 8:59 p.m., Diego Soenens wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118961/
> -----------------------------------------------------------
> 
> (Updated June 26, 2014, 8:59 p.m.)
> 
> 
> Review request for Dolphin.
> 
> 
> Repository: kde-baseapps
> 
> 
> Description
> -------
> 
> A minor (but very noticeable) inconsistency that has been bugging me in Dolphin is the fact that video thumbnails don't get the nice shadow frame added that image thumbnails have.
> Video snapshots are essentially images, and often times these two file types will be in the same folder. So to me it doesn't make sense to treat them differently.
> 
> 
> Diffs
> -----
> 
>   dolphin/src/kitemviews/kfileitemmodelrolesupdater.cpp 0865d40 
> 
> Diff: https://git.reviewboard.kde.org/r/118961/diff/
> 
> 
> Testing
> -------
> 
> Works fine (see before/after screenshots).
> 
> 
> File Attachments
> ----------------
> 
> Before
>   https://git.reviewboard.kde.org/media/uploaded/files/2014/06/26/11ed57e4-04af-4ff0-9963-7a183dfcb035__before.png
> After
>   https://git.reviewboard.kde.org/media/uploaded/files/2014/06/26/ae8c87c1-fb61-48ee-ba3c-11070752edb3__after.png
> 
> 
> Thanks,
> 
> Diego Soenens
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20140626/14d49a3b/attachment.htm>