Xpra: Ticket #2540: add splash screen

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



Sat, 04 Jan 2020 15:24:17 GMT - Antoine Martin: status, summary changed

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.


Thu, 06 Feb 2020 06:33:27 GMT - Antoine Martin: description changed


Fri, 19 Jun 2020 16:43:13 GMT - Antoine Martin: milestone changed

Would help with #2813.

It would be nice if we could show all the steps: server starting, client starting, opengl probing, etc...


Thu, 25 Jun 2020 15:21:47 GMT - Antoine Martin:

Added splash screen in r26803.

Still TODO:


Fri, 26 Jun 2020 09:47:26 GMT - Antoine Martin: status changed; resolution set

Updates:

Works well enough.


Sat, 27 Jun 2020 09:12:33 GMT - Antoine Martin:

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:


Sat, 27 Jun 2020 10:20:50 GMT - Antoine Martin:

macos issues fixed:


Fri, 28 Aug 2020 12:49:55 GMT - Antoine Martin:

Also used when starting servers now: r27332.


Thu, 01 Oct 2020 12:54:21 GMT - Antoine Martin:

Forgot to update the client launcher: r27570.


Tue, 20 Oct 2020 11:05:31 GMT - stdedos:

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.


Tue, 20 Oct 2020 14:23:45 GMT - Antoine Martin:

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


Tue, 20 Oct 2020 17:43:19 GMT - stdedos:

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).

Or, more concretely:

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.


Wed, 21 Oct 2020 08:18:25 GMT - stdedos: attachment set


Thu, 22 Oct 2020 15:17:25 GMT - 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.

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.


Thu, 22 Oct 2020 15:27:31 GMT - stdedos:

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.


Sat, 24 Oct 2020 15:38:07 GMT - Antoine Martin:

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)


Sat, 23 Jan 2021 05:54:02 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2540