There might be a reason it works like this - if so you can just ignore this, it's not really a big deal.
Regarding the preferences index generation (which happens for a few seconds the first time you search for a setting after updating), while it's short enough to not really be an annoyance, it's always a bit unexpected, and perhaps the mildest-possible tier of nuissance.
I wonder if it wouldn't be difficult to move the generation to the end of the installer where a few more seconds probably wouldn't be noticed, and the user is already expecting a wait. Not sure if it relies on runtime data though.
The index is built within Preferences from the actual dialog resources; the reason it takes a few seconds is every single dialog page has to be created in the background before it can be added to the index. So currently Opus (and Preferences) has to be running. Not easily done from the installer unfortunately.
Preferences are not dynamic in that they change during operational usage (the settings, not the values connected to them) - therefore it is possible to pre-build the index and include in the install package ?
What about some background task when first launching Opus after an update (even delayed so it does not impact launch time)?
This would probably be unnoticed since most users (probably) don't go straight to Preferences when opening Opus. And in case they do, they could get the current message saying index is being rebuilt.
Something like that could work, but also needs to be done carefully, and has a bunch of potential complications or potential annoyances that would outweigh the convenience if anything went wrong (e.g. getting stuck in a crash/restart loop if something on one of the 100s of Preferences pages crashes on a particular system/config, as well as things like not wanting to build the index right after boot when lots of things need the CPU).
I like the idea but I think it will turn out to be more complex than it looks. It's something we might play with over time.
Opus could run this routine after detecting a bit of idle time. However, it's really only relevant for beta testers, who frequently install new versions. Regular users average one update per month, so saving a few seconds of delay might not justify the effort or potential risk.
. It should also be generated when switching between languages.
Preferences are not dynamic in that they change during operational usage (the settings, not the values connected to them) - therefore it is possible to pre-build the index and include in the install package ?