Show Information Panel button by default instead of the Preview button
Needs ReviewPublic

Authored by ngraham on Apr 3 2018, 2:26 AM.

Details

Reviewers
None
Group Reviewers
Dolphin
Summary

Display the button to show and toggle the Information Panel instead of inline previews by default.

The Information Panel is an incredibly awesome and powerful feature, and this patch makes it more discoverable. Also, now that previews are on by defaul, having an always-visible button to turn them off isn't that useful; my sense is that the button was there in the first place to help users figure out how to turn previews on. Now that they're on, we can use that space for something more useful.

Test Plan
  • Deploy change
  • Create and log into a new user account
  • launch Dolphin and look at its toolbar:

Diff Detail

Repository
R318 Dolphin
Branch
show-information-panel-button-by-default (branched from master)
Lint
No Linters Available
Unit
No Unit Test Coverage
ngraham requested review of this revision.Apr 3 2018, 2:26 AM
ngraham created this revision.
ngraham edited the summary of this revision. (Show Details)Apr 3 2018, 2:27 AM
ngraham edited the test plan for this revision. (Show Details)
rkflx added a subscriber: rkflx.Apr 3 2018, 8:53 AM

Also, now that previews have been on by default since 17.12 (and I haven't heard any negative press or internet complaints at all about it)

Maybe that's because in fact previews are off by default? I guess the test plan in D7440: Turn on Dolphin icon previews by default is missing to account for .directory entries.

(Personally I think it is much too risky to enable previews by default for security reasons until the thumbnailers are sandboxed properly.)

button to turn them off isn't that useful

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), or they simply want different settings for different folders (e.g. previews only enabled in their pictures folder).


I don't have time to implement something currently, but at least I can express my preferences:

  • Previews off by default (as it is right now)
  • Ship a .directory for Pictures to turn previews on only there.
  • Keep the Preview button in the toolbar.
  • Find a better way to toggle panels in general (Gwenview's sidebar button in the statusbar comes to mind, but we'd need to make some space in Dolphin first, or find a different place…)

Also, now that previews have been on by default since 17.12 (and I haven't heard any negative press or internet complaints at all about it)

Maybe that's because in fact previews are off by default? I guess the test plan in D7440: Turn on Dolphin icon previews by default is missing to account for .directory entries.

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.

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.

or they simply want different settings for different folders (e.g. previews only enabled in their pictures folder).

I think that's a niche use case for expert users. I think most average users appreciate previews everywhere, not just their Pictures folder (many and maybe even most don't actually even put their pictures in there). macOS Finder and Windows Explorer both default to showing previews everywhere.

  • Find a better way to toggle panels in general (Gwenview's sidebar button in the statusbar comes to mind, but we'd need to make some space in Dolphin first, or find a different place…)

Agreed, and this is what my patch was attempting to accomplish. But it's still not ideal because it doesn't expose the Terminal or Folders Panels.

rkflx added a comment.Apr 3 2018, 4:22 PM

Also, now that previews have been on by default since 17.12 (and I haven't heard any negative press or internet complaints at all about it)

Maybe that's because in fact previews are off by default? I guess the test plan in D7440: Turn on Dolphin icon previews by default is missing to account for .directory entries.

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.

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.

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.

or they simply want different settings for different folders (e.g. previews only enabled in their pictures folder).

I think that's a niche use case for expert users. I think most average users appreciate previews everywhere, not just their Pictures folder (many and maybe even most don't actually even put their pictures in there). macOS Finder and Windows Explorer both default to showing previews everywhere.

At least for Windows, that's not true: By default, the "Details" view (which does not have previews) is used, and when switching to "Icons", only images will get previews, but not your typical Office documents.

I think we can trust users to turn on previews by themselves via the easily reachable button in case they don't use the default Pictures folder.

  • Find a better way to toggle panels in general (Gwenview's sidebar button in the statusbar comes to mind, but we'd need to make some space in Dolphin first, or find a different place…)

Agreed, and this is what my patch was attempting to accomplish. But it's still not ideal because it doesn't expose the Terminal or Folders Panels.

Yeah, I'm not against providing easy access to the information panel. I just don't want to lose the Preview button.

ngraham edited the summary of this revision. (Show Details)Apr 3 2018, 5:18 PM
ngraham added a comment.EditedApr 3 2018, 5:24 PM

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.

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. And the icons for different image formats are different: for example JPEGs get a green icon, and PNGs get a purple one, despite the fact that they may and likely will open with the same app.

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 for icons that don't have previews. 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, leapfrogging macOS in the learnability department.

rkflx added a comment.Apr 3 2018, 5:58 PM

My mistake, the change made it into 18.04, not 17.12.

Then you should ask everyone in D7440 if they are still okay with enabling previews by default if you remove the button at the same time.

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

Try adding some title pages of papers in Inkscape, then align them in a grid: You cannot see a thing, even with your proposal (which is very challenging to implement). IMO the concept of previews for files primarily containing text is broken. We can use this space for much more useful things (brainstorming a more useful meta-preview):

  • mimetype
  • primary background colour
  • aspect ratio of the first page
  • number of pages

…which leads to some kind of grid view for documents with multiple pages, without the purpose of trying to squeeze in illegible text.

For a useful preview I'd rather focus efforts on KLook…

previews aren't on for text files by default. Those were some of the compromises made to get the feature in.

I'd not call those compromises, but sensible decisions. Not showing a preview for text files is quite similar to not showing a preview for ODTs containing mostly text (which they do for most users I've met).

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.

That's not what I meant. I was referring to the fact that you can infer the mimetype from the icon (and thus the application, after using the system for a while), which does not work for thumbnails, because those can look similar for different mimetypes.

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 for icons that don't have previews. 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, leapfrogging macOS in the learnability department.

We already have those badges (mimetype icons only, for now) if you look closely. In KDE3 they had a size you could see them, now they are so tiny they are practically useless.