There are four methods that are available on electron.shell in the main process that we could plausibly want to use from the renderer, but which do not yet have analogs on the atom global:
showItemInFolder (reveals a certain item in the OS’s file browser)trashItem (moves a certain item to the trash)openExternal (takes a URI and opens it with the OS’s default behavior; https: links in a browser, mailto: links in the default mail client, etc.)openPath (takes a file path and opens it with the OS’s default behavior)
There's also writeShortcutLink and readShortcutLink, but those feel too esoteric to bother with.
Following existing conventions, these analogs would be available on the atom global directly:
atom.showItemInFolderatom.trashItematom.openExternalatom.openPath
If we wanted to stop dumping things in the top-level namespace, we could also start namespacing these methods the same way they're grouped in the Electron API:
atom.shell.showItemInFolderatom.shell.trashItematom.shell.openExternalatom.shell.openPath
If we did this, though, we'd want to add atom.shell.beep() and turn atom.beep() into a proxy for atom.shell.beep(). We'd also want to do the same with other such methods — e.g.,
atom.app.addRecentDocumentatom.win.isMaximized
and so on.
I would be much more tempted to do this if there were more methods to bring in… but since I'm adding only four, I'm tempted to leave things the way they are and just define the new methods directly on atom.
The purpose here is to remove the requirement for community packages to use @electron/remote for these common tasks. @electron/remote is an elaborate hack and we should encourage packages to eliminate or reduce their reliance on it.
There are four methods that are available on
electron.shellin the main process that we could plausibly want to use from the renderer, but which do not yet have analogs on theatomglobal:showItemInFolder(reveals a certain item in the OS’s file browser)trashItem(moves a certain item to the trash)openExternal(takes a URI and opens it with the OS’s default behavior;https:links in a browser,mailto:links in the default mail client, etc.)openPath(takes a file path and opens it with the OS’s default behavior)There's also
writeShortcutLinkandreadShortcutLink, but those feel too esoteric to bother with.Following existing conventions, these analogs would be available on the
atomglobal directly:atom.showItemInFolderatom.trashItematom.openExternalatom.openPathIf we wanted to stop dumping things in the top-level namespace, we could also start namespacing these methods the same way they're grouped in the Electron API:
atom.shell.showItemInFolderatom.shell.trashItematom.shell.openExternalatom.shell.openPathIf we did this, though, we'd want to add
atom.shell.beep()and turnatom.beep()into a proxy foratom.shell.beep(). We'd also want to do the same with other such methods — e.g.,atom.app.addRecentDocumentatom.win.isMaximizedand so on.
I would be much more tempted to do this if there were more methods to bring in… but since I'm adding only four, I'm tempted to leave things the way they are and just define the new methods directly on
atom.The purpose here is to remove the requirement for community packages to use
@electron/remotefor these common tasks.@electron/remoteis an elaborate hack and we should encourage packages to eliminate or reduce their reliance on it.