Kinoite KDE Welcome dialog, what to add?

Project Discussion
1

Fedora KDE and Kinoite have no Fedora-specific welcome dialog, while there would be the need for one.

I want to discuss what should be added and also how it should be packaged.

The GNOME setup dialog does the user creation, which is not needed, but it has some more things.

Repos

The GNOME setup allows to “add 3rd party repos”. I think this is totally confusing, because what is that?

  • rpmfusion?
  • the fedora 3rd party repo package?
  • flathub?

I know that on ublue, a “tinkerer specific variant”, Kinoite is the most common download. So I would like to diverge from the GNOME setup and add more options:

Add external Repositories

This will allow you to install packages from additional sources. No apps will be installed.

RPM Repositories

  • External Repositories :information_source:(Chrome, Pycharm, Jetbrains, NVIDIA)
  • RPMFusion :information_source:(needed for full media support and proprietary drivers)

Flatpak repositories

  • Fedora Flatpak Repository

  • Flathub, the official Flatpak repository (popup below appears when checked, radio buttons)

    • ( ) full :information_source:(the full repository containing all, including unofficial and nonfree/proprietary apps) (checked by default)
    • ( ) only verified :information_source:(only apps maintained by official developers)
    • ( ) only free software :information_source:(only software that is open source and under a free license)
    • ( ) only verified & free software :information_source:(both of the above)

The :information_source: can show a popup (the part in brackets) explaining what the subset does.

The only way to reset the subset currently is flatpak remote-delete --force flathub && flatpak remote-add flathub https://dl.flathub.org/repo/flathub.flatpakrepo but this works well and without uninstallations. Naming subset remotes differerent than flathub causes commands to not work.

Note that these subsets are maintained upstream and different from “filtered Flathub”.

See my repo with a list of all (?) Flatpak repos including the flathub subsets. All the othery are nieche or unstable.

Question: does that contradict with some Fedora philosophy? Could/should the GNOME setup be changed in a similar matter?

other things?

automatic updates

  • is rpm-ostree separated from flatpak? That would be useful but also more complicated. Ublue uptates flatpak every 6h, rpm-ostree every day, which is really nice.
  • the currently planned way is through the software stores, right? (I would prefer a systemd service with timer)
  • but could there be a moving slider to set the interval? This would be supercool.
  • also, a checkbox to “only update on unmeteted networks” would be useful, as this tag exists, even though it is not enforced. (Laptops dont normally use wwan cards, phone hotspots / usb tethering is registered as unmetered) but this would make people aware that this option exist, an :information_source: could inform them how to set a network as metered in systemsettings. Note: this option doesnt yet exist in rpm-ostree (but it needed for people using mobile hotspots) rpm-ostree FR
  • “only update on idle” (Note: this option doesnt exist yet in rpm-ostree) rpm-ostree FR
  • “silent mode” (the process gets a very low priority and consumes less resources) (Note: this option doesnt exist yet in rpm-ostree) rpm-ostree FR
  • “update when powering off”. This may be possible by catching the signal and replacing it with rpm-ostree update && shutdown now (Note: this could be an additional mechanism, or replace the automatic updates. It may be used only for rpm-ostree while flatpaks update automatically)
  • what about updating the toolboxes? They use podman containers but also package managers which is quite untraditional. Distrobox has a function to update all boxes using their individual package managers, toolbox hasn’t

Configure Background Updates

Configure updates without manual work. Recommended for most users.

  • User Applications :information_source:(this will update your installed Flatpak applications automatically) (interval pops up when checked) (text appears for the selected option, 4 options, weekly, 3 days, daily, 6h)

|---------------O---------------|--------------------|
[every 3 days]

  • System Updates :information_source:(this will automatically update your system in the background. Updates will not change your live system. Your next manual reboot will be into the updated system. The current system will be available as backup.) (Below options appear when checked)
    • only on unmetered networks :information_source:(Your system will not update if your network is marked as metered, e.g. a mobile connection. Set phone hotspots as “metered” in the network settings, to prevent high data usage)
    • only when idle :information_source:(Your system will only update if you where not using many resources for the past 20 minutes)
    • silent updates :information_source:(Updates will consume less resources and take longer to finish. You will likely not notice it, apart from less fan noise and heat)

(slider, text appears for the selected option, 4 options, biweekly, weekly, 3 days, daily)

|---------------|---------------O--------------------|
[every 3 days]

  • update when powering off :information_source:(Your system and apps will update when you turn off your computer. The shutdown will take a little longer, but updates don’t consume resources during use. You can use this option instead of automatic updates, or in addition to it)

Setting up a Toolbox

  • I imagine this would need to be a Fedora box with the same version, i.e. toolbox-create Toolbox
  • would other distros be possible? Probably not needed, wanted and possibly legal trouble?
  • what would the name be? I am not a fan of having an unnamed toolbox, which is what docs often refer to I think.
  • (not used toolbox in a while) does it create a GUI entry to launch it?
  • add konsole profile that launches the toolbox with a different color (this should be simpler that you think)

Install some applications

  • somehow manage the installstion of removed core apps like Gwenview and okular
  • this is already done by the upstream dialog with appstream metadata (there is a bug that needs to be fixed on Fedora Kinoite)
  • a link to the flatpak permissions systemsettings page, to manage the apps permissions

Packaging

Currently Fedora ships the unmodified plasma-welcome dialog. It would be best to keep that upstream and add custom QML pages via a plasma-welcome-regular and plasma-welcome-atomic package. Not sure if this is possible, but would be the best.

some more thoughts

This setup dialog is very much needed to round the edges of Kinoite.

Can you lock this dialog, so that it cannot be closed but needs to be finished or quit with a dedicated button? Would this be problematic? It is pretty essential to follow through and there are people always “clicking away that spam”.

1 Like
2

Hello Boredsquirrel!

My name is Steve (AKA Farchord) and I’m part of the KDE SiG. I wanted to let you know that we do have something on the way that’s similar to this: Overview - fedora-kde/plasma-welcome-fedora - Pagure.io

We are looking to release this before the official release of Fedora 40. This’ll be initially be released in Fedora’s KDE Spin and be used with Kinoite too.

The plasma-welcome-fedora app will add some customization to the welcome app, though not to the level that you are suggesting. The reason for this is simple: Most people simply “next-next-next” through it or simply close the app. But we did add the option to enable third party repos (On F40 KDE, that’ll run fedora-third-party).

Feel free to drop in https://matrix.to/#/#kde:fedoraproject.org and we can discuss!

2 Likes
3

Nice, sure!

4

Thanks for this post! I think this is a great idea, especially from the Kinoite side where it can be hard for people to realize the benefits they can enjoy for using the atomic spin.

When it comes to how updates are handled, I would like to keep the graphical way of managing updates. I know that on uBlue updates are automatic and on schedules, but they don’t have a graphical way of managing apps and checking what has to be updated or do updates manually. Ideally there would be a graphical way to manage automatic updates and update manually, but I wouldn’t want to lose that in favor of managing that in the terminal when I want to do it.

2 Likes
5

Rpm-ostree also has a native implementation in the stores. I am just not a fan of having them pop up manually, at all.

GUI configuration for sure, but such a QML page could also be added to systemsettings afaik, the same. So configure granularily, write to the systemd service file, have it work fully in the background (maybe with a notify-send at the end).

6

I see that point, especially because Fedora gets updates daily, especially the atomic spins. If that notification about updates being available can be put on a schedule (like after two weeks of not updating, nudge user that updates are available) then that works. And only if automatic updates are turned off. If the updates are running then you would never need to see a notification that you have updates available.

7

My ideal way would be

  • configure updates on startup, every user NEEDS to do this, sane defaults but supporting cases with rare updates (rule of thumb bein max 2 weeks distance. Also having idle, silent mode, unmetered connection) The same can be done in the system section of the systemsettings though, If users want to change it.
  • updates are done automatically with a small non-interactive notify-send interaction if they are done, when clicking it you can see the package changes (not the xxx overlays but only the packages updated, added, removed.)
  • Warn if packages where removed, like when Gwenview and Okular where removed. This should be done with kdialog (KDE)/zenity (the rest), and have a button to install the apps as flatpaks and require manual “okay”
  • if no auto-updates, display a kdialog (KDE)/zenity (the rest) if not updated for 2 days. This could also be configured. The dialog has “update” and “dismiss” buttons
  • The “update in shutdown” is an option I use to bypass the various issues with metered etc, there could be a GUI button like on Windows (shutdown, update and shutdown, reboot, update and reboot)
8

I think those are all fine options as long as there is a graphical way to adjust those settings later. I ran into an experience where there isn’t a graphical way to update on Bluefin and it bugged the heck out of me. Bazzite is a little better because I could manually update some things (mostly flatpaks), but I also have to go to the terminal if I want to manually update the image. I think both projects are in agreement that we want to move toward GUIs and not away from them, but I do want to mention it just in case. Kinoite didn’t always have a graphical way of managing updates, and now that it’s Discover I don’t want to lose it - that’s basically where my hesitation comes from, lol.

1 Like
9

yes, good point. This would not touch the discover implementation of rpm-ostree and flatpaks, but be additionally to it.

So if this is the way to go, those timers would hook into that existing mechanism and just fine tune it, leaving everything how it is.

What I would really like to get rid of is the rpm-ostree refresh-md when launching Discover/GNOME Software though. It makes quickly searching apps a pain. This would be possible if there is a graphical way to enable such automatic updates.

10

Oh, that would be a great little pro for automatic updates because of course you don’t need that to refresh if you’re going to get them eventually. Just refresh if you click to see the updates.

1 Like