KDE -> XFCE migration documentation?

[adrelanos]

Should we have KDE -> XFCE migration instructions for Qubes R3.2? It's non-trivial...

• switch from kdm to lightdm (since kdm is super slow which is probably a kde bug) -> sudo systemctl enable lightdm?
• set default session from (user-session=xfce does not work, why?)
• autologin for default user (works [autologin-user=user])

sudo kate /etc/lightdm/lightdm.conf.d/user.conf

[SeatDefaults]
user-session=xfce
autologin-user=user

• uninstall kdm / kde -> how?

This requires research and how to do these things. As well as documentation.

related:

• https://www.qubes-os.org/doc/xfce/
• https://www.qubes-os.org/doc/upgrade-to-r3.2/

Or should we simply say "backup your VMs, re-install and restore your VMs"?

[andrewdavidwong]

Probably the latter, but that might mean no fully-supported in-place upgrade path.

Is there also a third option: upgrade in place and keep using KDE?

@marmarek

[andrewdavidwong]

Probably the latter, but that might mean no fully-supported in-place upgrade path.

Is there also a third option: upgrade in place and keep using KDE?

@marmarek

[adrelanos]

@andrewdavidwong

Is there also a third option: upgrade in place and keep using KDE?

Quote Joanna from #2119:

upgraded KDE to 5.x which, for me at least, looks like a total disaster.

And I am afraid, as a year long KDE user I have to agree with that.

• super slow login manager kdm
• #2264

I would go as far as suggesting making KDE unsupported by Qubes or community supported only where most bugs / questions are ignored. As far as Whonix is involved, supporting XFCE as well as KDE would even increase maintenance overhead, since both would have to be tested.

[adrelanos]

@andrewdavidwong

Is there also a third option: upgrade in place and keep using KDE?

Quote Joanna from #2119:

upgraded KDE to 5.x which, for me at least, looks like a total disaster.

And I am afraid, as a year long KDE user I have to agree with that.

• super slow login manager kdm
• #2264

I would go as far as suggesting making KDE unsupported by Qubes or community supported only where most bugs / questions are ignored. As far as Whonix is involved, supporting XFCE as well as KDE would even increase maintenance overhead, since both would have to be tested.

[Zrubi]

Actually I would prefer the "keep the KDE 5" at least as a user choice.

Since I have no major problems with KDE 5 which is actually using sddm instead of kdm as a login manager. It is supports custom X parameters what is needed for Qubes, and it is actually working fine under Qubes 3.2.
(will extend the current KDE documentation page soon)

BTW:

• "ugliness" is really not a technical reason to drop it, and at most it is a subjective thing.
• "bloated" maybe means more features. Even if one do not need them others may find it very useful.
• "slow and unstable" probably because the composition features(which are optional) and maybe hardware related issues...

[Zrubi]

Actually I would prefer the "keep the KDE 5" at least as a user choice.

Since I have no major problems with KDE 5 which is actually using sddm instead of kdm as a login manager. It is supports custom X parameters what is needed for Qubes, and it is actually working fine under Qubes 3.2.
(will extend the current KDE documentation page soon)

BTW:

• "ugliness" is really not a technical reason to drop it, and at most it is a subjective thing.
• "bloated" maybe means more features. Even if one do not need them others may find it very useful.
• "slow and unstable" probably because the composition features(which are optional) and maybe hardware related issues...

[Zrubi]

But to add some notes to the topic itself:
Yes, I also feel the need for such a documentation, because of missing and/or different features of KDE and XFCE.

[Zrubi]

But to add some notes to the topic itself:
Yes, I also feel the need for such a documentation, because of missing and/or different features of KDE and XFCE.