However, that is simply not true. Stating something doesn’t make it true. The facts speak a different language, the developement is actually very efficient and constant for what they do: http://lxqt.org/releases/
You seem to either, not understand how big changes on a desktop enviroment are being developed, or you have some other real reason you didn’t tell us about.
3 Versions = 3*The work
Not viable.
If you don’t like whichever UI we use in the end, you may INSTALL whatever you prefer YOURSELF. No harm done.
After 4 years of development LXQT still unusable.
LXQT virtually indistinguishable from LXDE. LXQT is LXDE ported from GTK to QT. What’s the point of this in our time? When this project was born, people just do not like new GTK 3. And today, even XFCE gradually switches to GTK3. https://blog.xfce.org/
LXQT not always work after installation and there are quite a few bugs.
App uniformity… The history behind that is that @bnvk used to lead for Qubes usability. Generally to improve usability, once has to reduce the mental load for the user. Makes sense. His view was, that users who used the Fedora template who learned how to use applications there, be it NetworkManager or kate text editor, would benefit if they must switch to a Debian template for some reason, if they were presented with the same default applications.
(“Just install it.” doesn’t cut it from usability view. Mental load. Knowing the names of applications used beforehand, how to install them with Qubes difficult installation in TemplateVM and required AppVM reboot…)
Similarity to between Non-Qubes-Whonix and Qubes-Whonix, similar package dependencies (includes app uniformity between Non-Qubes-Whonix and Qubes-Whonix) makes it a lot simpler for me to maintain both, Non-Qubes-Whonix and Qubes-Whonix. Any fix/change on the one will likely work for the other also.
It’s questionable how much of these workarounds broke after jessie -> stretch version upgrade.
xfce4 on the other hand does not seem to require any workarounds since it is modular by design. In its minimal installation (–no-install-recommends xfce4) for example it seems like it does not even come with powersaving. The only workaround that apparently is required is disabling that default bottom toolbar.
I am still investigating which path seems more feasible.
IF using XFCE. If not lightdm… What is the most XFCEish login manager? It doesn’t have its own login manager? The login manager required for Whonix apparently does not really matter. Only feature so far that seems required:
a config file that can be dropped into a .d folder to enable auto login for user user (good usability feature for Whonix in VMs)
So perhaps xdm or lxdm? Don’t know yet if they support that feature. TODO: research
Another option might be using no login manager at all. Perhaps using startxfce4 (IF using xfce, similar otherwise) / startx. But:
probably better to avoid editing /home/user/.xinitrc. (Always problematic to write into the home folder as well as always problematic to use something other than .d config snippets.)
Therefore I thought it is a good idea to use a display manager that does not get removed from Debian in stretch + 1 to avoid double work and migration issues.
Another topic we should look at is wayland support. GNOME and KDE are forerunners in that respect. XFCE is still on the way to porting to GTK3 which it needs for any basic wayland support. GTK4 is being planned right now. So they are way behind.
Wayland means getting rid of a huge security hole that is X. At least in Stretch X doesn’t run as root anymore but still.
I won’t be copying in links to git commits related to stretch support as these are too many in too many repositories. However, one can follow them by having a look on my github profile [and/or by staying on top of Whonix source code changes]. I may generate progress report of this month at the beginning of next month.