Add missing shell methods on atom global

[savetheclocktower]

Closes #1563.

This adds in the following methods:

• atom.trashItem
• atom.openPath
• atom.openExternal
• atom.showItemInFolder

All of these exist on require('electron').shell, but are not 100% able to be called from the renderer for one reason or another. As with many other methods defined on the atom global, these methods proxy to the main process via IPC, then receive the outcome from the main process.

Specs are present for atom.trashItem, but I've got no clue how I'd test the others. That'll require manual testing.

[Daeraxa]

I tried them all out in the dev tools console and they seem to work fine. Even substituted the shell.trashItem in my init script for atom.trashItem and it is still working.

Also checked that atom.trashItem still honours $ELECTRON_TRASH, was able to set that to kioclient and watch it fail in the same way as if it was set on shell.trashItem.

[savetheclocktower]

Just pushed a commit that removes (nearly) all core usages of require('@electron/remote').shell in favor of their atom equivalents. We'll see if CI likes it.

There are other usages of @electron/remote that really ought to be replaced, but that will be a more complicated task for a later PR. I did want to know what we were up against, so I tried to catalog them:

Various packages

• remote.app.getPath (plus string argument)
• remote.app.getLocale
• remote.BrowserWindow.fromId

application-delegate.js

• remote.getCurrentWindow
• remote.screen.getPrimaryDisplay
• remote.systemPreferences.getUserDefault
• remote.dialog.showMessageBox
• remote.dialog.showMessageBoxSync (how?)

initialize-test-window.js

• remote.process.stdout
• remote.process.stderr

reopen-project-menu-manager.js

• remote.app.getJumpListSettings
• remote.app.setJumpList

These are insidious because they mirror their main-process APIs exactly. So if we wanted to replicate BrowserWindow.fromId, it'd need to return an instance of BrowserWindow — which itself has methods that probably will need to talk to the main process.

I haven't even investigated how @electron/remote replicates synchronous methods, since they presumably need to go async to talk to the main process. dialog.showMessageBoxSync is the perfect example; I think we'll need to support it indefinitely (since it's part of the atom.confirm API that we expose to packges), but I don't know how it manages to block the UI while it communicates with the main process.

This aspect of it is less urgent. But the fact remains that @electron/remote’s own README tries to talk folks out of using it, so it's not something we should rely upon in the long term. If we can get what we need via other means, it almost certainly will lead to a more reliable Pulsar.