Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

resolve aliases when browsing in the 3rd pane (by type). Fixes #1484 #1485

Merged
merged 2 commits into from Jun 10, 2013

Conversation

pjrobertson
Copy link
Member

@pjrobertson pjrobertson commented Apr 29, 2013

Does what it says on the tin.
I created a new method for file objects to easily get the resolved object of an alias object. It can be used 'blindly' to resolve objects (i.e. if the object isn't an alias then calling [anObj resolvedAliasObject] just returns anObj

I contemplated changing isDirectory and isFolder to look at the resolved object (since they fail for file objects that are aliases to folders), but thought that it would be better to let the developer make the decision as to whether they want to distinguish folders and aliases (if not then just call resolvedAliasObject on the object)

@skurfer
Copy link
Member

@skurfer skurfer commented Apr 29, 2013

I'm not seeing any difference in behavior here. Does it literally have to be an HFS+ alias? Because I'm testing with a symbolic link.

I contemplated changing isDirectory and isFolder to look at the resolved object…

I think you made the right choice here for the right reason.

@pjrobertson
Copy link
Member Author

@pjrobertson pjrobertson commented Apr 30, 2013

I'm using a soft link (created with ln -s) and I can confirm it fixes the
problem.

Just to clarify: this doesn't fix the problem for the initial objects in
the 3rd pane, only when you right arrow into a folder...

edit
OK, it does fix that now. See the latest commit. Also, I've changed a few
other places in the code to consider the resolved object as opposed to the
original as well.

On 30 April 2013 02:30, Rob McBroom notifications@github.com wrote:

I'm not seeing any difference in behavior here. Does it literally have to
be an HFS+ alias? Because I'm testing with a symbolic link.

I contemplated changing isDirectory and isFolder to look at the resolved
object

I think you made the right choice here for the right reason.


Reply to this email directly or view it on GitHubhttps://github.com//pull/1485#issuecomment-17188638
.

@skurfer
Copy link
Member

@skurfer skurfer commented Apr 30, 2013

I had created a folder and a symlink to it in my home directory, so I was going to ~ then hitting /. I'll get the new commits and test some more.

@pjrobertson
Copy link
Member Author

@pjrobertson pjrobertson commented Jun 10, 2013

@skurfer any updates on this pull? It should be good to go It got so old, that I actually completely forgot about it, and saw #1484 still open, so started re-fixing it... until I thought I could have sworn I'd already fixed it!

30 minutes of my time re-fixing the bug. Oh well! :P

skurfer added a commit that referenced this issue Jun 10, 2013
resolve aliases when browsing in the 3rd pane (by type). Fixes #1484
@skurfer skurfer merged commit 3c68c94 into quicksilver:master Jun 10, 2013
@skurfer
Copy link
Member

@skurfer skurfer commented Jun 10, 2013

Already merged, but FYI, I can get to symlinks if I search for them directly in the third pane, but if I search for the parent folder of a symlink, then navigate to its children, the symlink doesn't appear.

@pjrobertson
Copy link
Member Author

@pjrobertson pjrobertson commented Jun 11, 2013

Great, thanks Rob

but if I search for the parent folder of a symlink, then navigate to its children, the symlink doesn't appear.

Really, works fine for me?
I have a symlink for /Uni which points to the real folder at /Documents/Uni
If I find '
' in the 3rd pane, then hit → the '
/Documents/Uni' folder shows up.

On 11 Meh 2013, at 04:05, Rob McBroom notifications@github.com wrote:

but if I search for the parent folder of a symlink, then navigate to its children, the symlink doesn't appear.

@pjrobertson pjrobertson deleted the aliases branch Jun 11, 2013
@skurfer
Copy link
Member

@skurfer skurfer commented Jun 11, 2013

OK, I see what's going on. I had something like this:

~/link → ~/folder

I just tried creating

~/Uni → ~/Documents/School

and the symlink appears now when I navigate into my home directory, but it appears with the name and location of the real folder. Better than nothing, but probably not what people expect. I think there's already an issue open for that.

When I had a link to a folder in the same directory, the "resolved" path would have been a duplicate of the real thing, which was already included, which is why I never saw it.

@pjrobertson
Copy link
Member Author

@pjrobertson pjrobertson commented Jun 11, 2013

but it appears with the name and location of the real folder. Better than nothing, but probably not what people expect. I think there's already an issue open for that.

I got started on fixing this the other day, then looked at how Finder does this… (turn on "View" > "Show Path Bar")
If you go to column view, you'll see that whilst it looks like you're in

username > Uni

the path bar actually shows:

username > Documents > School

So I decided that we should be consistent with what Finder shows, although it is still confusing (you hit ← and you end up in '' not '/Documents' as you might think

On 12 Meh 2013, at 01:24, Rob McBroom notifications@github.com wrote:

OK, I see what's going on. I had something like this:

~/link → ~/folder
I just tried creating

~/Uni → ~/Documents/School
and the symlink appears now when I navigate into my home directory, but it appears with the name and location of the real folder. Better than nothing, but probably not what people expect. I think there's already an issue open for that.

When I had a link to a folder in the same directory, the "resolved" path would have been a duplicate of the real thing, which was already included, which is why I never saw it.


Reply to this email directly or view it on GitHub.

@tiennou tiennou mentioned this pull request Oct 28, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants