xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.


Opened 22 months ago

Closed 16 months ago

Last modified 9 months ago

#2540 closed enhancement (fixed)

add splash screen

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: major Milestone: 4.1
Component: client Version: 3.0.x
Keywords: Cc:

Description (last modified by Antoine Martin)

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

Attachments (1)

Plink_2020-10-21_11-17-20.png (51.1 KB) - added by stdedos 12 months ago.

Download all attachments as: .zip

Change History (17)

comment:1 Changed 22 months ago by Antoine Martin

Status: newassigned
Summary: use opengl probe as splash screenadd splash screen

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.

comment:2 Changed 21 months ago by Antoine Martin

Description: modified (diff)

comment:3 Changed 16 months ago by Antoine Martin

Milestone: 4.04.1

Would help with #2813.

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

comment:4 Changed 16 months ago by Antoine Martin

Added splash screen in r26803.

Still TODO:

  • test on other platforms
  • with 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

comment:5 Changed 16 months ago by Antoine Martin

Resolution: fixed
Status: assignedclosed

Updates:

  • r26805 use threads, works on win32
  • r26810 show connection established or authentication as we fade out the splash window
  • r26811 add more steps for remote server starts
  • r26812 ignore pipe errors
  • r26813 fake gradual progress during events

Works well enough.

comment:6 Changed 16 months ago by 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 kProcessTransformToUIElementApplication was used instead (hint found here), but this would require patching GTK..

Maybe setActivationPolicy can do this?

Links:

comment:7 Changed 16 months ago by Antoine Martin

macos issues fixed:

  • r26814 POPUP window, disable "startup notification"
  • r26817 cosmetic
  • r26818 force focus on macos
  • r26819 hide macos dock (it shows up very briefly)

comment:8 Changed 14 months ago by Antoine Martin

Also used when starting servers now: r27332.

comment:9 Changed 13 months ago by Antoine Martin

Forgot to update the client launcher: r27570.

comment:10 Changed 12 months ago by 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.

comment:11 Changed 12 months ago by 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

comment:12 in reply to:  11 Changed 12 months ago by 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.

Last edited 12 months ago by stdedos (previous) (diff)

Changed 12 months ago by stdedos

comment:13 Changed 12 months ago by 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.

comment:14 in reply to:  13 Changed 12 months ago by 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.

comment:15 Changed 12 months ago by 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)

comment:16 Changed 9 months ago by migration script

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

Note: See TracTickets for help on using tickets.