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.
- Debian testing (32 bit)
- LXQt 0.9, Qt 5.3, and KF5 packages are taken from Siduction
- Running in Virtualbox 4.3.20
- RAM: 512 MB
- CPU core: 1
- Screen resolution: 1024×768
- Measurement: Open xterm, and type `free -mh` (cache and buffer are excluded)
Memory usage after cold boot:
- LXQt 0.9: 118 MiB
- LXDE: 98 MiB
- XFCE: 107 MiB
- plain Openbox (without running any apps): 70 MiB
Well, for those who still remembered my previous report, the memory usage increased. But wait! All of the DEs, including Openbox, have the same degree of growth in memory usage. So it’s more possibly caused by the upgrade of the system itself. If you see the difference between plain openbox and LXQt, we only added 38 MiB (LXQt 0.8 added 37 MiB). Given that we migrated to Qt5 and added new features, both of which should normally increase memory usage, the current results are reasonable. Seriously, there are still room for more optimizations but we need some time to finish them.
LXQt aims to be a “modern” desktop with some “classic” designs which does not get in your way. We’re not going to clone KDE. Besides, don’t worry about resource usage. That’s the challange for developers and we’ll fight for it.
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.
- Consider compiling lxqt-panel and lxqt-runner with menu-cache support whenever possible:
Menu-cache is a mechanism to cache the generated freedesktop.org application menu so we don’t need to parse hundreds of files everytime. Though you can compile lxqt-panel and lxqt-runner without it and things still work, these two components will generally load faster if you use menu-cache.
- Compile libfm with libexif:
Libfm if the core library of PCManFM file manager. When compiled with libexif support, it can extract the thumbnails created by the cameras which are often embedded in jpeg files. So we can avoid loading the photo and generate the thumbnail ourselves. With libexif, loading folders with many photos will be faster.
- Try to “prelink” your system:
When you launch a program, your system will load it alone with the libraries it requires. Then, dynamic linking will be performed to make these libraries work together. The process could take seconds in some cases and affect the speed of program startup. By using “prelink”, part of the linking/relocation process can be done once and cached; then in the future the dynamic linking becomes faster. It’s tool worth trying if your desktop takes quite a long time to login.
- Avoid GTK+ theme:
Qt developers did a great job and provided a “GTK+” style for theming the Qt programs so they can look like GTK+/Gnome programs when running in Gnome. The magic behind this is simple. Your Qt style engine loads GTK+ 2 and creates fake Gtk UI elements. Then, copy the images painted by GTK+ to your Qt widgets. By using this, you have both Qt and GTK+ 2 theme engines loaded for every Qt program. Not really a big deal since the operations are still fast enough, but if you don’t need a GTK+ theme, don’t use it. Try “fusion” for Qt5 or “Cleanlook” for Qt 4.
- Some notes about gvfs:
Removing gvfs won’t make your file manager faster. PCManFM-Qt does not use it for most of the local file operations. So it’s safe to keep it around since it does not slow down things. We used “gvfs” from Gnome internally for trash can, volume management, and mounting various network filesystems. Yes, the UI is in Qt and its core uses few Gnome stuff. Don’t hate gvfs just because there’s a “g” in its name. It’s a quite good VFS implementation which does not have Gnome dependencies. So don’t remove it just because its name contains a “g”. It provides you some good features, including mounting sftp filesystems or accessing Android mtp devices if you have proper plugins installed.
Generally speaking, it might be a good idea for packagers to add “gvfs” to the dependencies or package suggestion list of pcmanfm-qt.
- Avoid Qt 5.4.0 if possible:
We encountered several weird regression bugs of Qt 5.4 while debugging LXQt. It breaks drag and drop crossing different programs. With Qt 5.4, you cannot drag a file from my file manager to other programs, but it’s not my fault.
(The bug will be fixed in Qt 5.4.1, which is not yet released.)
We’re going to release LXQt 0.9 very soon!
Hope these tips help. Cheers!
After some development, it’s time to release next feature version of LXPanel. The release goals for 0.8 were:
- complete multi-monitor support
- improve and further simplify plugins API
Now that it was done, and numerous bugs fixed along with that, LXPanel has come to release time, which is scheduled in about 2 weeks. We would appreciate all the testing and feedback on it. The fresh sources are in GIT repository, as usual. The changelog since version 0.7.2 is big enough, you can find it in the sources or read online.
I also would like to ask all our translators to come into Pootle and translate it. I would ask to read the Wiki if you didn’t do that lately. Thank you in advance, everyone.
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!
The session manager for LXDE was in long development and it still is. Julien did a lot for it to make it better. It is far from perfection yet but it is usable again and we hope it is a bit better than it was before. Two releases in row – 0.5.0, then fast bugfix next one – 0.5.1.
New release tarball download link:
lxsession-0.5.1.tar.xz – SHA1: 3419802c9e7269093900dd5fd4948acb95dec253
The most noticeable changes since previous stable release 0.4.6.1 (see git log for details):
- Translations updates.
- Added support for reboot and shutdown in LTST client.
- Added support for user switch.
- Added clipboard support, based on Xfce one.
- Added options to launch default applications.
- Rewritten whole lxsession in Vala.
- Implemented a connection to session bus.
- Added ability to change settings by Dbus call, example by keymap configuration.
- Added signal / Dbus for changing window manager.
- Added Dbus method for restarting Xsettings.
- Added Dbus methods for xrandr options.
- Added more details in the desktop.conf example.
- Added GTK, Mouse and Keyboard to the list of settings + Dbus methods to change them.
- Added lxclipboard standalone, and an option to launch it instead of built-in the support.
- Implemented network GUI default application (nm-applet, wicd, etc.).
- Moved in lxpolkit from standalone package.
- Moved in lxsession-edit from standalone package.
- Implemented audio-manager handler support.
- Implemented quit manager support and expose it in Dbus.
- Implemented workspace manager option and expose it in Dbus.
- Implemented launcher manager support and expose it on Dbus.
- Implemented terminal by default support and expose on Dbus.
- Implemented minimal support for inhibition of the screensaver.
- Implemented option to disable autostarted applications on home and system directory.
- Implemented new way of launching windows manager.
- Implemented composite manager handler.
- Rebased lxlock on xflock, and extend it with lightdm and xdg-screensaver.
- Added i3lock support in lxlock.
- Added systemd-logind support.
- Added more options for the disable_autostart option.
- Added an option for screenshot to take only the current window.
- Made lxsession-logout working when lxsession is not running.
- Added lxsession-default utility.
- Added PackageManagerRunning signal and ProxyOption initial commit.
- Increased timeout for lxsession-logout, to make authentification possible.
- Removed conditionnal support for Dbus, it’s now mandatory.
- Added razorqt polkit agent support.
- Added the version to the session name in lxsession-logout.
- Implemented AudioManagerSet.
- Implemented others Get() Set() functions for *_manager.
- Implemented close() and reload() for all Apps.
- Implemented panel control mechanism.
- Implemented a more complex quit_manager.
- Implemented ability to set some custom XDG environment variables.
- Added an ssh-agent option instead of gnome-keyring.
- Added lxterminal conffiles, and enabled the one for xscreensaver.
- Added “support” for libfm in conffiles.
- Implemented Desktop handler.
- Implemented upstart user session option.
- Implemented lxsession-default-apps, the GUI for configuring lxsession.
- Implemented lxsession-db, to build database of available applications by categories.
- Made it possible to set working directory when launching app, and set it for the terminal.
- Added a lxsettings-daemon binary independant from lxsession core.
- Implemented SessionSupport and SessionSupportDetail Dbus interface.
- Removed gee dependencies, use HashTable.
- Fixed lxsession-logout when lsb_release is not available.
- New –disable-gtk flag, which doesn’t build any gtk component at build time.
- Added support for ubuntu appmenu environment variable.
- Added light-locker in lxlock.
- Added support for only reload 5 times applications which are reloaded.
- Added missing man pages for some binaries.
The LXQt 0.8.0 release is now available. It brings with it full Qt 5 compatibility, two beautiful new themes and lots of new features, performance improvements and bugfixes.
Please see the full release announcement on our mailing list.
We are always looking for new contributors. If you are interested in joining us, please take a look at our Contributing guidelines.
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