Use links option in OpenInExplorer

[ghost]

Well, there is the bug in macOS Mojave and Catalina (as I consider it as a bug) with the terminal command "open -Rn …". This -n option should induce the Finder to open one window for each file name, but it doesn't. It shows the contents of the directory in question instead, highlighting only the last file name selected. I filed the issue to Apple, but I don't believe that there will be a remedy in due time.

So I thought of a different approach. Instead of one window for each there could be one link for each, in an arbitrary directory.

I realized this as an option originally meant for Mac users. But maybe some Linux users may also prefer using this option to opening multiple windows when many images are selected. For Windows users there is the drawback that Windows seems to allow to set links in the terminal only to administrators. If there is no workaround for this restriction, I can shut out Windows from this option altogether.

Please give it a critical judgment and feel free to improve my English message wording.

@BzKevin Incorporating this option needed a massive reorganization of the code. Please be most critical as you are the owner of the script.

[wpferguson]

I think this should be a new script, not a change to an existing one.

The purpose of OpenInExplorer is to open the directory containing the image and highlight the image. It works consistently across all operating systems, exhibiting the same behavior, including the behavior when multiple images are selected.

Since you would like a different behavior and the solution wont work on windows, I would suggest a new script that only runs on macos and linux.

Did you mean to include the contrib/german_unlauts.lua file in the PR?

[ghost]

No, I don‘t want contrib/german_unlauts.lua in this PR. I didn‘t mean to include it, and now I don‘t dare to delete it because I want it to serve as an example for the translation issue.

What you postulate as the purpose of OpenInExplorer holds only for Windows and Linux with Nautilus. It doesn‘t work satisfactorily on macOS, and even on Linux KDE with Dolphin the result looks very different.

I don‘t change this behavior. I only offer an optional choice for the Mac user and for the Linux user who wants to have one manageable window for multiple selected images. It‘s a pity that Windows users cannot have this choice, as it seems. It‘s only the KDE user who can do without it.

[ghost]

Thinking about your objection, Bill, I find that both of the different ways to open the file manager have their disadvantages. They depend on what the user wants to achieve.

If he wants to look into the directory, e.g. sidecar files or subdirectories, even the crippled macOS Finder presentation would do. But on Windows and with Nautilus you get as many directory windows as selected images even if they all show the same directory.

But if the user wants to work on the file and is not interested at the whereabouts, e.g. to copy or link it somewhere, he may like to find all targets at one place, albeit indirectly given as links.

There is no need for linking with a single selection, of course.

I propose that Kevin may decide on introducing the use_links option.

[wpferguson]

Letting @BzKevin decide works for me. Before we can merge, you need to squash all your commits into one. Deleting and replacing the file makes it impossible to tell what changed between versions. Try using gitk on contrib/OpenInExplorer.lua and stepping back through the commits and you'll see what I mean.

[BzKevin]

I’ll try a take a deep look in the next few days, but from the email chain it sounds as though adding a “preference” to enable or disable the described link behavior would be a good and acceptable solution. I agree with Bill, in that my first reaction would be a whole new script, but if what you describe is true about it not working on Linux, I can understand why you may want an alternative within the same script.

I would suggest disabling the preference of on a Windows PC, so there is no risk of it getting enabled accidentally on a windows computer.

Does that make sense? or have I completely misread things?

On Fri, May 29, 2020 at 10:14 PM wpferguson notifications@github.com wrote:

Letting @BzKevin https://github.com/BzKevin decide works for me. Before we can merge, you need to squash all your commits into one. Deleting and replacing the file makes it impossible to tell what changed between versions. Try using gitk on contrib/OpenInExplorer.lua and stepping back through the commits and you'll see what I mean.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/darktable-org/lua-scripts/pull/254#issuecomment-636261348, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIVSGIFNGQBYY3LX5ICBV23RUBTZ5ANCNFSM4NI6OV2A .

[ghost]

@wpferguson

Before we can merge, you need to squash all your commits into one. Deleting and replacing the file makes it impossible to tell what changed between versions. Try using gitk on contrib/OpenInExplorer.lua and stepping back through the commits and you'll see what I mean.

I must confess, I don't know how to squash effectively. I get my git infos from [https://git-scm.com/docs], but I'm afraid I have produced too much of a mess to find out. Could it be best to delete this use-links-option branch and start afresh from master? I found that if I checkout to master and git merge --squash use-links-option even my german-umlauts files are gone because I deleted them in the use-links-option branch. What is it you need?

[wpferguson]

Here's how I develop. I forked the darktable-org/lua-scripts repository to my github account. Then on my local machine I cloned my fork of the lua-scripts repository. If I do a git remote , that says origin is my fork of the lua-scripts repository. I then do a git add remote upstream https://github.com/darktable-org/lua-scripts to add the official lua scripts repository. When I develop a new feature, I do the following on my local machine:

git checkout master
git fetch upstream master
git merge upstream/master
git push origin master

Now my local repository is up to date. Then I do

git checkout -b <my new feature>

I do my development then commit my changes. Once I'm satisfied I do

git push origin <my new feature>:<my new feature>

which adds my branch to my github repository. When I open a browser and go to my github lua-scripts repository it asks if I want to do a pull request. I fill it out and submit it. If there are any changes, I checkout the branch on my local machine, then commit them, then push the branch in the same way I did before. That updates the pull request automatically.

Most times when I develop a new feature with a lot of commits, I copy the final file off to the side then create a new branch and copy the new feature in and commit it. That way when I do the push and pull request it shows only 1 commit rather than all my intermediate commits.

Once the pull request is merged, then in my local repository I do:

git checkout master
git fetch upstream master
git merge upstream/master
git branch -d <my new feature>
git push origin master

You can sqash commits with git rebase, but I haven't done that much.

[ghost]

Thank you, Bill, that's fine advice. I'll test it.

[wpferguson]

I've tested this and it works fine. To work around the history problem, you could copy this version of the file off to the side somewhere, then close this PR. Start a new branch, then copy the set aside file over the original, check it in, and do a new PR.