You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently, like many Flutter desktop applications, AppFlowy might show a blank screen or a slight delay before the main UI appears, especially on slower systems or during the initial Flutter engine warmup. This can sometimes feel a bit janky or give the impression the app is slow to start.
Describe the solution you'd like
I propose implementing native splash screens for Linux, Windows, and macOS. A native splash screen would:
Display an immediate visual (e.g., a logo or simple loading indicator) as soon as the user launches the application.
Remain visible while the Flutter engine initializes and the Dart application loads.
Transition smoothly to the main application UI once Flutter has rendered its first frame or essential app initialization is complete.
This can be achieved using a plugin like native_splash_screen which handles platform-specific implementations (GTK/Cairo for Linux, Win32 GDI for Windows, AppKit for macOS) and allows for compile-time configuration of the splash screen's appearance.
Describe alternatives you've considered
The current alternative is the standard Flutter startup, which can sometimes involve a brief delay or white screen before the first Flutter frame. While Flutter has ways to manage initial routes and loading states within Dart, a true native splash offers an even earlier visual.
Impact
all the desktop app users.
Additional Context
Implementing native splash screens would provide a more polished and professional startup experience, reducing perceived latency and improving overall UX.
I'm willing to work on implementing this feature. I've already experimented with the native_splash_screen package and believe it can be integrated effectively. The primary challenge would be ensuring the custom build environment of AppFlowy accommodates the platform-specific setup steps for each native platform.
Would the AppFlowy team be open to a contribution for this feature? Any initial guidance or considerations regarding AppFlowy's build process would be appreciated.
The text was updated successfully, but these errors were encountered:
Description
Is your feature request related to a problem? Please describe.
Currently, like many Flutter desktop applications, AppFlowy might show a blank screen or a slight delay before the main UI appears, especially on slower systems or during the initial Flutter engine warmup. This can sometimes feel a bit janky or give the impression the app is slow to start.
Describe the solution you'd like
I propose implementing native splash screens for Linux, Windows, and macOS. A native splash screen would:
This can be achieved using a plugin like
native_splash_screen
which handles platform-specific implementations (GTK/Cairo for Linux, Win32 GDI for Windows, AppKit for macOS) and allows for compile-time configuration of the splash screen's appearance.Describe alternatives you've considered
The current alternative is the standard Flutter startup, which can sometimes involve a brief delay or white screen before the first Flutter frame. While Flutter has ways to manage initial routes and loading states within Dart, a true native splash offers an even earlier visual.
Impact
all the desktop app users.
Additional Context
Implementing native splash screens would provide a more polished and professional startup experience, reducing perceived latency and improving overall UX.
I'm willing to work on implementing this feature. I've already experimented with the
native_splash_screen
package and believe it can be integrated effectively. The primary challenge would be ensuring the custom build environment of AppFlowy accommodates the platform-specific setup steps for each native platform.Would the AppFlowy team be open to a contribution for this feature? Any initial guidance or considerations regarding AppFlowy's build process would be appreciated.
The text was updated successfully, but these errors were encountered: