ipfs
"Add to IPFS" from Native File Manager
Summary
Installation of IPFS Desktop could register native integration that enables user to add files to IPFS (MFS) directly from operating system's file manager.
For example: a dedicated context menus in Windows and analogous UX for other OSes.
Status
Right now we are in design stage, gathering prior art and ideas. If you are familiar with good UX specific to your operating system, or got some examples, comment below :)
Prior Art
MS Windows
"add and copy link to public gateway" by @djdv:
MacOS
:grey_question:
Linux/BSD
:grey_question: – which desktop environments should we target?
@djdv do you happen to have that code public somewhere? 😄 I really want to add that feature to Windows, but haven't taken a look at it yet.
After searching, it seems somewhat easy to add a shortcut to both of those locations. Either 1 or 2. 2 is easier from my point of view, but hardest for a user to find.
It would call IPFS Desktop somewhat like:
/path/to/binary --add-to-mfs /path/to/file
And then everything would be handled inside our app. What do you guys think?
/cc @ipfs-shipyard/gui
To clarify, does 2 refer to the "Share" menu, or the "Open with" menu or the top menu itself? My preference is strongly for the top menu, as in th demo gif in the issue description. I think every submenu level down we go we lose a huge chunk of users who will ever find it.
@olizilla 2 refers to the whole menu as a primary/first-level option. 1 is under Send To
@hacdias Sorry for the delay, I totally missed the notification. This is from an old project that basically just provided IPC from a Windows shell dll to a user program that wrapped the IPFS binary.
I intended on cleaning it up and releasing it but unfortunately got interrupted by IRL things at the time. Although I still have the WIP versions at various stages. I'll poke around and see if I can scrap together something useful. (but not tonight) Likely a screencast with a braindump and various sourcecode.
@hacdias Silly screencast alert: https://www.youtube.com/watch?v=6PK87zlgG0M
I'm not sure if any of this is helpful, but may be a good starting point. Transcription of the important things: I implemented these COM interfaces as a DLL https://docs.microsoft.com/en-us/windows/desktop/shell/how-to-implement-the-icontextmenu-interface https://docs.microsoft.com/en-us/windows/desktop/api/shobjidl_core/nn-shobjidl_core-ishellextinit as well as this https://docs.microsoft.com/en-us/windows/desktop/api/olectl/nf-olectl-dllregisterserver
This gives you a DLL that can be registered with the OS, so that the OS can load and call you on Explorer operations. You don't have to implement this in C++ and I think you can make living/in-process objects to avoid producing a DLL too. But I believe you do have to interact with the COM interfaces to get this functionality.
For this specific implimentation: The DLL receives a list of (file)entries from the OS which then get sent off to a background program that does all the heavy lifting. The background program provides the DLL with capabilities like "Add X", "Do GC", "shutdown daemon", etc. and the DLL populates the submenus with them. When one of these is invoked, the DLL passes a value back to the program which does the actual invocation/call.
While IPC isn't necessary, it's important to note that unless you implement more APIs to handle upgrades, the DLL will never be unloaded. So your context menu will be less dynamic, and you have to make sure it doesn't leak or crash. Offloading this mitigates some of that. We can update the user program and provide new context menu entries if we now support them, without updating the DLL. It only acts as an interface in itself.
I think the project source is too incomprehensible in its current state, but I'm not keeping it a secret. If you want to know how something specifically is implemented, I can try to review the relevant section and produce a good example from instead of using the existing code.
Hello @djdv! Thank you so much for the screencast. It was awesome! Although I was thinking on a, perhaps, simpler solution:
- During installation add the registry key for a simple shortcut menu that would execute
...desktop.exe --add $filename. - During uninstallation that key would be removed.
Then we'd let IPFS Desktop deal with everything else. What do you think?
@hacdias For sure! MSDN actually recommends using those "verbs" over the "IContextMenu" interface if you don't need anything additional that they offer. The text is pretty demotivating imo but accurate 😆
IContextMenu is the most powerful but also the most complicated interface to implement. We strongly recommend that you implement a verb by using one of the static verb methods.
The reasons for me choosing a context menu I think revolved around supporting "folders" (which are not just directories). I forget if you need to do something special for verbs to be invoked on things like right clicking a drive/mount in "My Computer". Same with the lack of selection (right clicking empty space inside a folder). I think for verbs you must have something selected to be invoked at all, but I haven't dealt with either of these in a while so my memory on the details are a bit hazy.
Esoteric Windows-isms aside, you probably won't have any issues with using a verb over a context menu interface here.
Cool!
@ipfs-shipyard/gui before working more on this, a question for y'all: after calling desktop with the file's path, I wanted to show a modal to ask the user where to save the file (in MFS). And I was wondering if that would be a separate window, or something to incorporate into Web UI. What do you think?
It may be tricky to get the destination picker UX right across all platforms, so perhaps the first iteration could just add file to the root of MFS and open Web UI's Files with it? It does not require new development and still lets user to organize files after "Add to IPFS".
To make UX nicer we could highlight newly added file by pre-selecting it (checkbox next to it) by passing its CID via URL (needs change to Web UI).
so perhaps the first iteration could just add file to the root of MFS and open Web UI's Files with it?
+1
A ref for macOS:
- https://developer.apple.com/app-extensions/
- https://stackoverflow.com/questions/45612515/how-to-embed-a-mac-app-extension-in-an-electron-app
On macOS it doesn't seem to be simple to do. That functionality seems to be called a Plugin and generally comes with a containing application even though the binaries are not related to each other.
The only option I found was to create a dummy CLI app and add an extension/plugin. Then compile and copy the .appex file to a PlugIns folder in the final .dmg. I wonder if in the future we couldn't move to platform specific solutions (see #867).
Summary
grey_question
Linux/BSD
grey_question – which desktop environments should we target?
Rather than looking at Desktop Environments (DEs), would a better approach be to look at the most used File Managers, as that's what this issue pertains to? We can then raise feature requests against each file manager, to incorporate this functionality. As of 14 Feb 2021, this looks like a fairly representative list of most used file managers:
https://www.ubuntupit.com/linux-file-manager-reviewed-for-linux-users/
So as a start, it would be good to raise requests against the following:
Dolphin, Nautilus, Thunar, Konqueror, Midnight Commander, Krusader, PCMan, Nemo, XFE, emelFM2, SpaceFM.
The list goes on, but returns diminish.
If this is considered a sensible approach, I could start to raise the requests, against the most popular, first.
Thanks,
Chris chris_debian 2E0FRU
@chrisdebian sadly I am not familiar with graphical FMs to advise here, but if you want to look into this, I believe each file manager would have to somehow:
- Detect that IPFS Desktop is installed (check if its
.desktopfile present or something) - If present, then add the option to "Import to IPFS" that executes
ipfs-desktop --add="/path/to/file.jpg"
Just want to note that as soon as I installed IPFS Desktop and restarted (Windows 10 Home - 21H2 v_19044.1706) "Add to IPFS" showed up in the context menu of File Explorer for directories and files. I didn't make any registry changes or change the install (aside from installing to second drive).
The only change I made in the system environment was adding proper IPFS PATH variables.
The feature works great, shows up in my Files ready to pin. Another note, the context menu item was there many versions ago since I first installed the program, and not new to the recent version.
I'm curious now why this showed up for me so seamlessly and other's don't have the option.
Windows 10 Home (21H2) Version: 19044.1706
IPFS Desktop UI Version: 2.15.0
IPFS Agent: go-ipfs v0.12.2 desktop
@chrisdebian sadly I am not familiar with graphical FMs to advise here, but if you want to look into this, I believe each file manager would have to somehow:
- Detect that IPFS Desktop is installed (check if its
.desktopfile present or something)- If present, then add the option to "Import to IPFS" that executes
ipfs-desktop --add="/path/to/file.jpg"
Correct, a File Manager (especially the top ones) would be using UI code properly segregated from any of the OS code and should be doing only one thing, visually displaying mounted content. All of it's back-end instructions are coming from system environment variables and registry entries. I shutter to think how much slower File Explorer would be if it were doing that much extra work, it can be slow enough as is, hah.
@chrisdebian It would be a tedious task to work on an Explorer to Explorer basis, and make forward and backward compatibility a big undertaking for every update. The most streamlined way IMO that would only require the one-time change to the codebase would be to, on install/update of IPFS Desktop:
- Check OS
- Add context variable to the relevant script/database (.bashrc, PATH, Windows Registry Entry).
- Add the updated command/UUID as a config entry (with warning that it's an advanced feature) as some users may want to disable IPFS uploads for certain file types or entire directories to not accidentally upload sensitive info. Doing this through the config file would be much easier than doing it through the OS and could cause major problems if done incorrectly.
- Installer should remove the context menu entry and related changes. This is another reason I think the variable change should be written to the config file and not added only to the uninstall instructions during install is in case a user does opt to exclude certain files or directories, the uninstaller can reference the config file with the most recent changes, and not what could be outdated info from the install.
can we add such functionality to nemo file browser that is available for linux?
