Hello,
I used file association to change the inode-directory icon and when I navigate to a directory that has 'preview' enabled, the 'folder' icon 'goes away' and an 'icon' of the images or files inside the directory. Why?
Are there directory icons with different names needed?
The icon I used is a png from another 'theme'.
Do I need more than one icon that has a different opacity that shows thumbnails of content?

Anyone?
TY

The previews of files in a folder showing up is fairly routine, and is part of the preview feature. You can disable it at Dolphin > Settings > Configure Dolphin > General > Previews, and deselecting "Directories".

Can you clarify that Dolphin is using the "default" folder icon instead of the one you set for the inode/directory type?

The method of changing folder icons using the inode-directory method was *never* complete as far as I can tell.

The new folder icons did not appear in either preview mode nor when showing tooltips for instance.

There was a further step required to achieve this;
/usr/share/icons/oxygen/*x*/mimetypes:

The following symlinks needed setting with the new folder icon.

application-octet-stream.png -> application-x-python-bytecode.png
application-x-sharedlib.png -> application-x-python-bytecode.png
application-x-object.png -> application-x-python-bytecode.png

The fix was to replace application-x-python-bytecode.png (all sizes) with the new folder icon.
However these symlinks now do not exist.

To solve the issue create new symlinks after changing the application-x-python-bytecode.png image.

@bcooksley,
Should this be filed as a bug in your opinion?

I'm not sure why the "application-x-python-bytecode" icon would be involved at all in previews or tooltips.
Can you post screenshots showing the incomplete transition and the icon which "application-x-python-bytecode" was prior to being modified so I can verify that this could be a bug?

@bcooksley,
application-x-python-bytecode.png
Here's a screenshot of application-x-python-bytecode.png in the default icon-set;



Here's a screenshot of application-octet-stream.png in the same folder;



The following shot shows the result of setting an alternative folder icon via the inode method;



Ok now a screenshot only with the symlinks created above after replacing application-x-python-bytecode.png with the replacement folder icon;



Something has definitely changed as my previous method no longer works.

This is highly unusual - please check the content of the .directory file in the two directories affected by the incorrect icon after changing inode/directory. I suspect you'll find reference to a icon name of some description.

Pictures;

Code: Select all

[Dolphin]
PreviewsShown=true
Timestamp=2013,5,18,0,57,49
Version=3

No .directory file in Templates

I gather we all use the same source of icons regardless of distro, and assume this will only affect folks substituting the single folder icon.
Those replacing the entire set would not be affected, correct?

For the sake of completeness, the only places this above method fails is when first opening Dolphin (the home folder displayed is the default), folders displayed in the side panel, service menus, and Dolphin's navigation bar folders.

Odd - is there any hidden files which appear to be relevant in either folder?
Replacing the entire set should be fine though.

bcooksley wrote:Odd - is there any hidden files which appear to be relevant in either folder?
Replacing the entire set should be fine though.

Nothing I noticed that is different except for what I recall were the symlinks no longer present.
I'm 99% certain also that the inode-directory.png (16x16?)was symlinked also to the 'default' folder in /usr/share/icons but this seems no longer also.

Just to check - prior to adjusting the inode/directory mimetype, did those two affected folders (Pictures and Templates) use the correct icons? Does disabling previews have any impact?

Absolutely. Icons in the default set were trouble-free. Disabling previews worked as expected (hovering over a folder containing images would still show a preview in the information panel) but this is normal behaviour. Tooltip folders displayed correctly when enabled. Everywhere else, no problems.

Just to be clear, I know this is a crude hack to compensate for the inode method not replacing folder icons in all locations, at least I've never known it to. But I don't recall it being so troublesome so I think something is wrong somewhere. The locations not replaced with the new folder icon for instance, what's changed? This hack was 100% effective in 4.8.
Here's an old screenshot. You can see the folder in the location bar is correctly set for instance.
And another

Perhaps it's just a case that replacing folder images in this manner is no longer appropriate. Perhaps the only option now is to 'refurbish' a copy of the icon-set itself and rename it.

ADD:

Below now is a screenshot taking a different approach (replacing ALL the folder, user-home, and inode-directory png's)with the result being some obvious deficiencies.
If my previous approach is regarded as somewhat unconventional then what I'd like to know is what additional folder locations need editing to achieve 100% replacement?

It looks like you might be seeing the effects of thumbnail caching perhaps?
Try clearing out ~/.thumbnails.

I've cleared them several times to be sure. Anyway I think the give away that this isn't the problem is the updated location bar image.

EDIT:
I have discovered the default icon folder is empty. I don't think this is right...
I did start a new thread asking about that.

Thanks bcooksley for the time you've spent