Closed mouadessalim closed 7 months ago
Pyinstaller used underground by flet pack
has an option for splash screen.
But, I am just from reading here that this is not available for MacOS-packaged apps. 😕
Indeed, PyInstaller doesn't allow the use of a splash screen on macOS. However, this is more of a limitation imposed by the operating system rather than the library itself. This consistently keeps the issue at hand. Supporting 'flet pack' on macOS is objectively feasible, but it will never be utilized due to its startup time, especially the fact that creating a thread on which flet
runs makes it much more complex for compilers to comprehend (as they are generally based solely on the Main Thread).
For the moment, desktop-app-packaging is done with pyinstaller. But, if not mistaken, we would at some point move to using Flutter itself for the app packaging.
Great idea, that's exactly what I had in mind ! Being able to build our projects with the Flutter SDK will make things much simpler. Now, the problem might be compatibility limitations with Python. Creating the frontend with Flutter SDK and the backend with PyInstaller, all communicating through APIs, sounds like a plan !
Yes, unified packaging through a Flutter app (flet
and serious_python
packages) is the #1 item right now: https://flet.dev/roadmap#september-2023---january-2024
I just finished refactoring of serious_python
into federated plugin, so other platforms could be easily added https://github.com/flet-dev/serious-python/tree/main/src
Next step is adding macOS support and then I'm going to release a "beta" of project template.
Nicely done, your idea had already crossed my mind. So if I understand correctly, you're delving into two areas: the possibility of incorporating Python into a Dart Flutter project and the creation of Python applications using the Flutter framework.
I now have a better grasp of how Flet operates. Does Flet generate a Flutter application template and utilize serious_python
to execute our backend logic?
Does Flet generate a Flutter application template and utilize serious_python to execute our backend logic?
That's the exactly the idea! We are going to do it via flet create --template={X}
command, which is available today, but doesn't have a template yet.
...or template creation could be added as a first step inside flet pack
command (as I'm not sure there is a benefit of keeping that "transient" Flutter app around), so the entire sequence would be:
Related issue: https://github.com/flet-dev/flet/issues/2139
Try the new packaging method with flet build
.
The
flet pack
tool, used for distributing Flet apps, functions efficiently across various platforms, including macOS. However, there is an issue concerning the user experience on macOS. Currently, when launching a Flet app packed with 'flet pack' on macOS, it appears to create an additional process alongside the main application process in the background which create a false crash-like. This behavior impacts the professionalism and user-friendliness of Flet apps on macOS, leading to confusion and potential concerns among users.Proposed Solutions :
Resolve macOS Bug : One approach to enhance the user experience on macOS is to address the issue causing the additional process to run alongside the main application. This bug can be investigated and resolved to ensure that Flet apps on macOS start smoothly, similar to their Windows counterparts. This would significantly improve the professionalism and reliability of Flet apps on macOS.
Explore Alternative Python Compilers for macOS : Another potential solution is to investigate the possibility of using alternative Python compilers such as Nuitka, CxFreeze, or others that might offer better compatibility and performance on macOS. Experimenting with different compilers could help identify one that eliminates the issue with the additional process and ensures a seamless experience for macOS users.
Implement a Splash Screen or Error Message : To provide users with a more professional and informative experience, consider implementing a splash screen or a user-friendly error message when the additional process is created during app startup on macOS. This message can reassure users that the app has not crashed and is functioning as expected, thereby improving the overall user experience.