-
-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Protocol handlers & file associations on OS X and Windows #59
Comments
PR would be great. What would be even better was to make a new module that would handle setting up protocol handlers for all the different platforms and use that here. |
That sounds good but I couldn't quite imagine it totally elegant from an architecture point of view. Maybe something in like // Both return a plist format, but not the full plist, just an object with sub-properties CFBundleDocumentTypes / CFBundleURLTypes
// Use by extending plist object with it
.mac.supportedFiles([ { extension: "mp4" /* and more info about the type */ }]);
.mac.supportedProtocols(/* same format as currently supported */);
// Both return a string in .reg format
.win.supportedFiles(plistHandle, [ { extension: "mp4" /* and more info about the type */ }]);
.win.supportedProtocols(plistHandle, /* same format as currently supported */); That sounds reasonable. |
I started making progress on this front in https://www.npmjs.com/package/register-protocol-handler - would be grateful for help as I don't have a lot of time to spare for the next few weeks due to work |
@jden nice - will take a look later |
@jden Great job! This has to be run at runtime or install time. This isn't bad, but on OS X it has to happen when building the package, also on Linux (*.desktop files), so we shouldn't integrate it into electron-packager |
@Ivshti agree, the primary functionality shouldn't be built in electron-packager, but whatever the strategy for registering applications as protocol handlers is on each particular platform, electron-packager should use that to make it easier for people to build protocol handler applications with electron |
@jden @mafintosh I think we can consider this closed, and just link @jden's module somewhere. Since we cannot do it on building the app (electron-packager), the best approach would be that developers call it on first init. |
@lvshti agree. In Windows, it would have to be done by an installer, which was previously decided to be out of scope |
You can make extra Worked for me like this: var opts = {
version: '1.4.3',
dir: '.',
arch: 'x64',
platform: 'darwin',
'app-bundle-id': 'com.postbird',
icon: 'build_files/icon.icns',
'extend-info': 'build_files/Info.plist',
...
}; build_files/Info.plist (register <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundleDocumentTypes</key>
<array>
<dict>
<key>CFBundleTypeExtensions</key>
<array>
<string>sql</string>
</array>
<key>CFBundleTypeIconFile</key>
<string>SQL.icns</string>
<key>CFBundleTypeName</key>
<string>SQL File</string>
<key>CFBundleTypeOSTypes</key>
<array>
<string>sqlt</string>
</array>
<key>CFBundleTypeRole</key>
<string>Editor</string>
<key>NSDocumentClass</key>
<string>SPDocumentController</string>
</dict>
</array>
<key>CFBundleURLTypes</key>
<array>
<dict>
<key>CFBundleURLName</key>
<string>Postgres Database</string>
<key>CFBundleURLSchemes</key>
<array>
<string>postgres</string>
</array>
</dict>
</array>
</dict>
</plist> |
I've created a package to handle writing to the windows registry at https://github.com/Tympanix/electron-regedit |
Electron-packager should support setting up protocol handlers & file associations for built apps.
Currently, only protocol handlers on OS X are supported.
Adding file associations for OS X won't be hard - just the same plist modification logic as protocol handlers.
As for Windows, it will be a little tougher, as registry has to be modified and electron-packager does not generate installers. In this case, it can add .reg files somewhere in the output dir, and then let the developer decide how to make use of it.
If that's OK, I'll PR when I make progress with the Windows solution.
The text was updated successfully, but these errors were encountered: