We recently modified the macOS template to provide a stub app - a small binary executable that is used as an entry point for the app, which is responsible for starting the Python interpreter.
This has a number of benefits:
- The app appears in the process monitor with the app name and icon, rather than "python" or a shell file
- The app that is started is the same one that is granted permissions by the operating system, rather than needing to fork a process
- It provides a hook to catch high-level app failures, such as a fail on start due to import errors. If the app fails, we can catch the failure and show a crash dialog.
- It provides a hook for installing logging and other system-level handlers.
Describe the solution you'd like
The briefcase-linux-appimage-template should be modified to contain a stub app that behaves in a similar way to the macOS app template, showing a dialog if the Python code crashes.
This will involve writing a small C app in GTK that starts the Python interpreter. The implementation in the macOS template will be a useful reference; although that code is Objective C, and uses the Cocoa APIs, the structure of code needed to start the Python interpreter will be largely the same.
The macOS template has 2 versions - a pre-built version where the binary is copied and renamed as needed; and an "Xcode project" version where the user can modify the app if they wish. In the context of Linux, it should be acceptable to just use the "project" version, because it's easy to get the compiler toolchain in place. However, we need to document those extra system requirements, and add them to the Docker build environment.
We recently modified the macOS template to provide a stub app - a small binary executable that is used as an entry point for the app, which is responsible for starting the Python interpreter.
This has a number of benefits:
Describe the solution you'd like
The briefcase-linux-appimage-template should be modified to contain a stub app that behaves in a similar way to the macOS app template, showing a dialog if the Python code crashes.
This will involve writing a small C app in GTK that starts the Python interpreter. The implementation in the macOS template will be a useful reference; although that code is Objective C, and uses the Cocoa APIs, the structure of code needed to start the Python interpreter will be largely the same.
The macOS template has 2 versions - a pre-built version where the binary is copied and renamed as needed; and an "Xcode project" version where the user can modify the app if they wish. In the context of Linux, it should be acceptable to just use the "project" version, because it's easy to get the compiler toolchain in place. However, we need to document those extra system requirements, and add them to the Docker build environment.