D10990: Add "Open symlink destination folder" into symlink's context menu

[Nathaniel Graham]

ngraham added a comment.


  In D10990#220271 <https://phabricator.kde.org/D10990#220271>, @rkflx wrote:
  
  > Opening this Diff for the first time I was quite skeptical too, but as I actually needed this function recently and it is only added for links, I do think it could be quite useful to have.
  >
  > In D10990#220200 <https://phabricator.kde.org/D10990#220200>, @ngraham wrote:
  >
  > > Also, I notice that the behavior is still different for files and folders: original files are highlighted in their parent directories, while original folders are opened. Little inconsistencies like this tend to drive OCD people mad. :)
  >
  >
  > Are you sure? For me it is working, as Roman is already using `KIO::highlightInFileManager`. Also I like how this keeps both link and target in view, instead of just going to another location or hiding one item in a tab.
  
  
  Ah, you're right. Perhaps I've exposed a bug in `KIO::highlightInFileManager()` or how it's being called, because for most directory symlinks, it works as expected, but not for this one that I have:
  
    $ ls -la ~/nate_shared
    lrwxrwxrwx 1 dev dev 15 Feb  1 21:10 /home/dev/nate_shared -> /media/sf_nate/
  
  Invoking Show Original on `~/nate_shared` opens a new window showing the contents of `/media/sf_nate` instead of opening `/media` and highlighting `sf_nate`.
  
  Bug in `KIO::highlightInFileManager()`, or a bug in the implementation here?

REPOSITORY
  R318 Dolphin

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

To: rominf, #dolphin, ngraham
Cc: rkflx, ngraham, elvisangelaccio, markg, #dolphin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20180306/ca30475f/attachment.htm>