D11896: Show Information Panel button by default instead of the Preview button

[Nathaniel Graham]

ngraham added a comment.


  In D11896#239157 <https://phabricator.kde.org/D11896#239157>, @rkflx wrote:
  
  > In D11896#239096 <https://phabricator.kde.org/D11896#239096>, @ngraham wrote:
  >
  > > No, they are in fact on by default. Check with a new user account and add a picture to ~/Pictures, then go back to ~. The ~/Pictures folder gains a preview of its contents, i.e. the picture you just added to it.
  >
  >
  > Well, I tested exactly that before commenting, on multiple distros even. Anyway, don't change it, because I like how it is currently :D It's just that I think we should not lose the Preview button to //actually// turn on previews.
  
  
  My mistake, the change made it into 18.04, not 17.12.
  
  >> In D11896#238990 <https://phabricator.kde.org/D11896#238990>, @rkflx wrote:
  >> 
  >>> There is a huge difference between making something a default and removing the ability to change back a setting from the main UI. There are lots of situations where users might not want to have previews enabled, e.g. their document previews all look the same (common for the first page of most scientific documents)
  >> 
  >> 
  >> Sounds like a bug in the thumbnailer that we should fix. If where are cases where previews aren't useful, we should fix that.
  > 
  > No, that's not a bug, but a fundamental problem: Most documents I'm talking about have a white background, the same aspect ratio, a centred title and some form of abstract always at the same position. Of course the thumbnails will look //slightly// different, but for all intents and purposes there is no value in the thumbnail. I'd rather have the colourful mimetype icon to immediately see which documents are PDFs, ODTs, ePubs etc.
  
  I think if a preview isn't useful, the logic should be improved to make it more useful as much as possible. e.g. for the academic papers you're describing, we could have the thumbnailer produce a preview that's a zoomed-in section of the relevant part of the first page that has content (which would be the title and abstract).
  
  But I think you're focusing on one challenging use case to the exclusion of all others. Most files aren't academic papers with blank title pages. That's a really niche use case to optimize for. I looked through my own collection of a hundred or so academic papers in the fields of geology and chemistry, and none had blank title pages. I have zillions of PDFs on other subjects in various places in my home folder that do benefit from previews. And images always benefit from previews by default no matter where they're located.
  
  Also, we don't even have thumbnailers for epub and OpenDocument files, so there's currently no concern with having previews enabled on their account (also, many ePubs have pretty title pages anyway...), and previews aren't on for text files by default. Those were some of the compromises made to get the feature in.
  
  > It is also reassuring for regular users, because the mimetype indicates which app will be opened upon clicking on an item (i.e. the "learnability" aspect of the academic definition of usability). If previews were on by default, it's either a surprise or you'd have to squint at the file extension.
  
  With previews off, a file's icon remains the same no matter what app will open it, has has nothing visually in common with the app that will open it. The Breeze PDF icon displays an Adobe Acrobat logo, in fact. So you will generally have no idea what app your document will open with by default just by looking at its icon. macOS actually has the feature you want, and changes the icon to reflect what will open it. I think that we //should// have this feature! But it shouldn't be limited to when previews are off: we could also badge the preview with an icon of that app that will open it, perhaps.

REPOSITORY
  R318 Dolphin

REVISION DETAIL
  https://phabricator.kde.org/D11896

To: ngraham, #dolphin
Cc: rkflx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20180403/0afe9fc3/attachment.htm>