Send files and folders via command line argument

[Dr-Hex]

Checklist

• I have searched the issue tracker for open issues that relate to the same feature, before opening a new one.
• This issue only relates to a single feature. I will open new issues for any other features.

Is your feature request related to a problem?

Please, add the ability to accept command line argument to have faster and convenient way to download/upload files and folders.

Describe the solution you'd like to see.

Examples:

rymdport.exe "C:\...\file.txt"
should recognize 1st argument as a file and automatically start uploading it.

rymdport.exe "C:\...\folder"
should recognize 1st argument as a folder and automatically start uploading it.

rymdport.exe 4-backwater-spin
should recognize 1st argument as alias and automatically download the appropriate file or folder.

[Jacalz]

Am I correct in understanding that you want this to also open the application at the same time?
I.e. that passing a file or code should open the application and start the transfer?

If not, I'd recommend that you install https://github.com/psanford/wormhole-william instead.

[Dr-Hex]

Am I correct in understanding that you want this to also open the application at the same time? I.e. that passing a file or code should open the application and start the transfer?

Sure.

If not, I'd recommend that you install https://github.com/psanford/wormhole-william instead.

Thanks for alternate suggestion.

[Jacalz]

Cool. Thanks for confirming. I think this would require quite a lot of changes at the moment.

Thinking about this, I'd rather just implement support for passing files/folders as part of opening a file from a file manager in Rymdport (like a "Send with Rymdport" context menu or similar). Most other cases should be covered by using a cli as the one mentioned above.

[Dr-Hex]

Yeah, it would be cool to pass direct path, because the current menu is, well, quite too non-convernient (large icons, little window size, require too much scrolling, clicking etc to make a simple action - select the desired file).

[Dr-Hex]

Also, not sure why, however, it's the first time when I see the OS Windows "Send to" context menu doesn't display the item, when I place the shortcut of your program onto the folder

%APPDATA%\Microsoft\Windows\SendTo

[Jacalz]

Yeah, it would be cool to pass direct path, because the current menu is, well, quite too non-convernient (large icons, little window size, require too much scrolling, clicking etc to make a simple action - select the desired file).

Yeah, I know that is unfortunately. It is a bit blocked on the upstream GUI toolkit not providing nicer file pickers. I might be able to use a library like https://github.com/ncruces/zenity for native dialogs but I haven't gotten around to it yet and I don't know how well they work with UI interaction (wants to block the UI while they are open etc).

Also, not sure why, however, it's the first time when I see the OS Windows "Send to" context menu doesn't display the item, when I place the shortcut of your program onto the folder

I didn't know that it existed. Interesting. I'm not a Windows user so I can't tell you why really but I expect it might be because the application doesn't expose any context menu actions in the manifest

[Jacalz]

I think I have decided on the path forward here. The plan is to implement sending by right-clicking in the file manger (see #91) and that will require being able to pass files and folders as input through the command line. That part will have to be implemented for that to work and I think it might be generally useful for some people as well.

However, I don’t see quite the same need for implementing the same support for receiving (it can’t happen from the file manager and seems less useful to me). If someone wants to receive items using the terminal, I believe the best option is using a terminal client for Magic Wormhole instead (as mentioned above).

[Jacalz]

This has now been resolved with 40aacdd. Thanks for opening this issue.

[Jacalz]

The receiver side of this will probably be more-or less solved when #92 gets implemented.