Third party tools support [DONE]

[darek]

Mike, I think if you've added an easy way to support third party tools it would give Files a huge extra power without much work on your part. I'm thinking about something simple: you pick an app (or just a binary) and then it can get arguments based on what's going on in Files' windows. Examples of arguments you could pass (one of more):

* folder path in the left/right window
* file name in the left/right window
* full file path in l/r window
* user entered value
* list of selected files
* etc

This way, I could easily use external tools to add features like quick folder sync or file diff (Kaleidoscope or Beyond Compare) and many others.

Adding keyboard shortcuts for such extra tools would be a critical feature, to make them powerful.

[mike]

Mike, I think if you've added an easy way to support third party tools it would give Files a huge extra power without much work on your part. I'm thinking about something simple: you pick an app (or just a binary) and then it can get arguments based on what's going on in Files' windows. Examples of arguments you could pass (one of more):

* folder path in the left/right window
* file name in the left/right window
* full file path in l/r window
* user entered value
* list of selected files
* etc

This way, I could easily use external tools to add features like quick folder sync or file diff (Kaleidoscope or Beyond Compare) and many others.

Adding keyboard shortcuts for such extra tools would be a critical feature, to make them powerful.

Darek, thanks for your thoughts regarding external tools.
I absolutely agree that extensibility is a crucial requirement.
And we already have something available in form of "external editors", which are not very flexible although.

I have some questions about desired level of integration of 3rd part tools like (which might be not so obvious):
- should they run in native UI environment and/or in terminal emulator?
- should Files wait for their completion or should it just start them and leave?
- should they be able to access VFS like network resources or archives content?
- if so - should they be able to modify content of that VFS? (current external editors integration doesn't provide such functionality)
- should they be able to pass any result to Files back and somehow affect it?

[darek]

I see it pretty much like your current integration of editors, but on steroids So: native UI, don't wait for their completion, don't know about VFS and archives (I don't understand the question to be honest, so I'm guess it's not something I'd need), and no need for passing results to Files (since we don't wait for them anyway).

That's the basic implementation that would handle the most common scenarios for me.

[mike]

I see it pretty much like your current integration of editors, but on steroids So: native UI, don't wait for their completion, don't know about VFS and archives (I don't understand the question to be honest, so I'm guess it's not something I'd need), and no need for passing results to Files (since we don't wait for them anyway).

That's the basic implementation that would handle the most common scenarios for me.

Darek, under VFS access I mean an ability to manipulate, say, contents of a remote SFTP site.
I plan to implement this feature for external editors someday, hopefully sooner than later.
Of course this means some juggling with background copying files back and forth to local file system so regular apps can access them.
In my mind it's useful to be able to edit, for instance, remote .htaccess with your favourite editor directly without doing some extra movements.

[darek]

Ah, so that's one of the "nice to haves". Be careful to not spread yourself to thin here though. Because doing a good file manager AND a good ftp tool can get tricky. Personally I'm fine with using external tool for that (Filezilla & WinScp on Windows and Cyberduck na Mac).

Oh, which reminds me! It's currently impossible to drag items between Cyberduck and Files. Having that would be very helpful.

Or at least a keyboard shortcut to "Open Finder in current folder" so I can quickly open a new Finder window, drag the files, close Finder.

[don]

Plugin enabled architecture is crucial, no question about it. But it has to be thought through carefully. As it was noted before - not to stretch too thin.
My take would be to focus on the API, easy integration and plugin templates. Leave the functionality like SFTP to the plugin devs.

An I am classic UI fan. And the power of the manager like that, in my view, is the keyboard navigation. As far as it is there and thought through - well, I survive the modern UI

[darek]

the power of the manager like that, in my view, is the keyboard navigation

Hear, hear! If it's not accessible quickly through keyboard only, it might as well not exist. Commander is all about power and speed. Keyboard for the win! Thanks God, Mike understands that. That's why he made the new batch rename feature keyboard centric.

[mike]

Friends,

Lets bring this thread back to life!

Will anybody bother trying current results in external tools integration?
It's config-file only now (no editing via fancy Preferences pane), but already supports the following placeholders:
- produces % symbol: %%
- directory path: %r, %-r
- current path: %p, %-p
- filename: %f, %-f
- filename without extension: %n, %-n
- file extension: %e, %-e
- selected filenames as parameters: %F, %-F, %10F, %-10F
- selected filepaths as parameters: %P, %-P, %10P, %-10P
- list of selected files:
- filenames: %LF, %-LF, %L10F, %-L50F
- filepaths: %LP, %-LP, %L50P, %-L50P
- toggle left/right instead of source/target and vice versa: %-

* "-" sign in placeholder means "target panel" instead of "source panel", or "right" instead of "left", if %- was toggled.
* L prefix means writing a list of selected filenames/filepaths to temporary file and pass it's path as a parameter.
* numerical prefix like %-10P limits the maximum amount of results fetched.

The following one is under construction:
- dialog value: %?, %"some text"?

Of course, tools support hotkeys and can run in built-in terminal.
No network/archives/other vfs support currently, only native filesystems.

Just a simply example:

Code: Select all

    "externalTools": {
        "tools_v1": [
            {
                     "title": "TextEdit",
                     "path": "/Applications/TextEdit.app",
                     "parameters": "%P",
                     "shortcut": "⇧⌥T"
            }            
        ]
    }

Mike.

[darek]

Mike, I'd be happy to try.
Is this supposed to work in 1.1.2? Because I don't seem to be able to trigger it there. Or is there a new build somewhere?
Also, where should this script go, into the ~/Library/Application Support/Files/Config/Config.json?

[mike]

Darek,

Here's the latest build: http://magnumbytes.com/downloads/previe ... (1640).zip

Yep, this config supposed to live in ~/Library/Application Support/Nimble Commander/Config/Config.json.
Also - tools already supports on-the-fly config reloading, so it can reflect changes in that file without reloading whole app.

Mike.