It has always been rumored that Qt is bloated so programs written in Qt should be bloated. Some even argued that the LXDE developers made a wrong decision on the migration to LXQt.
Why not replace the assumptions with some experiments?
In fact, LXQt 0.11 even uses slightly less memory than XFCE (with gtk+ 2). After cold boot, LXQt uses 112 MB in the testing environment. Continue reading “Benchmark: Memory Usage: LXQt desktop environment vs XFCE”
There has long been needs for a simple Qt frontend for pulseaudio-based audio mixer. So I ported the gtk+ version pavucontrol program to Qt5 for use in LXQt. Continue reading “Qt5 port of Pulse Audio Volume Control (pavucontrol)”
Since the release of LXQt 0.9 several days ago, many people are curious about its memory usage since in the release announcement we mentioned the use of two libraries from KDE framework 5. Don’t worry! They are just “pure Qt libraries” without other KDE dependencies (Thank you KDE guys!). Good engineers always base their design desicions on careful analysis, experiments, and measurements, not politics. If a library works pretty well, it does not really matter where it comes from or it belongs to which camp. If it’s free software and it’s suitable for our need, I’d say “use it”. Here are some numbers of memory usage after cold boot. Continue reading “Memory Usage of LXQt 0.9”
As we’re going to have a new release for LXQt 0.9, I’d like to provide some performance tips for users and packagers. Continue reading “LXQt Performance Tips”
Although people often compare LXDE and the “so-called” Qt port, LXQt with each other, they are actually from different code bases.
The most parts of LXQt are actually built on top of razor-qt, a lightweight Qt-based DE with the same philosophy as LXDE. We reorganized the source code of razor-qt and removed unused pieces. Then we ported several LXDE components to Qt and also developed some new ones. Hence it’s more the merge of developers than the merge of the actual source code. That’s why they have slightly different feature sets. Without the work of razor-qt project, we can’t have LXQt now. Its developers deserved the credit. Since the story is too long for the tiny “About” dialog, I wrote the blog post here to thank their contributions.
Long live free software!
Yes, it’s about the gtk+ version LXDE, not LXQt.
Previously, razor-qt and lxde project merged and formed LXQt project, which just had a 0.8 release. Though the original plan was to migrate to Qt, this does not mean that LXDE is dropped. As many of the users have noted, many LXDE gtk+ components got updates recently. LXDE is still actively developed and maintained by the developers lead by Andrej N. Gritsenko (LStranger) and as long as gtk+ 2 is in use, I believe that they’ll keep working on it. We even got some patches for gtk+ 3 recently. Yes, gtk+ 3. This does not mean that LXDE is going to use gkt+ 3, but it’s a clear indicator that LXDE is not dead. If you’re not a fan of LXQt, don’t worry, you can still use LXDE. Also I want to say “thank you” again to LStranger who work really hard to keep LXDE so others can have some time to focus on LXQt while keeping our promise to the users.
About LXQt, the 0.8 version is quite stable and we have the required features, but of course it’s not good enough and have room for improvement. We’ll keep working on that, too. For the part I’m responsible for, the file manager, I’ll try to add the features that exist in the gtk+ versions but abscent in the Qt port. Also, I’m going to do more bechmarks for LXQt recently. Other developers are working on code cleanup and removing dependency on X11 so we can move to Wayland later.Both LXQt and LXDE are actively developed. Stay tunned! 🙂
After the first official public release 0.7, the LXQt team is working on making it better. Our recent focus is fixing existing bugs and migrating from Qt4 to Qt5, which is required if we want to support Wayland. Now we had something to show. The latest source code in our git repository can be compiled with Qt5. by just passing -DUSE_QT5=ON flag to cmake. Building with Qt4 is still supported until the next release, but later we’ll focus on Qt5.
Recently we also got some patches from the community and also a new developer joined us. We’re now fixing some remaining bugs. Hopefully we can have 0.8 release soon. 🙂
It’s known that system admin tools for LXQt were lacking.
This is no longer true. A new component lxqt-admin landed int our git repo. Please see the screenshots. 🙂 These are “desktop-independent” pure Qt tools based on system-tool-backends.
lxqt-admin-time: Tool to configure date and time.
lxqt-admin-user: Tool to manage users and groups.
We know that LXQt is not good enough, but it will getting better and better. Long live LXQt, the classic desktop!
After the initial release of LXQt, I found that there is a FAQ. How’s the memory usage? Will it become a bloated memory hog because of Qt? Here are some numbers for you.
My test environment is the latest Debian stable installed in VirtualBox with 512 MB of RAM and 1 CPU core assigned. After cold boot, the memory usage is as follows.
- Plain Openbox only: 58 MB
- XFCE: 89 MB (with default configuration of Debian. This value will increase after xfce is ported to gtk+ 3)
- LXDE (gtk+ 2 version): 78 MB (add 20 MB to openbox)
- LXQt: 95 MB (add 37 MB to openbox, still has some room for optimization)
The screen resolution is 1280 x 1024. So a wallpaper roughly used 1280x1024x4 bytes = 5MB of RAM. If you don’t set a wallpaper, this number can be lower. Besides, this is a virtual machine so some special modules for vbox are loaded. I turned off printer service and network-manager applet since they’re not used.
Yes, the memory usage slightly increased, but the difference is really negligible. Moreover, LXQt has more features, such as a better program launcher and new power management stuff.
Apparently the gtk+ 2 version uses less memory, but we cannot use gtk+ 2 forever. It’s not a secret that gtk+ 3 is not a memory saver. So, I’d say Qt is really not that bad.
Why yet another DE? Why can’t you do something more innovative? I think the answer for this FAQ is simple.
- Nowadays everything goes mobile and touch, but we still saw unmet need for a classic desktop environment. Otherwise, Windows xp should have been killed years ago and Windows 8 should have high market share now.
- In the history of free software, we see forking everyday, but (successful) merging rarely happened. We want to prove that it actually works. People can focus on what they can share with each other, not how they are different.
The following is my personal opinion (not on behalf of other LXQt developers)
Seriously, if a 17 MB memory usage increment can buy us faster development, more active developers [Figure 1], more contributors, and a healthier upstream community, that’s definitely worth it. When I say healthier, I mean those who do not hold a “Follow our way, or go away!” attitude. This is just as important as other technical considerations when you choose a toolkit.
Many people like to argue that Qt is not C++ since it requires a pre-processor. Did anyone tell you that Gtk+ actually uses a preprocessor, too? Check the manpage of “glib-genmarshal” please. Without this pre-processor to generate some code for you, it will be awfully difficult to add signals to your GObjects. That’s not C language, right?
It does not really matter for users what toolkit you’re using given the final result works. Let’s save some time not arguing which is better and focus on what we can do with them. 🙂
Figure 1. A screenshot from Google Trend
Recently, PC-BSD developers just reminded us that there is an unmet need for a Qt desktop for BSDs. So, here you go. 🙂
As stated earlier, we’re not really Linux-centric. We support Linux better simply because we’re Linux users. Now with some help from several FreeBSD users, things can be different. I installed FreeBSD 10 in Virtualbox last week. After reading some docs and fighting with it we fixed some broken makefiles. Now the major components should work as expected.
Of course, there are still some Linux things which do not work (yet).
- lxqt-powermanagement: this requires upower
- lxqt-policykit: I haven’t test if policykit works for FreeBSD
- volume control applet: currently it only supports ALSA and PulseAudio. I’m going to implement OSS support for it.
- removable device applet: this requires udisks
- Reboot/Shutdown from the menu: We use logind/consolekit now. Any good alternative for BSD?
Other parts should just work. We hope that we can improve FreeBSD support more. Of course, help from the BSD community is needed.