Until now, folders without previews have a smaller icon size than folders which do have a preview.
This patch adapts the size of those folders. In addition, the icons now scale if you increase the size of the panel.
FEATURE: 313050
Currently, this patch does not work for all "Places" icons. I was not able to find any traces about where the size of those icons is defined.
Maybe someone could help out?
Before:
Afterwards:
| Lint Skipped |
| Unit Tests Skipped |
I must say I don't really like the larger icon. How does that change the appearance of all the other file icons in the panel?
| src/panels/information/informationpanelcontent.cpp | ||
|---|---|---|
| 321 | Where does that magic number 12 come from? | |
+1 for the change itself; this is something that I've seen complained about a few times before.
Doesn't work work for folders that have custom icons (e.g. Pictures, Documents, etc), but technically that is a pre-existing bug.
It does not change the appearance of the other file icons as those are handled in showPreview().
How can I improve the appearance of the larger icon? The transition is defined pixmapviewer.cpp -> paintEvent() and currently designed to smoothly resize the icon (which would obviously no longer happen with this change).
| src/panels/information/informationpanelcontent.cpp | ||
|---|---|---|
| 321 | This is the "bad" part of this patch... I took the number from adjustWidgetSizes(), where the width is defined as const int maxWidth = width - style()->layoutSpacing(QSizePolicy::DefaultType, QSizePolicy::DefaultType, Qt::Horizontal) * 4;. I found out that this corresponds to 12, because simply subtracting the layoutSpacing() from parentWidget()->width() did not work. I need to change this (I know that simply hard-coding values is bad practice) but I couldn't figure out how. | |
Remove hardcoded value
I simply use m_preview->width now instead of hardcoding the width.
Code looks sensible, and I think the visual change makes sense; the abrupt jump was always weird. If the new size is too big, we can always play with it in a follow-up patch after gauging people's impressions, if any.
Let's let other Dolphin folks weigh in too.
Found where the Places icon sizes are defined: in InformationPanelContent::applyPlace(). Currently, the size is hardcoded to 128x128, ew. Let's fix that too as a part of this patch, so that we eliminate all the size changes in one fell swoop.
There are also a few other occurrences in this file of where KIconLoader::SizeEnormous is still used for the pixmap size in the information panel, e.g. to show the "nepomuk" icon (which should really be either "baloo" or even "system-search" instead (but that's something for another patch, hint hint :) ).
Let's fix those too, and make everything totally consistent. While we're at it, to make this easy to change in the future, it might be worth making the maximum size a variable or a constant, so it's easy to adjust in the future if we decide to make changes again.
The animation between normal folder icons and bigger preview icons is actually a feature, see pixmapviewer.cpp
If we make all icons of the same size (which I'm not sure I'd like), that code would become useless and should then be removed.
Hmm, didn't know that. What's the purpose of the feature? Whatever it is, it needs to be balanced against the somewhat odd visual inconsistency, IMHO.
Well, then we can simply keep the whole animation (as the animation only triggers if the size of the pixmap changes), adjusting it to only work if the panel is resized would probably require more code than the current solution.
I am apparently not able to control arcanist... reverting changes which should have been in a different patch.
This seems great to me. We still have the nice animation when the Information Panel is resized, and all folder icons are now the same size no matter if they have a preview or not.
One more to-do: fix the use of KIconLoader::SizeEnormous instead of the max preview width for the "nepomuk" icon (unless you want to do that in a follow-up patch).
The thing is, for one user that complains on bugzilla there are probably 10x people who are happy about the current implementation. Some of them *will* complain after this patch goes in.
The rule of thumb to understand whether users are actually unhappy is to check how many votes a bugzilla ticket has.
- The animation would not be totally useless, because if you resize the information panel, the pixmap will not have a smooth transition
Ah right, that's true.
Still, as I mentioned in bugzilla, the only inconsistency that I'd fix is that the information panel does not check whether the preview setting is enabled.
And what do you think about the size when the information panel is resized? Right now, folders without previews look pretty bad if you expand the panel:
Should we keep that as well?
What do we suspect that they will complain about? The icons/previews being too big if they fully fill the preview space?
To me, and to the version of me where I impersonate a Regular User™, the current implementation feels buggy:
There is unused space, yes, but I wouldn't say it looks bad. Imho it's better than what we would get with this patch:
Normal folder icons being too big for no reason (see also the very first comment by Kai).
To me, and to the version of me where I impersonate a Regular User™, the current implementation feels buggy:
- Some folders and icons have a maximum size in the preview pane, but others don't (putting on my "normal user" hat, I would have no idea why this was, and it would seem like a bug)
If the icon is showing a preview we make it bigger (and resizable), feels pretty consistent to me (besides the fact that the whole thing should be disabled if previews are disabled).
- Some folders that show a preview of their contents in the main view, but not in the information panel (not related to this patch, but still feels like a bug to Mr. or Mrs. Normal User)
Not sure what you meant here?
There is unused space, yes, but I wouldn't say it looks bad. Imho it's better than what we would get with this patch:
Well, I wouldn't exactly call the status quo ideal either:
Does it even make sense to have the information panel this wide in the first place? Neither the status quo nor the proposed patch really make sense when it's super wide. Maybe we shouldn't optimize for this extreme corner case.
This bug:
Because it has a custom icon by default, the Music folder shows a preview of its contents in the view, but not in the information panel.
A wide information panel makes sense if you are previewing e.g. a lot of pictures
Because it has a custom icon by default, the Music folder shows a preview of its contents in the view, but not in the information panel.
Hmm, weird. I cannot reproduce it (my Music folder with custom icon does show previews). Does this patch fixes it for you, and if yes, why/how?
When you really want to go through images quickly, you're never going to be able to make it wide enough to get the kind of visual fidelity you really need, and if you try, you'll make it take over the window and there won't be any room left for the actual main view. IMHO the Information panel makes more sense as a somewhat small yet always visible provider of small previews and contextual information, not as a poor man's multi-file comparison tool.
Coming from the Mac world, an instant previewer like Quick Look (or KLook!) provides a much more efficient workflow for quickly previewing pictures than making the information Panel really wide does in Dolphin.
No, this patch does not fix it. I discovered how to reproduce it: add the folder in the Places panel. Thereafter, the Information panel stops displaying that folder with previews. If you remove its Places item, the bug disappears and the Information Panel will once again show the folder in previewed form. I'll move this discussion into Bugzilla so we can avoid cluttering up this already-long discussion with something unrelated (my bad, sorry): https://bugs.kde.org/show_bug.cgi?id=392621
I agree that the large icon might look too big for wide panels, but I guess the only really good way to optimize for such a corner case would be to increase the font size as well (which is another task, and might look bad).
This patch turned out to be a lot more complex than I first thought... How do other file managers cope with this?
macOS Finder's Information Panel equivalent
Like Dolphin:
Unlike Dolphin:
As a result, Finder doesn't have this issue. Thoughts for paths forward here:
Personally, I like the overlays of content on the folders. I think it's a very stylish and unique feature. +1 for keeping this, in general.
I'd suggest a maximum size on the icon - not unlimited. We've got to be somewhat reasonable, right? I don't care much for the previews above that show the icon fully maximized in the preview box. It definitely needs a margin. Negative space is easier on the eyes. Maybe something like 85% or 90% of the space. And whatever happens, the aspect ratio has to be 1:1. One of the screenshots looks stretched in the X direction.
I tried installing a couple of file managers from other distros (GNOME, Mint), but they didn't play well in the KDE environment. Nemo (Mint) actually crashed. But I didn't see a preview pane in either - although they're both extendable through scripts and plugins, so anything is possible.
We don't want to poach directly from macOS, but Apple sets a high standard for usability and design.
My vote is for a Finder-esque display, with a maximum icon size and the preview overlays. As for the zoom animation, it should zoom on empty folders (or folders without preview contents) as well.
Yeah, pretty much ;) Nah, real life has been busy and I think that it'll take at least another two weeks until I can pick this up again. Frankly, I don't even really know what to implement now... Assuming that we do not want to WONTFIX the bug, we need to shrink the preview size down. @sharvey suggested that we set this to about 85% of the panel size, but this would not resolve the enormous icons if the panel is very wide. Should we introduce a cap (such as two times Size::Enormous)?
Any reason we wouldn't consider capping the maximum size of the preview pane as well? For reference, I believe 2 * Size::Enormous is the size used in the left-hand widget explorer. Those are pretty enormous.
Imho the only thing we need to do here is to not show previews in the information panel if the Preview button is not checked.
Why? I would imagine the information panel serving as an on-demand preview in case you don't want them cluttering the main view.
I'm with Kai here. The Information panel should always show previews no matter what; that's a huge part of its value. People who don't want previews should just turn off the whole icon (it isn't very useful without previews anyway IMO).