Add file associations for Windows applications

[davidfokkema]

This PR adds file associations to Windows apps. The support in briefcase.toml is already there and the feature is documented. It wasn't yet implemented for Windows, however.

Refs beeware/briefcase#1706 (corrects the problem for Windows).

I tested with https://github.com/davidfokkema/helloworld. This repository may be removed when the PR is merged. The relevant sections of pyproject.toml are:

[tool.briefcase.app.helloworld.document_type.project]
description = "Hello Project File"
extension = "hpf"
icon = "resources/document"
url = "https://example.com"

[tool.briefcase.app.helloworld.document_type.data]
description = "Hello Data File"
extension = "hda"
icon = "resources/document-data"
url = "https://example.com"

with the resources folder containing the icons inside the module. So, relative to the repository root, the icons are located in src/helloworld/resources. This makes them easy to reach from the .wxs file via the ROOTDIR and then src\app\helloworld\resources. This differs from the repository layout where they are at src/helloworld/resources, so without the app in between. For Windows, I think this is now solved cleanly. However, on macOS, I believe the icon paths were relative to the repository root. I may want to propose to change that when I'm working on that PR.

What is left to do: if we want to change the icon path, we should document that.

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[davidfokkema]

Still working on it, will check off all the boxes.

[davidfokkema]

To test the functionality of this PR, add this to your project settings in your pyproject.toml:

[tool.briefcase.app.your_app_name]
template = "https://github.com/davidfokkema/briefcase-windows-app-template"
template_branch = "file-associations"

[fedelibre]

@davidfokkema I did a quick test here and it's failing, apparently because of the directory separator character's discrepancy:

Compiling... done
Linking application installer...
Linking... started
D:\a\frescobaldi\frescobaldi\build\frescobaldi\windows\app\frescobaldi.wxs(79) : error LGHT0103 : The system cannot find the file 'src\app\frescobaldi\frescobaldi/icons/org.frescobaldi.Frescobaldi.ico'.
D:\a\frescobaldi\frescobaldi\build\frescobaldi\windows\app\frescobaldi.wxs(86) : error LGHT0103 : The system cannot find the file 'src\app\frescobaldi\frescobaldi/icons/org.frescobaldi.Frescobaldi.ico'.
Linking... errored

Unable to link app frescobaldi.
Saving log... started

Log saved to D:\a\frescobaldi\frescobaldi\logs\briefcase.2025_02_11-22_48_28.package.log

Saving log... done

[freakboy3742]

Looks good; a couple of comments inline about improvements to MIME and icon handling, plus one escaping issue.

[davidfokkema]

@davidfokkema I did a quick test here and it's failing, apparently because of the directory separator character's discrepancy:

The directory separator was not the issue. Currently, the icon needs to be specified relative to the sources module, in your case 'frescobaldi'. This diff of pyproject.toml fixes the icon issue:

 [tool.briefcase.app.frescobaldi.document_type.ly]
 description = "LilyPond file"
 extension = "ly"
-icon = "frescobaldi/icons/org.frescobaldi.Frescobaldi"
+icon = "icons/org.frescobaldi.Frescobaldi"
 url = "https://lilypond.org/"

 [tool.briefcase.app.frescobaldi.document_type.ily]
 description = "LilyPond included file"
 extension = "ily"
-icon = "frescobaldi/icons/org.frescobaldi.Frescobaldi"
+icon = "icons/org.frescobaldi.Frescobaldi2"
 url = "https://lilypond.org/"

However, it complained that a GUID is reused. On a hunch, since my test repo uses two different icons for the two document types, I copied the icon and named it org.frescobaldi.Frescobaldi2 (see the diff above) and on my machine, it created a nice .msi. I will look into the GUID issue, maybe there is an easy fix but I guess it just won't work with the same icon since two "components" in the installer are re-using the same file. I think the icons really need to be different, which is not that unusual if you define different document types, but I understand why you reused the icon.

[davidfokkema]

Mind that specifying the location of the icon this way will probably change after I implemented @freakboy3742's suggestions.

[davidfokkema]

@fedelibre with the current changes to the template, copying the same icon into the build directory, there is no longer any need to change your briefcase.toml. So the run that failed, should succeed now unchanged.

[fedelibre]

Thanks, I've rerun the job and the build completed successfully. I'll test the .msi file on Windows when I have time.

[freakboy3742]

Looks great - and works great in my testing as well. 2 comments inline, one of which comes with a fix that I'd like someone other than me to validate works - but if it does, I think this is good to go!

[davidfokkema]

The mime_type fix works for me! Without that declaration I get application/x-appname-doctype and with the declaration I get the mime type that is specified in the pyproject.toml section. Thanks!

[davidfokkema]

When this is merged, how would I best go about including it in the visualstudio template? As a single commit including the same changes by copying over the new files? Or somehow pulling in the different commits?

[freakboy3742]

Awesome - thanks for these fixes!

Regarding the VisualStudio analog - a single commit making this set of change on that repo would be great.

One final minor housekeeping note - I've tweaked the PR description slightly, because the text "Fixes #xxx on windows" contains the magic words "Fixes #X", which Github will use to close the referenced ticket - the human readable qualifier won't be taken into consideration. In this case the issue won't be completely fixed, so we need to use "Refs #xxx" instead.

[davidfokkema]

One final minor housekeeping note - I've tweaked the PR description slightly, because the text "Fixes #xxx on windows" contains the magic words "Fixes #X", which Github will use to close the referenced ticket - the human readable qualifier won't be taken into consideration. In this case the issue won't be completely fixed, so we need to use "Refs #xxx" instead.

Darn, didn't think of that. Thanks for the housekeeping. And for accepting my PR, of course!