#295 Test and improve Plasma Welcome for Fedora integrations
Opened a year ago by siosm. Modified 5 months ago

See https://invent.kde.org/plasma/plasma-welcome (package: https://src.fedoraproject.org/rpms/plasma-welcome-app).

We should (at least) be able to include all the features that are available in GNOME Tour already (https://gitlab.gnome.org/GNOME/gnome-tour), from a legal perspective.

Something like:
- Letting the user enable filtered / unfiltered Flathub: https://pagure.io/fedora-kde/SIG/issue/95
- Letting the user enable third party repos (Steam, NVIDIA, etc.): https://pagure.io/fedora-kde/SIG/issue/94
- Suggest installing openh264: https://pagure.io/fedora-kde/SIG/issue/357


Metadata Update from @siosm:
- Issue set to the milestone: Plasma 5.27

a year ago

Metadata Update from @siosm:
- Issue tagged with: experience, kinoite

a year ago

Metadata Update from @siosm:
- Issue tagged with: need-work

a year ago

I think I can look into this. We would need to write Fedora specific "pages" into the plasma welcome wizard and I already have some past experience with QML. These Fedora specific additions can have a repo at https://pagure.io/projects/fedora-kde/%2A. I checked and Fedora Weblate can also translate stuff on Pagure so that should work just fine.

My understanding is that this needs to go into pico-wizard, not plasma-welcome. The former runs before the first user is created, and the latter happens afterward.

Just to be clear, are we planning on having both run on a fresh install?
First pico-wizard, and then Plasma-Welcome ?

Sounds like a bad UX to have two welcome/setup wizards run.

We need both because we need the first to create the user and then the second one to be displayed every time we have a major plasma update to get "Hey, here is what's new in 5.28".

I would prefer we keep the duties of Pico Wizard to a minimum as it runs as root, is harder to test and should / will only run once on the first boot.

With the welcome app, we can trigger it to run on login as needed when we add configuration options / major updates happen, it is much much easier to test and work on, does not need root but can also do things as root as needed if the user is an admin.

fedora-third-party needs to run as root, so that goes to pico-wizard anyway.

fedora-third-party needs to run as root, so that goes to pico-wizard anyway.

We can go through Polkit and run fedora-third-party with elevated permissions, that's not a problem. I havent' seen pico-wizard, but my assumption is that plasma-welcome will be more visually close to KDE/Plasma and that's where I would put most of the post-install configuraiton. It will be also easier to customize as we can use C++/QML, while with pico-wizard one has to use Python, which at least for me is an obstacle.

I think it makes sense to have the unfiltered Flathub toggle and NVIDIA driver question in plasma-welcome at least, because not all users will ever see pico-wizard; it's designed for OEM installs where the user has not installed the OS themselves. What it does should be kept to an absolute minimum needed to make the system usable.

Custom pages can run arbitrary terminal commands, so as long as these tasks can be accomplished using the CLI, you can put a button on a page to do them as well.

I think it makes sense to have the unfiltered Flathub toggle and NVIDIA driver question in welcome-wizard at least, because not all users will ever see pico-wizard; it's designed for OEM installs where the user has not installed the OS themselves. What it does should be kept to an absolute minimum needed to make the system usable.

The goal is that the initial setup wizard will be shown regardless of install method, similar to Fedora Workstation. But if we do it in Plasma Welcome, we will need a way to track that it was done so it doesn't get asked to another user in a multi-user setup.

Plasma-welcome makes sense to show regardless of install method. I don't think pico-wizard does, though.

Great suggestion!

Maybe this welcome dialog could be used for more things like installing proprietary codecs, which should be no legal issue.

Maybe even using the HardHatOS Kernel and Malloc.

Also for displaying some Kinoite specific infos for Kinoite, like how to use updates, how to use Toolbox / Distrobox e.g.

Maybe this welcome dialog could be used for more things like installing proprietary codecs, which should be no legal issue.

Ehhh....

Maybe even using the HardHatOS Kernel and Malloc.

What?

Also for displaying some Kinoite specific infos for Kinoite, like how to use updates, how to use Toolbox / Distrobox e.g.

Sure, I suppose...

Metadata Update from @ngompa:
- Issue set to the milestone: None (was: Plasma 5.27)

a year ago

Login to comment on this ticket.

Metadata
Boards 1
Kinoite Status: Triaged