Get rid of KDE, use Xfce as the default Dom0 WM/DE

[rootkovska]

We've long wanted to get rid of the KDE out of Dom0 (because it's been: 1. bloated, 2. heavy on resources, 3. unstable, and last but not least: 4. ugly, see #84), yet we somehow always postponed it until later. More recently, we decided to try to get Gnome env as the default Qubes GUI (#1806). But the road to get Gnome working is still long and bumpy. Meanwhile, we have released Qubes 3.2-rc1 with upgraded KDE to 5.x which, for me at least, looks like a total disaster... A disaster that must be worked around ASAP, i.e. before the final 3.2 release, IMHO. And the best we could do, I think, is to switch to Xfce4, which today works really well, as I've had a chance to test over the last 2 days of extensive use.

So, what's wrong with the latest KDE we got in Qubes 3.2? A few things:

1. It seems very unstable. I installed and tested on several machines with different GPUs (some very old ones!) and on every one I keep getting plasma/kwin crashes every few hours. This is just ridiculous.
2. KDE has a reputation for being heavy and slow, but this latest release seems to beat itself in this respect beyond any reasonable expectation. This is clearly visible on some HiDPI systems, where the number of pixels (more specifically: memory pages) to process causes our GUI daemons to draw very slowly. Admittedly there are some bottlenecks in our GUI protocol (specifically that the actual lists of PFNs are copied), but switching from KDE to Xfce4 visibly improved the graphics speed from totally-not-usable to somehow-slow. Apparently KDE (kwin) tries some composition magic that slows down the system. Perhaps there are humans who could understand the KDE's graphics settings dialog-box, but surely this is beyond my mental powers.
3. The KDE's infamous bloated UI got even more bloated. Specifically the new "Start Menu" distracts the user even more from the Qubes isolated domains concept.
4. While this is a very subjective opinion, the KDE is ugly, and it's getting uglier with each new release. Plus it completely doesn't match the mostly-gnome apps we have in AppVMs by default (and which we have because they are so much lighter than their KDE alternatives).

Plus all the usual bugs with complex handling of appmemus (due to caching, etc.), see e.g. #890, #1628, #751.

Now, all the above problems can be resolved with the latest Xfce4, which we already support well (incl. decoration plugins, and general customization/striping for Qubes).

Looks like currently the only one features originally mentioned in #84 as the showstopper, is the lack of the expose-like effect. However, the new Xfce4 does have composition-based Alt-Tab poor-man's expose-like functionality, which should just be good enough for the purpose of securely identifying GUI decoration spoofing attacks (i.e. displaying e.g. a green-bordered password-prompting fake window within a red-bordered Web browser window).

There are still a few, rather minor I think, issues with the Xfce4 that I will describe in the upcoming separate tickets. But these seem so minor, compared with the problems outlined above and pertinent to the KDE, that I suggest that we promote the Xfce4 to the default GUI manager for Qubes 3.2, starting with rc2, and get rid of the KDE from the installer ISO (still preserving, of course, this as an optional WM, next to others we also offer via our repos).

I think that we should also give up on trying to get Gnome for Qubes 4.0 and just use Xfce4.

FWIW, I now use Qubes 3.2-rc1 with Xfce4 on my primary laptop.

[rootkovska]

Attaching a screenshot of how an Xfce4-based Qubes desktop might look like...

[rootkovska]

Attaching a screenshot of how an Xfce4-based Qubes desktop might look like...

[indolering]

While this is a very subjective opinion, the KDE is ugly, and it's getting uglier with each new release.

As a usability engineer, I would like to say that KDE looks like hell : )

[indolering]

While this is a very subjective opinion, the KDE is ugly, and it's getting uglier with each new release.

As a usability engineer, I would like to say that KDE looks like hell : )

[LeeteqXV]

That screenshot looks nice enough.

Personally, I am all in favor of Gnome, but also postponing it for stability, hence moving to XFCE4 meanwhile sounds good.

However, would the ('temporary') move to XFCE impact which features we have available such as increasing/decreasing windows transparency/opacity with a user-customizeable shortcut key combination?

A few points that I myself notice affects how much I (dis)like a DE:

• if I cannot auto-hide panels (the toolbar/line with the menu options and status icons), and have several such panels top/bottom/right/left
• the mentioned transparency customization is crucial: It brings tremendous "quality-of-life" (enjoyment) to using a GUI if I can work and write text on top of my favorite desktop background image
• set different background image per desktop
• easily make launchers/shortcuts and folders with such grouped shortcuts on each panel

All the customization options we already have now are part of KDE, I assume, so does XFCE offer something like that, or would we loose it ('temporarily')? I am not familiar with XFCE at all, but customisation of the GUI is rather important, IMHO.

[LeeteqXV]

That screenshot looks nice enough.

Personally, I am all in favor of Gnome, but also postponing it for stability, hence moving to XFCE4 meanwhile sounds good.

However, would the ('temporary') move to XFCE impact which features we have available such as increasing/decreasing windows transparency/opacity with a user-customizeable shortcut key combination?

A few points that I myself notice affects how much I (dis)like a DE:

• if I cannot auto-hide panels (the toolbar/line with the menu options and status icons), and have several such panels top/bottom/right/left
• the mentioned transparency customization is crucial: It brings tremendous "quality-of-life" (enjoyment) to using a GUI if I can work and write text on top of my favorite desktop background image
• set different background image per desktop
• easily make launchers/shortcuts and folders with such grouped shortcuts on each panel

All the customization options we already have now are part of KDE, I assume, so does XFCE offer something like that, or would we loose it ('temporarily')? I am not familiar with XFCE at all, but customisation of the GUI is rather important, IMHO.

[KAMiKAZOW]

So you want to stick with insecure X11 rather than walking the Wayland path towards greater security?
Well, I guess it's an acceptable sacrifice as long as it "looks nice"…

[KAMiKAZOW]

So you want to stick with insecure X11 rather than walking the Wayland path towards greater security?
Well, I guess it's an acceptable sacrifice as long as it "looks nice"…

[rootkovska]

On Tue, Jun 28, 2016 at 05:30:03AM -0700, ⛅ wrote:

So you want to stick with insecure X11 rather than walking the Wayland path towards greater security?
Well, I guess it's an acceptable sacrifice as long as it "looks nice"…

Qubes GUI architecture has been specifically designed to work around all the
problems related to X11 (large app->X server attack surfaces, insecure events,
etc). Thus, from the security point of view, it's irrelevant whether we use X11
or Wayland in either VMs or Dom0.

More read:
https://www.qubes-os.org/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf

[rootkovska]

On Tue, Jun 28, 2016 at 05:30:03AM -0700, ⛅ wrote:

So you want to stick with insecure X11 rather than walking the Wayland path towards greater security?
Well, I guess it's an acceptable sacrifice as long as it "looks nice"…

Qubes GUI architecture has been specifically designed to work around all the
problems related to X11 (large app->X server attack surfaces, insecure events,
etc). Thus, from the security point of view, it's irrelevant whether we use X11
or Wayland in either VMs or Dom0.

More read:
https://www.qubes-os.org/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf

[waiting-for-dev]

I completely agree with the points stated in this issue. I changed to QubesOS around one month ago. Since then, I'm absolutely happy with the approach it takes. I like having to take decisions that concerns my system security. I knew that I was going to have some issue, but it is always about trade-off and it has been much better than I thought.

The only think I really miss is Gnome 3. I think more important that beauty is usability, and I find KDE is horrible in that respect. For now, I have to stick to it because I had some weird issues with Xfce that hopefully will be gone in 3.2. I felt in love with Gnome 3 three years ago. For me, it has been the most user friendly user environment I have tried, the one that really stayed out of my way. Maybe it's not for every user, but I think it's near perfection for developers. You can have everything hidden and just display what you need pressing meta key. So, at least, while we can't get to Gnome, I will be very happy if I can rid off Kde.

[waiting-for-dev]

I completely agree with the points stated in this issue. I changed to QubesOS around one month ago. Since then, I'm absolutely happy with the approach it takes. I like having to take decisions that concerns my system security. I knew that I was going to have some issue, but it is always about trade-off and it has been much better than I thought.

The only think I really miss is Gnome 3. I think more important that beauty is usability, and I find KDE is horrible in that respect. For now, I have to stick to it because I had some weird issues with Xfce that hopefully will be gone in 3.2. I felt in love with Gnome 3 three years ago. For me, it has been the most user friendly user environment I have tried, the one that really stayed out of my way. Maybe it's not for every user, but I think it's near perfection for developers. You can have everything hidden and just display what you need pressing meta key. So, at least, while we can't get to Gnome, I will be very happy if I can rid off Kde.

[free5lot]

GNOME is a disaster. It has almost no options and no settings in GUI, so often it's impossible to tune something even simple.
Probably because gnome-developers think that they know better what user wants and what he doesn't (apple style). And GTK's open/save dialog is still the most awful thing in GNU/Linux world. It's hard to believe, how terrible it stays for 10-20 years straight.

On the other hand, I think DE is not the most important part in QubesOS, e.g. unsolved video-acceleration problem that doesn't allow to have 720p/1080p video lags-free playback with adequate bitrate is MUCH more important thing for average PC or notebook user in my opinion.
So, OK, let it be xfce, but got to say: GTK and Gnome are NO GOOD at all.

Anyhow, thanks for great project, QubesOS developers and Joanna! Long may she reign!

[free5lot]

GNOME is a disaster. It has almost no options and no settings in GUI, so often it's impossible to tune something even simple.
Probably because gnome-developers think that they know better what user wants and what he doesn't (apple style). And GTK's open/save dialog is still the most awful thing in GNU/Linux world. It's hard to believe, how terrible it stays for 10-20 years straight.

On the other hand, I think DE is not the most important part in QubesOS, e.g. unsolved video-acceleration problem that doesn't allow to have 720p/1080p video lags-free playback with adequate bitrate is MUCH more important thing for average PC or notebook user in my opinion.
So, OK, let it be xfce, but got to say: GTK and Gnome are NO GOOD at all.

Anyhow, thanks for great project, QubesOS developers and Joanna! Long may she reign!

[rapgro]

Read: http://blog.alteroot.org/articles/2016-04-12/road-to-xfce-4.14.html

[rapgro]

Read: http://blog.alteroot.org/articles/2016-04-12/road-to-xfce-4.14.html

[xenithorb]

Nice, way to implement a deprecated GTK2 system.

[xenithorb]

Nice, way to implement a deprecated GTK2 system.

[mixedCase]

GNOME is a great DE for exactly two distros: RedHat and Fedora. They design GNOME to work for their usecases and no one else's; never a better example than "my way or the highway". KDE has a tendency to release unfinished software and they did not go far enough with the redesign of Plasma 5.

So I can definitely get behind XFCE. With that said, I'd say that MATE and LXQt should also be considered. LXQt is already on Qt5 so there's good high DPI support among many other niceties; while MATE may or may not get to GTK 3 before XFCE does.

[mixedCase]

GNOME is a great DE for exactly two distros: RedHat and Fedora. They design GNOME to work for their usecases and no one else's; never a better example than "my way or the highway". KDE has a tendency to release unfinished software and they did not go far enough with the redesign of Plasma 5.

So I can definitely get behind XFCE. With that said, I'd say that MATE and LXQt should also be considered. LXQt is already on Qt5 so there's good high DPI support among many other niceties; while MATE may or may not get to GTK 3 before XFCE does.

[lucasrunner]

I strongly disagree with your points. Let me explain why

1. Which version of Plasma 5.x exactly? I am asking because it makes a huge difference. Since Plasma 5 is released every 3 months now, every new release brings huge improvements in stability. Please also remember that Qt 5.6 have some nasty regressions (use 5.6.1 or later) https://mail.kde.org/pipermail/kde-distro-packagers/2016-March/000138.html. The same goes for multi-screen issues sadly.
2. Xfce (xubuntu 16.04) running from live usb is using 302 mb of ram
   http://wstaw.org/w/40Ui/
   For comparison KDE Neon (based on ubuntu 16.04) running from live usb is using 350 mb of ram.
   http://wstaw.org/w/40Uj/
   As you admitted "there are some bottlenecks in our GUI protocol" so you may want to disable compositing (yeah one can still do that)
3. Which menu? For example openSUSE and a few other KDE distros use classic menu by default (hardly distracting)
   http://wstaw.org/w/40Uk/
4. Plasma 5 supports something called look and feel packages (basically big meta themes). You can switch to oxygen in system settings > workspace theme > look and feel.
   http://wstaw.org/w/40Ul/
   While this is a very subjective opinion I think that breeze theme is a huge improvement compared to the old KDE 4 glossy theme. KDE developers also provide GTK 2 and GTK 3 breeze theme.

[lucasrunner]

I strongly disagree with your points. Let me explain why

1. Which version of Plasma 5.x exactly? I am asking because it makes a huge difference. Since Plasma 5 is released every 3 months now, every new release brings huge improvements in stability. Please also remember that Qt 5.6 have some nasty regressions (use 5.6.1 or later) https://mail.kde.org/pipermail/kde-distro-packagers/2016-March/000138.html. The same goes for multi-screen issues sadly.
2. Xfce (xubuntu 16.04) running from live usb is using 302 mb of ram
   http://wstaw.org/w/40Ui/
   For comparison KDE Neon (based on ubuntu 16.04) running from live usb is using 350 mb of ram.
   http://wstaw.org/w/40Uj/
   As you admitted "there are some bottlenecks in our GUI protocol" so you may want to disable compositing (yeah one can still do that)
3. Which menu? For example openSUSE and a few other KDE distros use classic menu by default (hardly distracting)
   http://wstaw.org/w/40Uk/
4. Plasma 5 supports something called look and feel packages (basically big meta themes). You can switch to oxygen in system settings > workspace theme > look and feel.
   http://wstaw.org/w/40Ul/
   While this is a very subjective opinion I think that breeze theme is a huge improvement compared to the old KDE 4 glossy theme. KDE developers also provide GTK 2 and GTK 3 breeze theme.

[marmarek]

Which version of Plasma 5.x exactly? I am asking because it makes a huge difference. Since Plasma 5 is released every 3 months now, every new release brings huge improvements in stability. Please also remember that Qt 5.6 have some nasty regressions (use 5.6.1 or later) https://mail.kde.org/pipermail/kde-distro-packagers/2016-March/000138.html. The same goes for multi-screen issues sadly.

In short - the version which is available in Fedora 23 repository. Which means Qt 5.6.0, Plasma 5.6.5, kf5-* packages 5.22.0. It has all the patches mentioned above applied.

Which menu? For example openSUSE and a few other KDE distros use classic menu by default (hardly distracting)
http://wstaw.org/w/40Uk/

Yes, the classic menu is slightly better. But setting this (and other
things - see #1784 (comment)) by default, without forking all the packages and applying patches is painful.
In theory KDE supports scripts for that. In practice - it is severely limited (for example there is no way to
remove an entry, only add new value or change existing), and very hard to debug - you wont receive any feedback from applets loading new configuration, or sometimes you don't even know if the new configuration was loaded at all.
Also, asked about that on KDE mailing list. And guess what - no answer at all.

[marmarek]

Which version of Plasma 5.x exactly? I am asking because it makes a huge difference. Since Plasma 5 is released every 3 months now, every new release brings huge improvements in stability. Please also remember that Qt 5.6 have some nasty regressions (use 5.6.1 or later) https://mail.kde.org/pipermail/kde-distro-packagers/2016-March/000138.html. The same goes for multi-screen issues sadly.

In short - the version which is available in Fedora 23 repository. Which means Qt 5.6.0, Plasma 5.6.5, kf5-* packages 5.22.0. It has all the patches mentioned above applied.

Which menu? For example openSUSE and a few other KDE distros use classic menu by default (hardly distracting)
http://wstaw.org/w/40Uk/

Yes, the classic menu is slightly better. But setting this (and other
things - see #1784 (comment)) by default, without forking all the packages and applying patches is painful.
In theory KDE supports scripts for that. In practice - it is severely limited (for example there is no way to
remove an entry, only add new value or change existing), and very hard to debug - you wont receive any feedback from applets loading new configuration, or sometimes you don't even know if the new configuration was loaded at all.
Also, asked about that on KDE mailing list. And guess what - no answer at all.

[star-buck]

While XFCE seems also like a good choice, it simply isn't true for Plasma being bloated:
https://postimg.org/image/p9h64wm8x/
Screenshot shows Plasma 5 Desktop running on an Odroid C1 (note you also can subtract the vnc and websockify processes due to the screenshot being taken over novnc).

[star-buck]

While XFCE seems also like a good choice, it simply isn't true for Plasma being bloated:
https://postimg.org/image/p9h64wm8x/
Screenshot shows Plasma 5 Desktop running on an Odroid C1 (note you also can subtract the vnc and websockify processes due to the screenshot being taken over novnc).

[lucasrunner]

In theory KDE supports scripts for that. In practice - it is severely limited (for example there is no way to remove an entry, only add new value or change existing), and very hard to debug - you wont receive any feedback from applets loading new configuration, or sometimes you don't even know if the new configuration was loaded at all.
Also, asked about that on KDE mailing list. And guess what - no answer at all.

https://marc.info/?l=kde&r=1&w=2 is a user support mailing lists. Hardly any KDE devs are there. Plasma-devel https://mail.kde.org/mailman/listinfo/plasma-devel is the right place to ask. I am sure that plasma developers will try to answer all your questions.

[lucasrunner]

In theory KDE supports scripts for that. In practice - it is severely limited (for example there is no way to remove an entry, only add new value or change existing), and very hard to debug - you wont receive any feedback from applets loading new configuration, or sometimes you don't even know if the new configuration was loaded at all.
Also, asked about that on KDE mailing list. And guess what - no answer at all.

https://marc.info/?l=kde&r=1&w=2 is a user support mailing lists. Hardly any KDE devs are there. Plasma-devel https://mail.kde.org/mailman/listinfo/plasma-devel is the right place to ask. I am sure that plasma developers will try to answer all your questions.

[rootkovska]

I would like to clarify that this ticket is not intended to serve the purpose of debating the decision to move away from KDE. The decision has been made already by the core devs. It only is here to serve the purpose of tracking the progress of implementing this for the upcoming 3.2 (plus give some rationalization for the record). In the interest of keeping the ticketing system useful for tracking of our work, I'd like to ask people, especially non-Qubes devs, to refrain from commenting. Thank you for your understanding.

[rootkovska]

I would like to clarify that this ticket is not intended to serve the purpose of debating the decision to move away from KDE. The decision has been made already by the core devs. It only is here to serve the purpose of tracking the progress of implementing this for the upcoming 3.2 (plus give some rationalization for the record). In the interest of keeping the ticketing system useful for tracking of our work, I'd like to ask people, especially non-Qubes devs, to refrain from commenting. Thank you for your understanding.

[lucasrunner]

I fully respect your decision. I only regret that your issues weren't properly communicated with KDE developers. Since this ticket was picked by the press http://news.softpedia.com/news/qubes-os-3-2-to-use-xfce-by-default-because-kde-5-is-bloated-unstable-and-ugly-505745.shtml I suggest to close this issue or to restrict further comments.

[lucasrunner]

I fully respect your decision. I only regret that your issues weren't properly communicated with KDE developers. Since this ticket was picked by the press http://news.softpedia.com/news/qubes-os-3-2-to-use-xfce-by-default-because-kde-5-is-bloated-unstable-and-ugly-505745.shtml I suggest to close this issue or to restrict further comments.

[birdie-github]

KDE5 is bloated beyond measure as seen on this screenshot, KDE 5.7 beta 2 neon with no applications/plasmoids/etc running: http://i.imgur.com/7ZuZYyL.png

Over 600MB of RAM occupied when running solely KDE + Konsole (I did echo 3 > /proc/sys/vm/drop_cashes under root prior to taking this screenshot). Stop saying that KDE is lean for fuck's sake - its memory usage is insane. Its speed is abysmal. And it crashes crashes and crashes.

[birdie-github]

KDE5 is bloated beyond measure as seen on this screenshot, KDE 5.7 beta 2 neon with no applications/plasmoids/etc running: http://i.imgur.com/7ZuZYyL.png

Over 600MB of RAM occupied when running solely KDE + Konsole (I did echo 3 > /proc/sys/vm/drop_cashes under root prior to taking this screenshot). Stop saying that KDE is lean for fuck's sake - its memory usage is insane. Its speed is abysmal. And it crashes crashes and crashes.

[rootkovska]

Alright, we don't want religious wars here in our ticketing system. I've just locked the conversation in this ticket, limiting it only to Qubes devs. Again, the purpose of this ticket is to help us implement the task stated in the first message, rather than fuel the endless debate on which DE is best. Thank you.

[rootkovska]

Alright, we don't want religious wars here in our ticketing system. I've just locked the conversation in this ticket, limiting it only to Qubes devs. Again, the purpose of this ticket is to help us implement the task stated in the first message, rather than fuel the endless debate on which DE is best. Thank you.

[marmarek]

Automated announcement from builder-github

The package pykickstart-2.13-3.fc23 has been pushed to the r3.2 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package pykickstart-2.13-3.fc23 has been pushed to the r3.2 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package pykickstart-2.13-3.fc23 has been pushed to the r3.2 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package pykickstart-2.13-3.fc23 has been pushed to the r3.2 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update