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

show "Open" above "Open URL" by default #1824

Merged
merged 1 commit into from Aug 28, 2014
Merged

show "Open" above "Open URL" by default #1824

merged 1 commit into from Aug 28, 2014

Conversation

skurfer
Copy link
Member

@skurfer skurfer commented Apr 16, 2014

More than one new user has been confused because when copying a file from the clipboard, the object will contain a file URL. In that case, “Open URL” is what they see by default. They create a trigger with that and then the trigger quits working after a relaunch because the URL data goes away.

They should be using “Open”, but this is not obvious.

I “broke” this myself in 78079f4, but that was not the right answer. I’ll lower the precedences in Remote Hosts instead.

@skurfer
Copy link
Member Author

@skurfer skurfer commented Apr 16, 2014

I’ve released a new Remote Hosts plug-in that should address the original problem.

@pjrobertson
Copy link
Member

@pjrobertson pjrobertson commented Apr 17, 2014

So what are the implications of making Open higher than Open URL...? ;-)

Since they both accept differet dObject types it shouldn't matter right?

@skurfer
Copy link
Member Author

@skurfer skurfer commented Apr 17, 2014

Before my original change, I think they were both equal (2), but it should only be an issue when an object has both types, which as far as I know, only happens when a file is pasted or dropped.

For file objects that happen to include URL data
@skurfer
Copy link
Member Author

@skurfer skurfer commented Aug 3, 2014

Rebased and force-pushed this to deal with the recent submodule changes.

@skurfer
Copy link
Member Author

@skurfer skurfer commented Aug 28, 2014

We have to do another 1.2.0 release anyway. You think this can make it in?

@pjrobertson
Copy link
Member

@pjrobertson pjrobertson commented Aug 28, 2014

I can't think of any other objects that might have an URL and a file type except for file objects.
I'm assuming you can't either? In which case this makes sense.

Is there a reason you haven't just reverted that bad commit?

Also - should we have a unit test for this? Although that might be hard to test, since it can be changed by user prefs

@skurfer
Copy link
Member Author

@skurfer skurfer commented Aug 28, 2014

Reverting the commit would make Open and Open URL equal (2). I think we need to be more explicit.

On the unit test, I’m not sure exactly what we’d test, unless we came up with a comprehensive list of what should be default for all types. But even then, this problem ultimately originated from something a plug-in was doing, so we wouldn’t have caught that. Precedence doesn’t change that often anyway.

@pjrobertson
Copy link
Member

@pjrobertson pjrobertson commented Aug 28, 2014

Yep, all good. I just like to be sure ;-)

pjrobertson added a commit that referenced this issue Aug 28, 2014
show "Open" above "Open URL" by default
@pjrobertson pjrobertson merged commit f2f2d22 into master Aug 28, 2014
1 check failed
@pjrobertson pjrobertson deleted the precedence branch Aug 28, 2014
skurfer added a commit that referenced this issue Aug 29, 2014
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