Proposed KDE Plasma entry for the Wiki

As suggested here https://forum.endeavouros.com/t/kde-not-install-dependency-kdeplasma-addons/27972 and by @joekamprad this topic is intended to scope and draft a Wiki entry that covers KDE issues specific to EndeavourOS (i.e. not to replicate information in the Arch wiki or elsewhere). I’ve searched the forum and subreddit for common KDE issues and suggestions people have made.

The absence of kdeplasma-addons in the default KDE Plasma install has been mentioned a number of times https://forum.endeavouros.com/search?q=kdeplasma-addons, and one key difference to a standard Arch install of KDE Plasma is that EndeavourOS does not include plasma-meta out of the box.

Having installed the latest Apollo ISO in a Virtual Machine (selecting only the default options of Base + Common, Firefox, and KDE-Desktop), the following packages are selected for installation when running pacman -S plasma-meta:

archlinux-appstream-data
bluedevil
bolt
boost-libs
discover
drkonqi
gdb
gdb-common
kdeplasma-addons
kgamma5
ksshaskpass
kwayland-integration
kwrited
oxygen
plasma-browser-integration
plasma-firewall
plasma-systemmonitor
plasma-thunderbolt
plasma-vault
plasma-workspace-wallpapers
source-highlight
xdg-desktop-portal-kde

So, my proposed elements for an EndeavourOS specific guide to KDE are:

  • A brief description of KDE Plasma and signposting to the Arch Wiki https://wiki.archlinux.org/title/KDE

  • A brief explanation of the ethos of EndeavourOS and its intention to provide a minimal base of packages that users can add to.

  • Some packages that are not installed by default include kdeplasma-addons and discover (more details below).

  • kdeplasma-addons includes additional launchers, widgets, wallpaper options, task switchers and system tray applets.

  • Discover (should be included here as on first boot after installation it is a blank icon in the Task Manager) – Discover is not installed by default in EndeavourOS and is not recommended for package management in Arch Linux, as it obscures any messages that manual intervention is needed. It can be used to manage Plasma addons, and also firmware and Flatpaks (by installing fwupd and flatpak).

  • Thumbnails – by default EndeavourOS includes the ffmpegthumbnailer package. This does not provide thumbnails for audio files in Arch (this used to be the case – is it still true?). It can be replaced by the KDE packages ffmpegthumbs and kdegraphics-thumbnailers.

  • Wayland is not yet the default display server protocol for KDE Plasma. Outstanding bugs and issues can be found here – https://community.kde.org/Plasma/Wayland_Showstoppers. Yad is not fully working with Wayland, and this affects Welcome in particular (e.g. on KDE/Wayland) (link to Wiki entry for Welcome).

  • Cursors – for your chosen cursor theme to be used in SDDM and also the EOS apps under Wayland, you need to edit ~/.icons/default/index.theme - see here KDE Wayland issues with the EndeavourOS apps - #6 by joekamprad

  • Other packages – looking at the plasma-meta list above: bluedevil is included in the Bluetooth Wiki entry (could be mentioned and linked here); plasma-systemmonitor is easily found; plasma-browser-integration is also easily available as an addon/extension for browsers; EndeavourOS comes with firewalld installed by default, although personally I have uninstalled it and replaced it with ufw as it integrates better with plasma-firewall (views welcome on this in KDE) ??

  • Akonadi – I don’t use this or any of its related apps. Are there any EndeavourOS specific issues ??

  • pavucontrol is installed by default, but all its functions are covered by the Plasma Audio Volume applet. It could be recommended to either uninstall this or replace it with pavucontrol-qt ??

Hope the above makes sense :woozy_face: This is very much intended to be a first draft of the elements to be included, rather than a final draft of the Wiki entry. Let me know what’s right/wrong, missing/unnecessary.

I look forward to your input :nerd_face:

16 Likes

Only one - get ready to maintain that list of packages from plasma-meta, because it will definitely change :upside_down_face:

Maybe it’s best just to link for arch package directly where all dependencies are listed

4 Likes

Yes it will, so if we keep it to just kdeplasma-addons and discover from that list then it will be easy to maintain :smiley:

I use Kde and i’m satisfied with the current install of Kde Plasma on EndeavourOS. I’m really going to have to think about this because sure there may be a few additional packages that could be added but i don’t want to see much change myself. What i would rather see is if there would be a way to have an option in the online installer under the current selections for the desktop to have an additional packages category for each desktop where the user could select any of those additional packages that would be provided. This is something that may or may not be possible? For the future? :thinking:

3 Likes

I have been thinking also along these lines. Something like options for minimal and full desktop kinda sort of. Or some such :wink:

1 Like

So additional DE extras groups for each DE in netinstall.yaml?

On the online installer when you click on a desktop it shows the packages that are going to be installed for say kde. Then underneath this could be another menu item with additional packages. When you click on it there would be whatever packages the devs decide to add as additional that could be installed and it would pull down the dependencies needed.

1 Like

I am actually quite pleased with how it is now.
However minimal the current choice of packages is, I tend to even uncheck the box for a few that I know I don’t use.

1 Like

Me also but rather than add packages to the install I would like to see them as additional at the users choice to select.

Edit: This is only my opinion as an option. It would be entirely up to the devs and powers above.

Your proposal is a good one. An option for a minimal install of DE and another one with kitchen sink and all. However there is always user_pkglist as well. May be just give a more prominent hint in the installer to use it instead.

2 Likes

Personally I think the user_pkglist should be promoted more instead since it is more inline with the EOS philosophy of being terminal centric etc. Plus it’s already been here for a while. Most new users don’t read stuff before they even attempt an install. I think more focus should be put on this as well as the process for logs and troubleshooting.

Edit: What I was saying earlier was that I would rather have additional packages vs adding more to be installed automatically.

4 Likes