Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Even though some people often confuse LXQt as a rewrite of LXDE in Qt, this is not true. PCMan, the original author of LXDE, started experimenting with Qt, first by implementing a GUI for PCManFM in Qt. While doing so he wrote up A Guide for Migrating from GTK+ to Qt where he sums up his experiences.
When he released a preview, some people feared that a Qt-based desktop environment would be too heavy and bloated, so he posted about this too. LXDE was written in GTK+2, but times change and GTK+3 came out. Some people thought that GTK+3 was not good, and that a port to GTK+3 would have been rather bloated, but a Qt version wouldn't be.
Short notice: for those interested in numbers, PCMan later created another post about the usage and performance, which you can find here.
At the same time another group of people were working on a Qt-based desktop environment called razor-qt, and eventually the LXDE-Qt and razor-qt people decided to work together and create LXQt. So instead of being a rewrite of LXDE in Qt, LXQt is rather a lightweight desktop environment heavily based on the razor-qt code base and a team consisting of LXDE and ex-razor-qt developers. This same information is stated in a post called In memory of Razor-Qt.
Some distributions still have it categorized under the name LXDE-Qt, for historical reasons that should be now clear. In this post you can still see the name mentioned as LXDE-Qt or LXQt, but now the official name is settled, and it's LXQt
Initially it was developed in Qt4. In June 2014 it got full Qt5 support and since version 0.9.0 only supports Qt5.
Recently it has been switching from using many individually developed libraries to instead use the KFrameworks5 library. Again, some people where afraid of introducing bloat because they thought it would mean including all KDE libraries and dependencies, but once again this has not been the case. KFrameworks5 was actually introduced in an attempt to split the basic functionality from KDE specific libraries and thus make it usable in other projects than just KDE.