When packaging an app (typically for anything graphical) we are often using remote parts … each of these parts comes with a wrapper … i.e. I recently packaged a kiosk browser app (but this is also an issue for many of our desktop apps)…
When wanting to use fonts and a toolkit in your app you will include one of the desktop remote parts, inclusive its launcher … now … when my app wants to also support sound i’ll include the alsa remote part … again inclusive an added launcher … and since my app is a kiosk app using X i’ll also need to include the Xwayland launcher.
This means my app launches three shells in succession, each of them doing some processing, setting some variables etc and in the end spawns my own shell wrapper to set the app specific bits up … this behaviour has definitely impact to application statup time and i’m writing this post to trigger some discussion how we can improve this area beyond stacking more and more shell scripts on top of each other … any ideas are welcome here …
Note that this will get “prettier” soon due to snapd’s support for command-chain (coming in 2.36) but it doesn’t actually change the core issue: several processes are required before the final app launches (ignoring snap run and snap-exec, so there are multiple other processes as well). Unfortunately, I’m not sure there’s a better solution. Even running a shell and sourcing before running the app is multiple processes. Even putting everything into snapd’s environment keyword doesn’t solve it, since it doesn’t support actually running stuff like the desktop helpers need to do. Basically: if you have logic that needs to run, like the desktop helpers do, it has to run somewhere. We can make it easier to do and nicer to look at, but the multiple processes will still be there.
it isnt only that, i bet if we look closer there are probably even code duplications and redefining of env vars that were defined differently in a former wrapper (i.e. i’m pretty sure font env vars are defined in desktop-launch as well as in the xwayland wrapper since you could also use each of them standalone) … eventually this will cause havoc because the order in which you put these wrappers starts to give you different results.
