Similar to what happens with the html5 client: we can use this to show progress, from initialization, testing opengl, opening the network connection, authenticating, etc.. Then the window can be faded out.
See also #2571
The opengl probe should still be done in a different subprocess so that we can handle crashes gracefully.
We can keep the splash screen running until we get the "first-ui-event" (ie: first window shown on screen), or just until we are connected.
Would help with #2813.
It would be nice if we could show all the steps: server starting, client starting, opengl probing, etc...
Added splash screen in r26803.
Still TODO:
xpra start --attach=yes ssh://host/
- we should wait for the hello
packet rather than hiding the splash screen as soon as we have established the ssh connection, as starting the server and connecting to it may still take quite a bit of time to complete
Updates:
connection established
or authentication
as we fade out the splash window
Works well enough.
One problem: on macos, we have a "nodock" app bundle that uses LSUIElement=true
to suppress the dock icon when running the audio subprocess, but this does not work for GTK, probably because GTK uses kProcessTransformToForegroundApplication.
It might work if here), but this would require patching GTK..
Maybe setActivationPolicy can do this?
Links:
macos issues fixed:
POPUP
window, disable "startup notification"
Also used when starting servers now: r27332.
Forgot to update the client launcher: r27570.
btw - are you planning to add some UI "magic" to increment the progress bar between stages?
That, and/or a spin-loading cursor might help give the impression to the user that the client is actually waiting doing something, and it is not e.g. frozen.
I understand that this is a "close equivalent" to the terminal output, but UIs are "different kind of logic" and have different things to be expected from them.
btw - are you planning to add some UI "magic" to increment the progress bar between stages?
We already do that.
That, and/or a spin-loading cursor might help give the impression to the user that the client is actually waiting doing something, and it is not e.g. frozen.
Done in r27720
Replying to Antoine Martin:
btw - are you planning to add some UI "magic" to increment the progress bar between stages?
We already do that.
Again I managed to not explain myself fully :-p.
I mean that, while waiting to go from e.g. 20% to 30% (arbitrary), make it increment 0.5-1-2% per second (as appropriate to what "on average" a state is expected to take), to "fake" progress (but not mask real progress).
Progress bar in this state does not progress at all.
Or: there are some ways that progress bars "blink" when no progress is made to show interactivity: some light goes through the edges of the progress continuously (or that a small bar itself rolls around the progress bar space, but I think that one is for progress bars that don't depict a percentage).
Ofc, the spinner update beta hasn't landed; maybe it's good enough.
I mean that, while waiting to go from e.g. 20% to 30% (arbitrary), make it increment 0.5-1-2% per second (as appropriate to what "on average" a state is expected to take), to "fake" progress (but not mask real progress).
That's exactly what we were doing already, now changed to increase gradually more slowly so we don't reach "29%" too quickly.
Or: there are some ways that progress bars "blink" when no progress is made to show interactivity
The one in GTK isn't useful, hence the new UTF spinners.
Ofc, the spinner update beta hasn't landed; maybe it's good enough.
There is definitely a new build there now. Prior to that, it might have been just client-only builds - FYI: these are the ones you want if you don't intend to run the xpra server on mswindows: they're smaller.
Replying to Antoine Martin:
I mean that, while waiting to go from e.g. 20% to 30% (arbitrary), make it increment 0.5-1-2% per second (as appropriate to what "on average" a state is expected to take), to "fake" progress (but not mask real progress).
That's exactly what we were doing already, now changed to increase gradually more slowly so we don't reach "29%" too quickly.
I didn't see interactivity on the moment depicted by the image I uploaded, and I waited enough for it. Maybe it was just me or it was intentional (server waiting for the ssh password is arbitrary)
Ofc, the spinner update beta hasn't landed; maybe it's good enough.
There is definitely a new build there now. Prior to that, it might have been just client-only builds - FYI: these are the ones you want if you don't intend to run the xpra server on mswindows: they're smaller.
These are my kind of builds; however, it looks to me that you haven't been building them much these days. I really don't want to bitch about having them all the time, when it's your time, effort (and money probably). I am just happy that beta builds keep rolling every ~50 changesets or so.
The splash screen causes some really strange problems with the server when running daemonized (console warnings, unresponsive, etc), so r27757 turns it off. (it would be interesting to know what causes this - but I don't have the time)
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2540