I've also had this issue, even though my computer is relatively high-spec. Skipping or hiding the "Loading Vesktop" splash, or just making it not force the main window to focus when it's done would be a lot less annoying.

#384 (comment)

@Maritsu, if you're using cpe:/a:kde:plasma:5 with the default KWin WM, importing

[KWinRuleset]
fpplevel=3
fpplevelrule=2
fsplevel=3
fsplevelrule=2
wmclasscomplete=true

(see https://github.com/Vencord/Vesktop/files/14562853/KWinRuleset.kwinrule.zip) into kcmshell5 kcm_kwinrules should prevent this from being problematic anymore.

#384 (comment)

@Maritsu, if you're using cpe:/a:kde:plasma:5 with the default KWin WM, importing

[KWinRuleset]
fpplevel=3
fpplevelrule=2
fsplevel=3
fsplevelrule=2
wmclasscomplete=true

(see https://github.com/Vencord/Vesktop/files/14562853/KWinRuleset.kwinrule.zip) into kcmshell5 kcm_kwinrules should prevent this from being problematic anymore.

Thanks for the tip! However I use DWM, so this might not be of use to me; though I do hope any KWin users that stumble upon this find this useful!

stop leaving these spam comments. if you agree, leave a thumbs up, commenting "omg i need this too" just adds noise

or just making it not force the main window to focus when it's done

Yep, this is the troubling behaviour from vesktop - it requests focus twice. Once for the splash screen, and again for the main window. That is the cause of the problem OP describes. The splash screen is given focus by running the application. The main window is given focus without user interaction even if the splash screen does not have it.

If you have a WM which has focus stealing prevention, such as kwin, you can see that if you do prevent vesktop from stealing focus, start it, thus giving the splash screen focus, then switch focus to another app, it will still restore the main window's size, and it will be the front window, but not the active one. Like, you will see vesktop maximised like it was before, but the window that was active before, will still be active, you can see in your taskbar, and if you type, you type into that app behind vesktop, not the vesktop window you are looking at.

So.... Hiding the splash screen won't solve OP's problem. They could still start vesktop, switch to another app during the wait time, and have focus stolen by the main window.

Even if focus stealing is fixed (by: only hand off focus to the main window, if the splash screen already (and still) has focus) then there is also the problem with the restoring the window geometry over the top of other windows. Sorry!

Describe alternatives you've considered
Hiding the splash window instead of disabling it

Also wouldn't help, sorry!

Opening the main window immediately and displaying the loading animation inside it

I don't know vesktop's source well, but If this is anything like the Discord client, that splash window is (in layman's terms) a separate program that's downloading the actual main program and running it. So that couldn't work because the main window doesn't exist yet. Hopefully this is different...?

the splash doesn't actually serve any purpose, it's just placeholder ui, and can easily be disabled/removed

the reason it exists is that there are two alternatives, both of which suck:

1. show no splash at all, which will make the app seem unresponsive / like it hasn't opened
2. show the browser window immediately; at this point it will be a full white screen

I agree. 1) sucks because a user might think it's broken, try to kill it. etc... 2) sucks because "ow my eyes!". Seems like a splash screen is required here. What a surprise, I bet you didn't know that :D (joking)

I Imagine that even if you are able to find a way to launch the main window without the white, and skip the splash screen, some people will still prefer the splash screen. It would be nice to fix this for them, too. I am a boring old man, I don't know what a shiggy is, but I sure know ppl around here like one!

I guess the trick then, is to ensure we do not give focus/activity to the main window, if the splash screen does not have focus. (but do, if it does - as things are now). That way a user can start the app, see the splash, alt+tab to something else, and not have stolen focus when the main window is ready.

Also, finding a means to avoid the obstructive geometry (as in, if the splash screen isn't in front, don't draw the main window at the front)

No pressure from me, if you fix it some way that I can turn off the shiggy I probably will. It doesn't gel with my crusty old luddite persona. I just thought some other people might also see the problem OP described and want a fix that lets them keep their shiggy.
I've just been spectator to a fellow developer with similar window management hurdles in a tauri app. It's never simple. Good luck!

is https://www.electronjs.org/docs/latest/api/browser-window/#setting-the-backgroundcolor-property not the solution for the startup flashbang?

If you are using Hyprland, a temporary solution is to use a windowrule to hide the vesktop splash

Hyprland.conf:
windowrule = opacity 0.0 override,title:^(vesktop)$

You may see the shadow of the window for >=200ms but the window will be hidden

Thanks for the tip there Axel living up to your name. Here's a KDE approximation of this concept

Exported the above to a rule you can import from the GUI, github doesn't like the extension so I added .txt.

vesktop-hide-splash.kwinrule.txt

If you are using Hyprland, a temporary solution is to use a windowrule to hide the vesktop splash

Hyprland.conf:
windowrule = opacity 0.0 override,title:^(vesktop)$

You may see the shadow of the window for >=200ms but the window will be hidden

I use DWM, but I'll poke around and maybe get something similar to work.