It would be really awesome for Plasma-welcome to act as a user onboarding for the KDE experience. For example, after installation of a system, on first boot, you'd be prompted to create your user account, with sudo permissions, etc. Thank you!
Ultimately I suspect this is how we'll end up doing it, yeah. Other efforts to create an OEM setup wizard within KDE seem to have stalled, and Wwlcome Center alrady has most of the needed plumbing. We just need a few new custom pages for creating user accounts, connecting to Wi-Fi, setting the language and keyboard layouts, and the like. In this mode, custom pages would be mandatory, and then distros with EULAs could use a custom page to show their EULA (or we could be nice and add a pre-made EULA page for them).
Calamares solves this use case already, does it not?
Yes, but Calamares isn't a KDE project and not all distros use it. Most of the big ones don't. FWIW, GNOME has their own thing for this.
It's a good idea, but how would Welcome Center be shown in an OEM mode? I'm unsure what would go in to doing that on Linux - by which I mean showing a window on boot (mandatory until completed) and then logging you in to that created user.
(In reply to Oliver Beard from comment #4) > It's a good idea, but how would Welcome Center be shown in an OEM mode? I'm > unsure what would go in to doing that on Linux - by which I mean showing a > window on boot (mandatory until completed) and then logging you in to that > created user. Something like that. Basically, the equivalent of Windows's OOBE. Or, if you want to test it in Linux Land, try to install Fedora 39 Workstation (Gnome), you'll see the setup wizard on first boot.
(In reply to Nate Graham from comment #3) > Yes, but Calamares isn't a KDE project and not all distros use it. Most of > the big ones don't. FWIW, GNOME has their own thing for this. That sounds like NIH reasoning. If a distro isn't using calamares for OEM why would they use our thing (that would just do what calamares already does)?
From the Fedora KDE perspective, we've tracked this downstream for a while: https://pagure.io/fedora-kde/SIG/issue/5 Some time ago, the development of KISS[1] was started specifically to support an integrated experience for a split-stage firstboot process. Unfortunately, development ended and it was archived. We tried pico-wizard and it turned out to be... not suitable[2]. Harald asks why would we use KDE's thing if we don't want to use Calamares. It comes down to two simple things: * It would be integrated into the desktop's system initialization process * It does not preclude the usage of the distribution's preferred system installer There are other complications with Calamares: notably that it cannot properly function unprivileged due to its design as a system installer[3], which means it is unusable for accessibility[4]. I have asked for a proper firstboot system similar to GNOME Initial Setup[5] to specifically address these problems and open the door to handle other things, such as being able to set the correct language and keyboard on boot in live environments, similar to what Mageia's live ISOs do with DrakLive. [1]: https://invent.kde.org/system/kiss [2]: https://invent.kde.org/plasma/pico-wizard/-/issues/1 [3]: https://github.com/calamares/calamares/issues/2268 [4]: https://github.com/calamares/calamares/issues/1294 [5]: https://gitlab.gnome.org/GNOME/gnome-initial-setup
(In reply to Harald Sitter from comment #6) > (In reply to Nate Graham from comment #3) > > Yes, but Calamares isn't a KDE project and not all distros use it. Most of > > the big ones don't. FWIW, GNOME has their own thing for this. > > That sounds like NIH reasoning. If a distro isn't using calamares for OEM > why would they use our thing (that would just do what calamares already > does)? Speaking as somebody that is creating a Plasma based product (https://kalpadesktop.org) it would be far more advantageous, and less overhead for me as a developer, if KDE offered a solution similar to G-I-S, for this purpose, as opposed to having to completely refactor into an entirely new installer. I've looked at Calamares, and I've even gotten some test builds working with it, but at least for us, we would absolutely prefer to go with something that's KDE integrated, whether as an extension to plasma-welcome or not. Partially because our upstream *is* GNOME based (https://aeondesktop.org), and leverages G-I-S for their setup, so the installer isn't offering this functionality.
Apparently our DNS(In reply to sfalken from comment #8) > (In reply to Harald Sitter from comment #6) > > (In reply to Nate Graham from comment #3) > > > Yes, but Calamares isn't a KDE project and not all distros use it. Most of > > > the big ones don't. FWIW, GNOME has their own thing for this. > > > > That sounds like NIH reasoning. If a distro isn't using calamares for OEM > > why would they use our thing (that would just do what calamares already > > does)? > > Speaking as somebody that is creating a Plasma based product > (https://kalpadesktop.org) it would be far more advantageous, and less > overhead for me as a developer, if KDE offered a solution similar to G-I-S, > for this purpose, as opposed to having to completely refactor into an > entirely new installer. > > I've looked at Calamares, and I've even gotten some test builds working with > it, but at least for us, we would absolutely prefer to go with something > that's KDE integrated, whether as an extension to plasma-welcome or not. > > Partially because our upstream *is* GNOME based (https://aeondesktop.org), > and leverages G-I-S for their setup, so the installer isn't offering this > functionality. Apparently our DNS forward is acting up. https://en.opensuse.org/Portal:Kalpa is the alternative address, if kalpadesktop.org is acting up for anybody.
(In reply to sfalken from comment #8) > as opposed to having to completely refactor into an entirely new installer. I am not following, using calamares as installer is separate from using calamares as OEM configurator.