Ipfs-desktop: "Add to IPFS" from Native File Manager

[lidel]

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?

[hacdias]

@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.

[hacdias]

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

[olizilla]

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.

[hacdias]

@olizilla 2 refers to the whole menu as a primary/first-level option. 1 is under Send To

[djdv]

@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.

[djdv]

@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.

[hacdias]

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?

[djdv]

@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.

[hacdias]

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?

[lidel]

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).

[hacdias]

@lidel completely agreed!

[alanshaw]

so perhaps the first iteration could just add file to the root of MFS and open Web UI's Files with it?

+1

[hacdias]

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

[hacdias]

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).

[chrisdebian]

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

[lidel]

@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:

1. Detect that IPFS Desktop is installed (check if its .desktop file present or something)
2. If present, then add the option to "Import to IPFS" that executes ipfs-desktop --add="/path/to/file.jpg"