Category Archives: Development

LxImage-Qt image viewer

The image viewer of LXQt (LXDE-Qt) has been improved much recently. Here is the latest screenshot.


Here is a brief list of recent changes:

  1. Printing support added
  2. Thumbnail preview (the bottom pane on the screenshot)
  3. Built-in tool to take a screenshot
  4. Slide show support
  5. Improved fullscreen support
  6. Improved preference dialog
  7. File properties dialog added

The image viewer is fully functional and usable now. At the same time, other LXQt components are getting some more updates as well. Though there are no formal releases of LXQt yet, the latest code in git already works pretty well. Please stay tunned! :-)

PCManFM/libfm string freeze and beta period

An unusual update. Andriy posted a note to the pcmanfm development list about the upcoming release of PCManFM and libfm components. He has been hard at work closing bugs and adding features and in hopes to release in time for the next Ubuntu freeze we’ve now entered soft string freeze. This means that no new features will be added and most strings are stable enough to be translated. In about two weeks a solid freeze happens and no strings will change (hopefully we’ve found all hard to translate cases by then). If you want to help test drive the new code (build from source: pcmanfm-1.2.0-beta1.tar.xz libfm-1.2.0-beta4.tar.xz) or add to the translation effort we do welcome that.

If nothing very evil happens a new and shiny PCManFM 1.2.0 will be out early February.

LXAppearance ObConf plugin 0.2.1 released!

The OpenBox Configurator plugin to LXAppearance was just released. Grab the file from sourceforge.
This release is mostly a maintenance release, making sure the code base builds and keeping it in sync and working with both OpenBox 3.5.0 and 3.5.2.

lxappearance-obconf-0.2.1.tar.gz, sha1: 13ef5ab481f72b9782a22486df9b133554af92fa

1b3ebd4 – config.h should be included by src/preview.c to get its defines.
c9d5ca6 – Make it compilable with both Openbox 3.5.0 and 3.5.2.
06fe6ce – Update to build with newer autotools
2449b84 – Keep depending on openbox lib 3.5, the version didn’t change with openbox 3.5.2
c8f0cd4 – Fix building with openbox 3.5.2, and increase the depends (fix 3614951)

Build lxde-qt from git source: an updated guide

Since the original LXDE and razor-qt projects decided to merge the effort and work together on the same project, we formed lxde-qt, or lxqt for short. Some effort was made to merge existing codebases and components, but things are still in an early stage so there is no public release yet. For preview purpose, here is a guide for the brave to build lxde-qt from git source code. Please note, since this is a work in progress, things are subject to frequent changes. So be prepared and don’t expect too much. Things will improve, but it takes time. :-)

Please don’t use it in a production environment. It’s not ready for daily use yet. You have been warned.

menu-cache 0.5.1 released

The backend library to read application menu files has been released with mostly minor changes.

  • Fixed build on systems where MAXSYMLINKS isn’t defined.
  • Fixed menu-cached crash in some rare cases.

menu-cache-0.5.1.tar.gz, sha1sum: 9580ee33966d112ed421f2c523b0730ad69e109d


c45ff3e – fix memory corruption when freeing cache->files
0fe2a66 – fix typo in menu-cache-gen.c
6a16c51 – Fix build on debian hurd-i386: there is no MAXSYMLINKS defined there.
506d35a – debian: libmenu-cache-bin in fact conflicts with libmenu-cache[12]
e53d0b3 – debian : – Force removal of libmenu-cache2, since it may have provide SONAME 3 library – Use SONAME number in the .install to only install the good version of the library (and fail on SONAME bump)
a424120 – debian: Enabling hardening.
515d722 – debian: Correcting libmenu-cache1-dev to oldlibs/extra.
ff605d7 – debian: Changing libmenu-cache2 into libmenu-cache3 due to ABI change.

Obconf (Openbox Config Tool) is ported to Qt

Since we’re using Openbox as our default window manager, we need a GUI way to configure it. Previously, we have a GUI config tool for OpenBox named obconf, which is based on gtk+ 2 and libglade. However, since we plan to use Qt, and gtk+ 2 is no longer officially supported by its upstream, a Qt port is wanted.
Hence, as part of LXDE-Qt project, I started a Qt port of obconf and that’s obconf-qt.
It’s a pure Qt program so it works as well outside LXDE-Qt. It’s also useful for the upcoming razor-qt 0.6.

Please test the source code in git:
> git clone git://----escape_autolink_uri:5acf69934b3dbf516eae5a6e8c914e7f----

Or, browse the code online:;a=summary

Most of the original features are already been ported to Qt.
What still does not work:
1. font settings.
2. dock settings.
3. preview of themes
Other stuff should work as expected.

If anyone is willing to help, please contact me.
Thank you.

No, LXDE-Qt is not bloated

After posting a preview screenshot for LXDE-Qt, I got quite a lot of feedback from various sources. Generally the responses from the users are positive, but there are also some people saying that LXDE is no longer lightweight.

Please, in the free world we’re all friends and let’s not spread FUDs to hurt each other. I’m not going to respond to groundless accuse or get involved in toolkit wars. Just see the screenshot.

This screenshot is done for a cleanly installed Debian testing system running LXDE-Qt after a cold boot. The Qt theme engine used is “CleanLook”.

The command “free -h” shows that 252 MB is in use. However, most of the space is used for buffers and caches. After excluding caches and buffers, the memory usage is 91 MB. On the same machine, LXDE gtk+ version uses 86 MB. Will you call this “bloated”? Please note that I open “lxterminal”, a GTK+ 2 terminal emulator, to execute the “free” command. That means doing this also loads GTK+ so the actual memory usage should be lower than this. Besides, I’m using zh_TW locale since I’m from Taiwan and we use traditional Chinese here. That means, I also have Chinese fonts and input methods loaded in the memory. If you’re a western user, you probably don’t need them and can save a little bit here.

By default, similar setting under Ubuntu will use around 200 MB of RAM.  That’s caused by differences between distros, not the bloat of LXDE. So, please stop spreading unfounded FUDs. Qt is designed for use with embedded systems and cell phones. How fat and resource hungry can it be? It’s the way you use it that really matters.

Delivering a good lightweight desktop is always our goal no matter what approach we’re using. So stay tunned and be confident.

LXDE-Qt Preview

Many users have read about our recent Qt-related work in prior blog posts.
The GTK+ version of LXDE is still under development, but we did some experiments with Qt, too. Now I have some things to show you. :-)
Here is a preview screenshot for LXDE-Qt.

At the bottom of the screen is lxpanel-qt, the Qt port of lxpanel. Now it basically works, but it’s still rough and needs much polishing. Besides, there are no GUI configuration tools for it yet. Editing the xml config file manually is needed. Later there will be preferences dialogs as the old gtk+ version of lxpanel. Most of the major applets already work. However, don’t expect too much!
It’s still a work in progress and it can be better in the future.

In the middle of the screen is PCManFM-Qt, the Qt port of the PCManFM file manager. It looks very similar to the original gtk+ version. The desktop wallpaper and icons are also managed by PCManFM-Qt, just like what the gtk+ version does.
The memory usage of PCManFM-Qt is slightly higher than that of the gtk+ 2 version, but the difference is not very significant. The overall performance is similar to the original gtk+ 2 version. Now it has most of the features of the original one and is almost ready for daily use. \o/

On the right side of the screen is the new Qt-based image view, LxImage-Qt.
It’s not really a port of the original gtk+ GPicView. I regard it the successor of GPicView in the Qt world. It works better than GPicView and is as fast.

Most of the work demonstrated in the screenshot is still in our git repository and is not ready for a new stable release, but there is really much progress and LXDE-Qt is no more a plan or a concept. It’s a real project that gradually shapes.

OK, back to what most user will concern, the resource usage.
To be honest, migrating to Qt will cause mild elevation of memory usage compared to the old Gtk+ 2 version. Don’t jump to the conclusion too soon. Migrating to gtk+ 3 also causes similar increase of resource usage.
Since gtk+ 2 is no longer supported by its developer and is now being deprecated, porting to Qt is not a bad idea at the moment.
Besides, the slightly higher memory usage is still acceptable for most of the existing old machines. The real resource usage may differ a lot among different Linux distros. For example, Ubuntu-based distros running LXDE tends to use more memory than ArchLinux-based ones. So more testing and real benchmarks are needed before making a conclusion on this.

Anyway, glad to share with you what we already done. Hope that you like it. :-)
Long live LXDE!

Edited on 2013-07-04
Answer the questions in the comments of this blog entry:

  1. Cooperation with razor-qt is going on. We subscribed razor-qt google groups and discussed about possible cooperation earlier. Currently, the ported LXDE components are designed with Razor-Qt in mind. For example, PCManFM-Qt and LxImage-Qt will reads razor-qt config file when running in razor-qt session. We’ll try to keep the interchangeability between the two DEs. Further integration is also possible. Actually, I personally am running a mixed desktop with LXDE-Qt + Razor-Qt components on my laptop. Components from the both DE blends well.
  2. The version of Qt supported now is Qt 4. I’m going to skip Qt 5 and wait for Qt 5.1. Qt4 and Qt5 are compatible in many areas and porting to Qt5 should be easy in most of the cases. Unfortunately, this is not the case when you use X11-related stuff. Qt 5 removed many X11-related APIs and there are no direct equivalent methods. So the porting is not painless for desktop environments. In addition, some specs are designed to work with X11 only, such as the EWMH/NETWM spec and Xsettings spec. To port to Wayland, these problems need to be solved first. Gnome and KDE guys will fix them so we can just wait. Then why Qt 5.1? Because Qt 5.1 added back the once-removed X11-related APIs. So porting from Qt 4 to Qt 5.1 should be the most smooth path. It takes time for distros to adopt Qt 5.1, though.

Please use PCManFM-Qt git version for now.

As many people know, a Qt port of PCManFM is under heavy development. Although we released PCManFM-Qt 0.1 previously, it contains some bugs and memory leaks. Most of the issues are already solved in the latest source code in our online git repository and will be available in the next release. However, the new code depends on the latest libfm 1.2, which is not released yet. Due to the small delay of libfm release, the new release for PCManFM-Qt cannot be made at the moment. Brave users who cannot wait for the final release are encouraged to try the latest git version of libfm and PCManFM-Qt to get the latest features and fixes.

Here is a short list of what’s in the latest git version (and will be in the next release):

  1. Fix several important memory leaks in version 0.1
  2. Some optimizations for memory usage and speed are done
  3. Full thumbnail support (can show thumbnails for image files and other formats with external thumbnailer installed)
  4. Extract thumbnails from EXIF data of jpeg files (via libfm 1.2)
  5. Optimize column widths of detailed list view automatically
  6. Correctly handle desktop icons when a work area is set
  7. Detects icon theme automatically according to current desktop environment. No need to set an icon theme manually in LXDE, XFCE, Gnome, and Razor-Qt.
  8. Some other small bug fixse

The current code of PCManFM-Qt in the git repo is nearly ready for daily use. The memory usage and overall performance are acceptable, too. When Andriy finishes libfm 1.2 and makes a new release, I’ll make one for PCManFM-Qt at the same time. Before that, users are encouraged to try the git version.


> git clone git://

For compiling the latest code in git, you also need the git version of libfm and menu-cache:
> git clone git://
> git clone git://

Have fun!

A Guide for Migrating from Gtk+ to Qt

Since I started learning Qt recently, I noted some issues when trying to port Gtk+ programs to Qt. There are tons of tutorials for Gtk+ and Qt, but a guide for porting is lacking. Most of the articles comparing Gtk+ and Qt did not go into detailed issues people will encounter during coding.
To help people porting their Gtk+ programs to Qt, I just started a wiki page documenting what I’ve learned so far.
Currently it provides a long table listing equivalent Qt classes for
commonly used GtkWidget classes. Since I cannot find a similar list with Google, I built one. This is useless for experts, but it’s very handy and helpful for Qt beginners who already know Gtk+. The mapping between Gtk+ and Qt classes is not yet finished, but I’ll try to make it complete soon.
I also documented things you need to know to safely mix glib/gio/GObject code with Qt. Later I’ll add docs describing how the translation systems differ.
I hope that developers interested in this topic can help edit the wiki
page to make it more complete and free from errors. It’s still a work in progress but I hope it helps someone as more and more people are using Qt and some more LXDE components *might* get Qt ports later. BTW, since Ubuntu guys is moving toward Qt, this also helps them.