Please support running a "first run" app

[agx]

When the user first boots the device (and no user exists yet) it would be nice to be able to (optionally) run a "first run" app fullscreen before the initial user selection is shown. This would allow to set up a default user / pin, etc.

Phrog could spawn that app before it shows the PhoshLockscreen.

(The first run app could e.g. be gnome-initial-setup in it's system mode but which app it is likely doesn't matter for phrog).

I'm a bit fuzzy how we deal with permissions yet as we'd e.g. need polkit configuration that would allow the greetd user to create other users via accountsservice.

[samcday]

This sounds very interesting indeed. I imagine this would be a big help towards producing a generic image that can be "installed" (customized) on first boot. Aside from the phrog bits, I imagine there would be a lot of distro-specific work to achieve something like this.

What mechanism do you think would be best for this? I think it should probably just be some GSettings properties. If com.samcday.phrog.firstrun-execute is set with a string array for exec+args, then it boots directly into this instead of the lockscreen.

What if first-run process fails in some way? Should phrog be responsible for clearing the firstrun-execute prop when it has launched said process? Or should that responsibility lie elsewhere?

[agx]

I imagine this would be a big help towards producing a generic image that can be "installed" (customized) on first boot.

Yes, that would be really nice. The current way is to run gnome-initial-setup after the first login but that requires that the user knows the initial PIN and usually can't customize the user name upfront.

What mechanism do you think would be best for this? I

An initial naive approach could be: Run the "first run app" every time and let it decide whether it finished successfully (at the cost of maybe slightly slower startup). That would shift the responsibility out of phrog.

gnome-initial-setup used to work that way by exiting early when it found a file in the file system (it ran successfully already).

[samcday]

I'm gonna try hacking up an initial branch for this soon. I think it's gonna need some upstream Phosh changes.

We need a bit more control over the home widget of PhoshShell, I think. We ought to disable the default PhoshHome entirely - I can't think of any scenario where we want to present a user with a list of apps available to the greeter ;)

So in the case that a first-run app is configured, we don't lock on startup, and instead spawn the desired app. Once we detect the spawned app has exited we force the shell to be locked.

I'm a bit hazy on the specifics around this point. In particular, it'd be neat to hold the initial shell reveal until either a) the first-run app has loaded and signalled that its done its first paint b) a spinner tracking the app load has painted or c) a combination of the above? (wait for app first paint for N secs and then fall back to fading in the spinner)

[agx]

I see to ways:

1. Leave phosh out this

like:

• if first run: launch configured app
• once first launch app exits: launch phosh

That would leverage the fact that we have control over when exactly the shell object is instantiated. We might need to unclutter phosh_shell_constructed for that at some point (so we can e.g. init CSS and make PhoshFader usable for fading without bringing up the panels. Downside is that we don't have the top panel for showing connection status.

2. Allow to not create PhoshHome (or at least put it behind the application)

In particular, it'd be neat to hold the initial shell reveal

If you have the full shell then you should have a splash screen doing this job.

[samcday]

1. Leave phosh out this

Mmm, I don't think that's a viable option. As you note, the top panel is important. Connection status and like, maybe changing device orientation and brightness (to actually conduct the First-run Experience ™️ properly), and so on.

2. Allow to not create PhoshHome (or at least put it behind the application)

Right, so I will start hacking some commits in the local phosh/ subtree to this effect. Do you think it makes sense to dispatch the phosh_home_new call through a vtable func on PhoshShell (similar to how we virtualized get_lockscreen_type)?

If you have the full shell then you should have a splash screen doing this job.

Well the issue is the fade-in signal to phoc happens at the end of the idle setup callback in PhoshShell. Currently that's fine because the lockscreen construction and populating the user+session happens synchronously during that init flow. If instead we launch a first-run app in a separate process, we're not blocking the PhoshShell constructor for that and so it's harder to ensure that initial fade-in happens in the sexiest way possible.

[agx]

Mmm, I don't think that's a viable option

Yeah, that was my thinking as we'd not have connection status, BT devices, etc.

Do you think it makes sense to dispatch the phosh_home_new call through a vtable func on PhoshShell (similar to how we virtualized get_lockscreen_type)?

I'd rather have a property on PhoshShell that decides whether the current shell object has a PhoshHome rendered or not. That could become useful for other use cases like fullscreen.

[samcday]

I'd rather have a property on PhoshShell that decides whether the current shell object has a PhoshHome rendered or not.

Cool, that makes sense. I'll do that 👍

[samcday]

Very optimistically targeting the v0.42.0 release for this. Code freeze is 2 weeks away and I do not yet have any commits for consideration upstream yet.

[samcday]

I've opened https://gitlab.gnome.org/World/Phosh/phosh/-/merge_requests/1601 to get the ball rolling here upstream. It's a simple property on Phosh.Shell that prevents PhoshHome being constructed. I think the proposed patch is quite sane and unintrusive. I also think it's essentially exactly what you proposed back in September, so hopefully it looks okay 🤞

It's nice and simple on the consumer side, testing it in libphosh-rs custom-shell-and-lockscreen was as simple as changing this:

let shell = custom_shell::CustomShell::new();

to this:

    let shell: CustomShell = Object::builder()
        .property("home-enabled", false)
        .build();

And voila:

demo.webm

[samcday]

The initial stab is up as a PR - as such I think it's feasible to land this in 0.45