Since KDE 4.7.4, directory icons have been ignored (not shown) in any directories located under an NFS or CIFS mount point because they're considered "slow", according to someone's definition. Think the goal was to try speeding up file listings on network mounts with a large number of directories, but it did it by completely removing the ability to use custom directory icons if (and only if) the directories are located on a network share. This results in an inconsistent and annoying experience for, when dealing with gigabit network speeds as I am, a largely pointless change to fix a problem I never had to begin with.
Full discussion about this problem is located here:
After a large and so far fruitless discussion on how to "properly" fix the problem, one user posted a very simple patch that just removes the concept of "slow" filesystems for NFS and CIFS mounts, allowing proper directory browsing and icon support as available in KDE <=4.7.3. I tested it on my system tonight, and it seems to work great; I haven't noticed any ill side effects, and I can finally, after nearly a year, view all of my directory icons again. It's a good patch. :-)
So, I'm posting here to request evaluation and consideration for inclusion in Gentoo. I've attached the patch, which applies cleanly by adding it to the end of the PATCHES=() array in kdelibs-4.9.1.ebuild.
Created attachment 324342 [details]
This is a minor upstream bug and the activity in the bug is high, so i would suggest to wait for inclusion by upstream.
Fair enough. If you'd prefer to take a "wait and see" approach, though, I do have a different suggestion: could you please add support for epatch_user() to the kdelibs ebuild so that, while waiting for upstream to decide on some course of action, Gentoo users can easily apply this patch themselves?
I'd much prefer to throw a patch in /etc/portage/patches and let it be auto-applied (even it it requires occasional tweaking) than maintaining a completely separate kdelibs ebuild in my local portage tree and bumping it with each new release.
According to a comment on the upstream bug, this should be fixed in 4.10.2. Can you confirm?
I likely won't have a chance to test this anytime soon, but according to some commenters on the upstream bug today it looks like this has indeed been fixed. I'm satisfied with their confirmation, so I'll go ahead and mark this as resolved.
Thanks for the follow-up.