Speed up app launch via background emoji loading, progressive UI rendering, and loading state 🚀

[larouxn]

Important

Should merge #120 first as this is built on top of such. This PR's proposed changes are just those in 4bdd993.

What does this PR do?

This PR aims to speed up the launch of Smile from around 2-3 seconds to under a second via offloading emoji loading to a new background process based loader and progressively rendering the massive emoji list via a new batch-based progressive renderer while also adding a loading state to conceal the background loading on slower systems.

ℹ️ Full transparency, I did use LLMs (mainly Claude and a bit of Gemini) to implement the first version of most these changes as I'm both unfamiliar with GTK/Flatpak/etc. and Python¹. That said, I have manually gone through everything several times and iterated as I felt necessary.

¹ More of a Ruby/Rails/web dev myself but I really enjoy this app and GNOME so I'd like to improve it! 🚀

Resolves #114

🎩 Tophatting/checking app 🎩

Before (current app)

Screencast.From.2025-08-10.15-50-57.mp4

After (this PR local build)

Screencast.From.2025-08-10.15-49-58.mp4

🎩 Tophatting/checking loading 🎩

Screencast.From.2025-08-10.17-31-00.mp4

[larouxn]

Even though I know that loading the emoji data in the background is valid approach for making the app startup faster. I am not entirely convinced by the implementation. I think it generally makes sense but it probably could be far simpler, smaller, cleaner. Heck, maybe we don't need background loading at all and some kind of cache could better speed up the app startup in a simpler way. 🤔

While I'm still thinking about this PR, whether it's the right way, I am sure I'd like to get the following much simpler improvements merged whenever possible, pending review of course.

• Clean up whitespace and trailing spaces #120
• Add ctrl+q shortcut to quit the app as per GNOME convention  #122
• Fix 0.55.0: {'ExternalProgram.path'} deprecated feature warning #123
• Update README to state correct required GNOME packages, from 44 to 48 #124
• Require Meson >= v1.0.0 for long term project health #125

[larouxn]

Update re: above, I tried a simpler caching based approach but the checking of cache validity actually made it slower than master. I then proceeded to benchmark this branch. It did prove faster:

• master took 3 seconds to launch
• this branch took 2.5 seconds to launch

But I don't think 0.5 seconds speedup is worth the added complexity introduced by this PR. If it got launch to under 1 second, perhaps, but not 2.5 down from 3. Thus, closing this PR.

[mijorus]

@larouxn I have already tried many tricks to speed up the app launch, including using a sqlite database instead of a python List. Unfortunately, most of this stuff just adds complexity, the biggest slowdown is the startup of the Flatpak environment

[enessmr]

Flatpaks are bloaty, this is the reason that this is like 🐌🐌🐌.

[Piripe]

@larouxn I have already tried many tricks to speed up the app launch, including using a sqlite database instead of a python List. Unfortunately, most of this stuff just adds complexity, the biggest slowdown is the startup of the Flatpak environment

I'm using the AUR package and it's taking 1~2s to open.
The right solution may be to rewrite the entire program in a lower level language like C(++), Rust or Go, but I'm not sure about that, it's only speculation.