OS X extend-info not respected for keys set by other options

[JimiC]

When creating a package for OS X and 'extend-info' file is provided, which contains info that the user wants to override (i.e. CFBundleDisplayName), the packager doesn't respect them.

electron-packager version: 7.0.2
Electron version: 1.2.0
OS: OS X 10.11.5 (64bit)
Target Platform: darwin/x64
Options:

{
appVersion: packageJson.version,
dir: paths.src + paths.app,
platform: process.platform,
arch: ['x64'],
name: packageJson.name,
//version: packageJson.devDependencies['electron-prebuilt'],
download: { cache: './cache' },
ignore: '.+map',
out: paths.out,
icon: 'resources/' + process.platform + '/icon',
asar: true,
overwrite: true,
'app-version': packageJson.version,
'app-copyright': packageJson.copyright,
'build-version': packageJson.version,
'version-string': {
    CompanyName: packageJson.author.name,
    FileDescription: packageJson.name,
    ProductName: packageJson.productName,
    OriginalFilename: packageJson.name + '.exe'
},
'extend-info': 'resources/' + process.platform + '/product.plist'
}

[JimiC]

Problem lies with mac.js line 78~85. I believe that that code-block needs to be moved right at the end of the assignments (line 139). So if the user wants to override any info the packager will respect them.

P.S.: I've done so on my dev machine and the packager now produces the desired package.

[malept]

This is by design. What is your reason for overriding that key with a value other than the app name provided to electron-packager?

[JimiC]

Sorry for the late reply but I was gathering the info in order to make my case.

I understand that the extend-info is intended to "extend" the Info.plist but bare with me.

Let's assume that we are developing a cross-platform Electron app and we want to distribute it in all major platforms (Windows, Mac OS, Linux).

Assume that:

• The 'name' attribute in package.json has been set to 'lowercase'
• The 'title' attribute in the Browser Window has been set to 'PascalCase'.

The packager currently produces (according to the options in the OP):

OS	Executable Name	Process Name	Menubar Name	Taskbar / Dock Name
Windows	lowercase (depends on 'name' attribute)	lowercase (depends on FileDescription)	PascalCase (depends on 'title' attribute)	PascalCase (depends on 'title' attribute)
OS X	lowercase (depends on 'name' attribute bound to CFBundleDisplayName)	lowercase (depends on 'name' attribute bound to CFBundleDisplayName)	lowercase (depends on 'name' attribute bound to CFBundleName)	lowercase (depends on 'name' attribute bound to CFBundleDisplayName)
Linux	lowercase (depends on 'name' attribute)	lowercase (depends on 'name' attribute)	PascalCase (depends on 'title' attribute)	PascalCase (depends on 'title' attribute)

Notice the inconsistency with the Menubar Name and Dock Name in OS X.

Now, I know that there is no way to align all platforms to use the same pattern, simply because OS X uses CFBundleDisplayName for the Dock Name and this breaks the pattern.

So this issue arise the need to override/assign the CFBundleName in Info.plist differently than it's set from the packager.

I see two solution for this:

1. Move the extend-info assignment at the end of the procedure.
2. Add assignment attributes for OS X like it does with Windows.

Note 1: If OS X used CFBundleName for the Dock Name we would only need to override/assign that attribute, but it doesn't.

Note 2: This issue also relates to #297.

[erkyrath]

Speaking as the person who added extend-info in the first place... we have a bunch of ways to name the app. The name field from package.json is the default; you can override this with the name argument.

Since the name winds up being used in a bunch of places (including Info.plist and various filenames in the package), it is best for electron-packager to know the name and set it everywhere. (Rather than allowing extend-info to change it behind the packager's back.) This is the plan behind the original design, anyhow.

It sounds like you want to set the name argument to a PascalCase string.

[JimiC]

@erkyrath The problem doesn't lie with the name but with the "title" that OSX doesn't respect.
And yes, I could set name to PascalCase and everything will line up, same as if I set "title" to lowercase.

But that's not what I want, am I?

[erkyrath]

You're talking about the title attribute of the BrowserWindow? That cannot affect the app name in the menu bar, because an Electron app can run without any BrowserWindows open. Or you could have an app with several BrowserWindows, each with a different title.

(I do this. My app, Lectrote, is an IF interpreter. You can have several IF games open in different windows; each window has the game name for a window title. But the menu bar name (and the dock icon name) is always "Lectrote".)

[JimiC]

@erkyrath No offence, but I'm afraid you are looking at the tree and missing the forest.

Yes, Electron can run without any BrowserWindow but what's the point in doing that on a desktop app. Never mind that.

Let's assume that we are not setting a "title" in the BrowserWindow. Here is the result:

OS	Executable Name	Process Name	Menubar Name	Taskbar / Dock Name
Windows	"name"	"version-string.FileDescription"	Electron	Electron
OS X	"name"	"name"	"name"	"name"
Linux	"name"	"name"	Electron	Electron

Note: Let me explain what I mean with "Menubar". On Linux/OSX it's the bar on top of the desktop window where the menu options appear. On Windows it's the bar on top of the app window above the menu options.

Again, spot the inconsistency across the platforms.

Now, I have to agree that using extend-info to override the CFBundleName is not a good choice. Come to think of it again, it's a design "no-no".
What can be done though, is to provide the tool with a version-string like option parameter for OSX CFBundleName/CFBundleDisplayName.

@malept If you feel like not taking any action on this issue, feel free to close it. I can always hack the tool to produce me the desired result, something I rather not prefer doing but if I have no other choice, I will.

[malept]

@JimiC When you omit the name from the packager() options, it uses either productName or name keys in package.json. Perhaps what you want is a more robust version of specifying productName. If so, I will be happy to review a pull request to add this feature, as long as fallbacks (e.g., what happens if productName is not specified but name is) are clearly documented and tested.

[JimiC]

@malept

As you can see in the OP in package.json I declare name and productName (which is used in declaring version-string.ProductName)
If I omit the name then productName gets used but it messes up the containing folder naming, and my O.C.D. doesn't allow that. Just because Apple likes to deviate from what most do, doesn't mean we have to settle for that. (Not saying that Apple does it wrong, I'm saying it does it differently).

Perhaps what you want is a more robust version of specifying productName.

In my case productName is what I want to use for CFBundleName.
I'll try to provide a PR and test it out, in order to meet everyone's liking.

Are you OK if I use the version-string and add OS specific options?
Something like:

 'version-string': {
    win32: {
        CompanyName: packageJson.author.name,
        FileDescription: packageJson.name,
        ProductName: packageJson.productName,
        OriginalFilename: packageJson.name + '.exe'
    },
    darwin: {
        CFBundleName: packageJson.productName
    }
}

In this case if the user doesn't specify the CFBundleName the name will be used.
This structure allows future usage of other attributes.
How does that sounds like?

[erkyrath]

@ JimiC: I think you are confusing the window title name (which appears in the Window taskbar, and also above the menu options) with the app title name (which appears in the Mac menu bar and also in the Mac dock). When you set the name option, the app title will never appear as "Electron", but window titles still default to "Electron".

[erkyrath]

In any case, it sounds like your objection is not the "Electron" column in the above comment, but the use of productName versus name for... hm. I'm still not sure.

My basic position here is "You should use the name argument to set CFBundleDisplayName; that's what it's for." You don't want to do that because the name also appears as the containing folder? Do you mean the one that winds up as NAME-darwin-x64?

[JimiC]

@erkyrath That's the thing on Windows and Linux I can set that to use either name or productName (aka title) but on OSX I'm stuck with using name only.

I want to be able to set CFBundleName to productName.
CFBundleDisplayName using name is just fine for me, but who knows who would like to change that.
What I'm proposing is to add flexibility in setting those attributes on OSX.

Yes, by containing folder I mean NAME-darwin-x64.

[JimiC]

And btw a great example is VS Code which has CFBundleName set to "Code" and CFBundleDisplayName set to "Visual Studio Code". Clear separation of name and productName.

[JimiC]

@malept
Combing through the issues I found #331. My proposal is a good candidate to address that issue too.
We could rename version-string to metadata and have OS specific properties.
Thoughts?

[malept]

I'll put my thoughts in more detail later, but I'd rather have a separate parameter specifically for productName as I think that can be a good cross-platform parameter that encompasses version-string.productName and CFBundleDisplayName.

[JimiC]

According to Apple Developer Docs we should support the assignment of both CFBundleDisplayName and CFBundleName in case of localization.

[JimiC]

@malept Coming back at this. Would you consider using the displayName first and fallback to name for CFBundleDisplayName and CFBundleName?

[durran]

This has another side effect for users who are upgrading electron applications that were built with an older version of electron-packager where the CFBundleExecutable name is set to the application name now and not Electron. (#323) If we could override these properties as well as control the name of the executable we could provide a seamless upgrade path for our users and not make them move or rename the folder. While moving the folder is trivial, many users don't read the release notes before simply draging the new .dmg in the Applications folder and automatically assume everything is corrupt.

[malept]

GIven the current title of the issue summary, I'm resolving this as "by design". I think there should be a separate productName option that sets a human-readable name in the appropriate places.