xsplash should support UNR in netbook-launcher mode

[David Barth]

xsplash should fade out and reveal the user session without relying on the timeout in UNR. More specifically, when the user session is in netbook-launcher mode. In classic desktop mode (ie vanilla gnome-session) xsplash should already work correctly on UNR.

Design trap: if xsplash needs to wait for an extra signal from netbook-launcher, then it needs to know in advance whether the user session is running in classic or launcher mode.

[Neil J. Patel (njpatel)]

Cody and I have discussed possible ways in which Xsplash could be made aware of the need to wait for netbook-launcher to signal it's ready on UNR systems.

As UNR shares the same packages as the desktop (i.e. we can't make unr-specific changes to packages), the possibility of having a 'unr build' of xsplash doesn't work.

Instead of that, we have discussed having a /etc/xsplash.conf file which contains a very simple CSV list of applications xsplash should expect to receive 'ready' signals from before fading out. The UNR distribution could easy add this file to ubuntu-netbook-remix-default-settings, and it would contain something like "gnome-panel,nautilus,netbook-launcher".

I think this would also help other spins such as Kubuntu/Xubuntu as and when they support xsplash. If no file exists, then xsplash can assume "gnome-panel,nautilus", so no changes need to be made to the desktop spin.

Another concern was disk-activity while trying to access the file affected start-up time of xsplash, but the reading of the file can happen at the gdm stage rather than the startup stage, and therefore wouldn't effect the startup time of xsplash.

[Loïc Minier (lool)]

Problem is that this is system wide, but you might have e.g. GNOME and UNR on the same system and be choosing between the two on the GDM screen.

This is not particularly well supported right now since we override the GConf defaults system wide for instance but let's not make this worse.

We could set this in Xsession.d code; for instance a GNOME session would be detected in /etc/X11/Xsession.d scripts and we would signal to xsplash via DBus that we expect gnome-panel and nautilus to signal session readiness. On Xubuntu these would be different and on UNR, until we can distringuish the two types sessions (perhaps by having a different GDM .desktop file?) we'd simply add another Xsession.d file which would add to the list of apps to watch for. If the list is empty, we'd tell that xsplash too, and it would be a fallback which causes xsplash to switch immediately to the Xorg VT and show whatever is being started.

[Loïc Minier (lool)]

So to be clear, I propose adding a /etc/X11/Xsession.d/55gnome-session_xsplash with XSPLASH_WAITFOR+=nautilus gnome-panel, a 55unr-session_xsplash with XSPLASH_WAITFOR+=netbook-launcher, and to call dbus-send xsplash WaitForTheseAppsToSignal $XSPLASH_WAITFOR in /etc/X11/Xsession.d/99xsplash.

Thoughts?

[Cody Russell (bratsche)]

So xsplash could just pick it up from the environment? That sounds like a better idea than what we were thinking of, which was to read some xsplash.conf file somewhere.

[Cody Russell (bratsche)]

"call dbus-send xsplash WaitForTheseAppsToSignal $XSPLASH_WAITFOR in /etc/X11/Xsession.d/99xsplash"

I'm not really sure what this part of your comment is about. xsplash right now is started by /etc/gdm/Init/Default and /etc/gdm/Init/PreSession. Could it still pick up the $XSPLASH_WAITFOR in this way?

[Loïc Minier (lool)]

Well the way we IPC to signal xsplash is open to discussion; I was under the impression system dbus was on the table which seemed fine to me.

What I understand happens:
- gdm starts up
- gdm startup scripts bring up xsplash which renders on a Xorg server started by gdm of which it starts itself (not sure)
what I propose happens next:
- gdm starts an user session as usual and the session scripts tell xsplash which components it should wait for

[Cody Russell (bratsche)]

Right now we have nautilus and gnome-panel patched to send the signals once they're finished loading. Ideally we'd rather be doing it from gnome-session I think, but this can be changed later.

[Cody Russell (bratsche)]

If you set the environment from /etc/X11/Xsession then is it setting the environment for root user or for gdm user? Because xsplash is running as gdm user.

[Loïc Minier (lool)]

I'm not suggesting setting an env var in Xsession.d which xsplash could read. The environment var is just a shell var which Xsession.d scripts share as to accumulate a list of processes to wait for; at the end of the Xsession.d sequence, some IPC like for instance dbus sends this list to the running xsplash. That is a shell script calls dbus-send towards the system bus to talk to xsplash.

Does that make sense? Otherwise let us have a quick phone call about it

[Cody Russell (bratsche)]

I don't think this can work, because there is no way for the shell script to know when to dbus-send the signals.

Right now we have some patches in gnome-panel and Nautilus that were done by Robert Ancell. They determine at what point in the application it is considered to be ready.. for example, I think in gnome-panel it's once all the applets have been displayed it considers itself to be loaded.

A shell script would just be able to tell when the applications have been launched.. if you launch gnome-panel and Nautilus and then dbus-send the signal, this will be too early since the apps will still be loading.

[Cody Russell (bratsche)]

I asked Scott if it's okay to read the signals from a conf directory and he said that's fine, so I'm committing my branch to do that now.

[Loïc Minier (lool)]

The shell script wouldn't be signaling that apps have loaded, it would be signaling which apps to wait for!

So on a gnome-session, just before running gnome-session itself we would tell xsplash to expect signal from nautilus and gnome-panel.

On a xfce-session, it would be thunar and xfce-panel or something.

[Cody Russell (bratsche)]

Oh, I get it now. Makes sense.

I already implemented something that just looks at what files are in /etc/xsplash and uses those signals. It doesn't actually read the file contents, just the filenames in that directory. So with this branch gnome-panel would just install a file called /etc/xsplash/gnome-panel, etc for other applications. Then xsplash would wait until it's received a "gnome-panel" signal.

We'll wait until after alpha5 for this, since it will obviously involve changing packages for gnome-panel, nautilus, and netbook-launcher.

[Kai Jauch (kaijauch)]

@Cody:
That would only work if only one kind of session (gnome, kde, xfce, ...) is ever started on a machine. If you have one user using kde and another one using gnome, the read-files-and-wait-for-those-signals-approach doesn't work (if I understood you correctly).
Loïc Minier's approach is dynamic, per-session-oriented. It determines what kind of session (gnome, kde, xfce, ...) is actually being started and tells xsplash what signals to wait for _this time_.