search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
536 stars 48 forks source link

Improve documentation on installing KDE in dom0 #2663

Open Rudd-O opened 7 years ago

Rudd-O commented 7 years ago

These are the packages needed:

packages:
- plasma-workspace
- plasma-systemsettings
- plasma-breeze
- kde-settings-plasma
- plasma-desktop
- kwin
- kscreen

Note the missing package in #2662 .

Here is an Ansible playbook that deploys KDE and works around some issues of KDE not being present in the base image:

- hosts: dom0
  become: true
  vars:
    packages:
    - plasma-workspace
    - plasma-systemsettings
    - plasma-breeze
    - kde-settings-plasma
    - plasma-desktop
    - kwin
    - kscreen
  tasks:
  - name: install required software
    shell: qubes-dom0-update -y {{ " ".join(packages) }}
    register: dom0install
    changed_when: '{{ "Nothing to do" not in dom0install.stdout }}'
  - name: fix PAM settings for kscreensaver so the screen can be unlocked
    shell: |
      cd /etc/pam.d
      diff kscreensaver xscreensaver > /dev/null && {
        echo ALREADY
      } || {
        test -f kscreensaver.bak || cp -f kscreensaver kscreensaver.bak
        cat xscreensaver > kscreensaver
      }
    register: kscreensaverfix
    changed_when: '{{ "ALREADY" not in kscreensaverfix.stdout }}'
marmarek commented 7 years ago

Have you tried this: https://www.qubes-os.org/doc/kde/ ? It's linked from the main documentation index...

andrewdavidwong commented 7 years ago

@Rudd-O: As Marek pointed out, there clearly exists documentation about installing KDE in dom0. Should this issue instead be about improving that documentation?

Rudd-O commented 7 years ago

Yes.

Rudd-O commented 7 years ago

The docs mention a kstart program that does not seem to be available on my system after installing KDE.

The docs also make no mention of the fact that the screenlocker will malfunction and needs a fix as per the above role (which I have uploaded to https://github.com/Rudd-O/ansible-samples/tree/master/qubeskde )

Rudd-O commented 7 years ago

OK. KDE ships with a program called kstart5. The docs need to be updated to reflect that.

andrewdavidwong commented 7 years ago

@Rudd-O: Please consider submitting a PR.

0spinboson commented 4 years ago

this group is broken again in Q4.1.

marmarek commented 4 years ago

Generally KDE in R4.1 is not yet done. Any help welcome here. It's mostly about updating qubes-desktop-linux-kde-* repositories to the versions in Fedora 31.

0spinboson commented 4 years ago

Generally KDE in R4.1 is not yet done. Any help welcome here. It's mostly about updating qubes-desktop-linux-kde-* repositories to the versions in Fedora 31.

okay. will try to play around with it, it looks like kde-baseapps was phased out after kde/ubuntu 16.08.x. https://community.kde.org/Applications/16.12_Release_Notes says:

0spinboson commented 4 years ago

btw, this may mean kde is becoming a viable alternative to xfce again: https://www.forbes.com/sites/jasonevangelho/2019/10/23/bold-prediction-kde-will-steal-the-lightweight-linux-desktop-crown-in-2020/#69447a6a26d2

I’m as surprised about writing this article as you are at reading that headline. But yes, folks, in much of my initial testing the latest version of KDE (5.17) is using less RAM than Xfce 4.14.

fepitre commented 4 years ago

Generally KDE in R4.1 is not yet done. Any help welcome here. It's mostly about updating qubes-desktop-linux-kde-* repositories to the versions in Fedora 31.

okay. will try to play around with it, it looks like kde-baseapps was phased out after kde/ubuntu 16.08.x. https://community.kde.org/Applications/16.12_Release_Notes says:

* kde-baseapps (split into kdialog, keditbookmarks, kfind, konqueror. kdepasswd is gone)

@0spinboson: thank you for your help in this direction of updating KDE. kde-baseapps is more a metapackage now: https://src.fedoraproject.org/rpms/kde-baseapps/blob/master/f/kde-baseapps.spec.

btw, this may mean kde is becoming a viable alternative to xfce again: https://www.forbes.com/sites/jasonevangelho/2019/10/23/bold-prediction-kde-will-steal-the-lightweight-linux-desktop-crown-in-2020/#69447a6a26d2

I’m as surprised about writing this article as you are at reading that headline. But yes, folks, in much of my initial testing the latest version of KDE (5.17) is using less RAM than Xfce 4.14.

With GuiVM, that would be easier to choose/switch default desktop. I don't know yet if we could achieve at firstboot something like letting user decide which desktop to use in GuiVM but I'm seeing at least two options for that:

0spinboson commented 4 years ago

Generally KDE in R4.1 is not yet done. Any help welcome here. It's mostly about updating qubes-desktop-linux-kde-* repositories to the versions in Fedora 31.

okay. will try to play around with it, it looks like kde-baseapps was phased out after kde/ubuntu 16.08.x. https://community.kde.org/Applications/16.12_Release_Notes says:

* kde-baseapps (split into kdialog, keditbookmarks, kfind, konqueror. kdepasswd is gone)

@0spinboson: thank you for your help in this direction of updating KDE. kde-baseapps is more a metapackage now: https://src.fedoraproject.org/rpms/kde-baseapps/blob/master/f/kde-baseapps.spec.

Thank you for the kind words. Yeah, I saw that, but due to my ineptitude, I'd assumed that since the metapackage is still prefixed '16' (rather than starting with '19' as I'd expect for something that's tracking the kde applications), I'd assumed it wasn't really getting much love from the fedora folks. Is that inaccurate?

btw, this may mean kde is becoming a viable alternative to xfce again: https://www.forbes.com/sites/jasonevangelho/2019/10/23/bold-prediction-kde-will-steal-the-lightweight-linux-desktop-crown-in-2020/#69447a6a26d2

I’m as surprised about writing this article as you are at reading that headline. But yes, folks, in much of my initial testing the latest version of KDE (5.17) is using less RAM than Xfce 4.14.

With GuiVM, that would be easier to choose/switch default desktop. I don't know yet if we could achieve at firstboot something like letting user decide which desktop to use in GuiVM but I'm seeing at least two options for that:

  • embed the very minimal package set for each desktop supported in one template (i'm not fan of this possibility at all)
  • find a way for feeding a local repository to the corresponding template with necessary packages for the desktop chosen (extensive pipeline with respect to different template available).

Given the amount of extra work it sounds like that would require, and seeing how few devs the project has, this sounds like rather a lot of work for something with middle-low priority.