Category Archives: PCManFM

Volume Management Without Gvfs is Possible Now!

As I stated in previous posts, I’m doing direct UDisks support for PCManFM/Libfm. Now I have some things to show.

It now correctly supports different kinds of devices without GVFS. However, LUCKS devices are not supported because I don’t know how to do it. In addition, I’m not sure if LVM or RAID are displayed in proper way because I don’t have them for testing, either, but mostly used storage media for desktop PC Or laptop should be well-supported.

Here is a design decision to made: Should we show partitions reported as “system internal” by UDisks? UDisks consider them internal to the system and asks us to hide these partitions. So that’s why you don’t see some partitions in GVFS since it follows the direction of UDisks. Last release of libfm/pcmanfm does this, too. Should we ignore that and display all partitions just like what the old 0.5.x series do?

Anyway, volume management without gvfs now works. Hooray!
Now, it’s time to clear the bugs on the bug tracker. Later, when there is spare time, it’s also possible to move udisks of PCManFM to a separate gio module, so all gio-using programs, even XFCE, can use it without gnome.

Special thanks to Mihai Militaru who made some donation to the development of PCManFM and libfm through my PayPal account. If you want to help the development, too, feel free to donate via PayPal. My account is


PCManFM 0.9.1 + libfm 0.1.1 Alpha

Today, new alpha releases of PCManFM and libfm were made.

Again, let me show you the screenshot first.

Here are highlights of this release:

  1. Auto-mount for removable devices and and “Auto-run” dialog. (Finally we have this!)
  2. Support ‘menu://applications/’ to show installed applications in pcmanfm. (needs lxmenu-data) (reported to be a little bit buggy?)
  3. Support ‘menu://applications/DesktopSettings/’ to show configuration tools. This just acts like control center. (only when you have lxmenu-data installed)
  4. “Open in terminal” now works for folders on desktop
  5. “Create New” is working on desktop.
  6. The color of location bar is changed when pcmanfm is executed with root user.
  7. Fix command line argumnent-related bugs.
  8. Fix sorting related bugs
  9. New configure option: –enable-debug
  10. Some minor bugs were fixed.

Please get it heavily tested.


PCManFM 0.9 Alpha is released!

After endless waiting, here comes the first public tarball release of next generation PCManFM.
But don’t expect too much. This is an Alpha release. :-)
Everybody loves screenshots. This is PCManFM 0.9.0 alpha running under LXDE with its desktop manager turned on.

There will be 1.0, but before it become stable enough for production use, let’s call it 0.9.

Actually, 0.9.0 is not a new version of PCManFM. It is a whole new total rewrite and redesign from scratch. So its code base is totally different from the old PCManFM 0.5.x series.

Major improvements:

  1. Have GIO/GVFS support but “still keep original speed” and memory usage is still acceptable
  2. Seamless remote filesystem access such as sftp and smb (provided by gvfs)
  3. Trash can (provided by gvfs)
  4. Much better designed configuration dialogs
  5. Much better thumbnail support
  6. Better wallpaper handling
  7. Better drag and drop handling and also support X direct save
  8. Basic auto-mount (provided by gvfs)
  9. Better application chooser based on applications menu installed on the dsektop system
  10. The core part is moved to a separate lib called libfm, which can be used by other programs
  11. Much better structure of source code, so future hacking is easier
  12. Better configurability
  13. and more…

Please give it heavy tests. This will be the default file manager in next generation LXDE.
So quality and usability are extremely important.

Grab tha tarballs now!


Current status of libfm and PCManFM

As usual, let’s begin with the latest screenshot.

The latest libfm screenshot on 2009-09-13

The latest libfm screenshot on 2009-09-13

Some highlights:

  1. The side pane now correctly display volumes.
  2. Mounting of removable devices now works out of the box. Just click on them in the side pane.
  3. Bookmark items in the side pane are now correctly updated whtn your gtk+ bookmarks got changed by other applications.
  4. Some bugs have been fixed.

Some notes on the volume management support:
This is achived with glib/gio, which calls gvfs. Unfortunately, gvfs currently has calls to ‘gnome-mount’ hard-coded in it and there is no way to override this bizaare behavior. So without gnome-mount, mounting doesn’t work. However, the developers of gvfs is now moving toward including mouting support in gvfs itself (by using libgdu and DeviceKit) and deprecating the use of gnome-mount. Then this will become no issue in the future. In addition, I think our move from HAL-based mouting in the original pcmanfm to glib/gio/gvfs is quite a correct decision. People on are now trying to break backward compatibility (and also break others’ programs) “again”, and disk related parts HAL are going to be removed later. So existing applications which use older HAL, including pcmanfm and some applications in XFCE, will be broken in the near future. So, we don’t seem to have other choice…

Exciting improvements in libfm and PCMan File Manager

Recently libfm, the core of next generation file manager, underwent heavy development and rapid changes. Here are some exciting highlights.

  1. The repository was completely moved from svn to git now.
    You can grab the latest source code with following command line:
    git clone git://
  2. Drag and drop now works! You can even drag and drop between two different remote filesystems.
  3. Clipboard handing is greatly improved. Files cut/copied in GNOME/Nautilus, XFCE/Thunar, and even KDE/Dolphin can now be correctly pasted in libfm.
  4. Now libfm correctly mounts remote filesystems on demand.
  5. Basic bookmark support was added.
  6. File associations (default application for file types) can now be changed in properties dialog.
  7. Partial auto-completion for path entry
  8. Moving files now works, but error handling is not yet implemented.
  9. Now errors are correctly reported when the loading of folders failed.

Now we’re more and more closer to our goals, to build a modern, fast, and lightweight file manager supporting gio/gvfs for LXDE. After the core library, libfm, is finished, the development of the next major release of PCManFM will be started. This will fix various old bugs in the original 0.5.x series and provide full access to remote filesystems. So stay tunned and get it well-tested!

Last but not the least, developers are wanted! Please join us if you like LXDE and you know gtk+ and gio programming in C language.

Recent Advancement on libfm (core of next generation pcmanfm).

Everybody loves screenshots!

Libfm can access remote filesystems now.

Libfm can access remote filesystems now.

Look! It’s sftp://.

By utilizing glib/gio and gvfs, now libfm can access remote filesystems supported by gvfs. Currently there is no auto-mounting. So when testing libfm, you need to mount the filesystems with gvfs-mount manually. However this should work once libfm is finished.

The current source code in svn repositoy can already work as a good filesystem browser. However other parts are not yet finished so it’s not fully working. Anyways, browsing local and remote filesystems already works.

For those who claimed that gio and gvfs are heavy and slow, please try libfm. Although it uses gio/gvfs in several parts, the speed and memory usage are still quite acceptible. Sometimes programs using gio and gvfs can be slow, but libfm is not slow at all. Nor will the next generation pcmanfm be slow. Please give it a try and you’ll see it.

The project page of libfm:

Next generation PCManFM is now under development!

Everybody loves screenshots!
This is the little demo program included in libfm demonstrating the functionality of libfm – the core of next generation PCManFM.


Due to some limitations and various hard-to-fix problems in the original PCManFM, a new project is started to work on a fresh rewrite of PCManFM. Now I’ve created a project named libfm. It’s a gio-based library used to develop file manager-like programs.

This will be the core of next generation PCManFM. Currently the work that has been done is in branches.  It contains a simple demo program named libfm-demo. Most of the menu items in this demo program are not working.

Currently it can only listed the files on your disk. No other operations are avaiable since they haven’t been written yet. I’ll work hard to finish it and hope the first really usable release can be made before 2010.  The project is in its very early stage, but you can see the progress here.

After finished, the lib will be separated into two parts, libfm and libfm-gtk.  The former is a generic non-gui library, and the later provides useful file manager-related widgets.

The roadmap of PCManFM is updated, too. Those are the tasks to finish.

If someone is willing to help, that’ll be appreciated. Help is wanted!!

Please vote for the future of PCManFM.

Please visit the following URL to vote for the future of PCManFM.

Hi, all LXDE users,
After more than two years of development, now LXDE became very active and more and more mature.
Recently, some developers joined us, and many new changes were made in our svn repository.
However, the core and the origin of the desktop, the file manager, PCManFM, didn’t get improved for a period of time.
There are originally some plans, but due to dramtic changes in recent GTK+/glib/gnome/, we have a dilemma now.
One thing that I hate Linux most is they are always breaking backward compatibilities and trying to ruin others’ work.

The volume management parts is now broken due to incompatibility changes in HAL.
Now many modern distros are using PolicyKit and force the use of it with HAL.
Unfortunately, some related things are now GNOME-specific, and more or less depends on gnome. KDE guys are now trying to develop their own equivalent tools, and its only availble in the latest KDE. The simple gksu, sudo, or other similar tricks no longer works correctly without gnome stuff.

Thunar and XFCE uses their own libexo and exo-mount along with some xfce libs to handle volumes. Not sure about how it handle PolicyKit.

So, a gnome-free clean solution to this is not quite possible at this time.

Second, since glib/gio is now extensively used in gtk+ itself, the GtkFileChooser (Open/Save dialog) now uses gio, too. So, shifting to gio seems to be a reasonable and inevitabe move.
GTK+ already depends on it, so there is no way to prevent the use of gio.

However, though they claimed that gio works without gvfs (fallback to local filesystem), that’s not the truth. File copying, HAL-based volume mouting, and even trash bin…etc don’t work at all without gvfs, which has many dependencies. Using gio extensively means that you’ll need gvfs, too. Current gvfs depends on some gnome stuff, such as gnome-mount and gnome-terminal, gconf…etc, and those parts are “hard-coded” in gvfs. So they are not changable.

Bookmarks in GTK+ file dialogs now supports remote URLs. If we don’t use gvfs, we will be incompatible with gtk+ itself. Current PCManFM doesn’t recognize those remote URLs, and this causes problems with more recent gtk+/gnome programs. No matter you like it or not, gtk+ is now depending on gio, which requires gvfs + gnome stuff to be fully functional.
Yes I know it still work without gvfs, but most of the advantages of gio won’t be available without gvfs. Removable devices are not mountable in GTK+ file dialogs without gvfs, too.

Besides, some parts of gio are not efficient and uses much more memory in many places.
Hence using gio along with gvfs (plus its gnome dependencies) seems to be inevitable in the future.

Another solution will be using thunar-vfs implemented by thunar. The advantage is quite apparent. Thunar is very fast and the memory footprint is small. The APIs are easy to use and provides more sophiticated interface to developers. I already reviewed its code, and it’s well written, commented, and optimized. The quality is very good. The author of thunar, Benny, is one of the best gtk+ programmer I’ve ever seen in the free world. However, thunar-vfs depends on several XFCE libs. Besides, in some distros, it’s bundled with thunar. It has no support for remote filesystems, and the compatibliy with gio/gvfs is hence questioned.

In addition, there are some XFCE developers trying to migrate thunar from thunar-vfs to gio.
I think they made a huge mistake since both the design and performance of thunar-vfs are better than gio. Thunar-vfs, however, doesn’t support remote filesystems. This can be compensated by using FUSE-based implementations. Originally this is also the plan of PCManFM, and was once tried in 0.4 branch. Unfortunately, due to lack of good-quality and GUI-friendly FUSE-based remote filesystem implementations, this was removed in 0.5. Moreover, using FUSE-based implementation can only provide POSIX interface to programmers, which is a little bit restrictive to desktop applications.

Apart from those two existing vfs implementations, there is no existing equivalence.
Our own vfs implementation in PCManFM is quite primitive and a little bit buggy. Besides, we’ll be lagged behind specs since it’s mainly controlled by GNOME and KDE guys.

Before this important issue is solved, further development of PCManFM will make the shift to other VFS more difficult. So a decision should be made here, and we can continue the development of the file manager.

Options are:

1. Shift to GIO + GVFS, and accept the inevitable GNOME dependencies it brings since many gtk+ apps also need them, and we can get full support to remote filesystems with good compatibility with gnome/gtk+. Future breaks in backward compatiblity won’t affect us since those dirty works were maintained by GNOME developers. Then we can focus on the design of desktop environment, not on fixing broken compatibilities. Since XFCE seems to be shifting to GIO, maybe it’s inevitable.

2. Shift to thunar-vfs, and accept the inevitable XFCE dependencies. Then handle all remote filesystems with FUSE-based solutions. However, if XFCE adopted GIO/GVFS in the future, we’ll lose all the supports. Besides, I’m not sure if XFCE solutions can be compatible with future GNOME. Especially when PolicyKit, ConsoleKit, and more things are widely adopted by modern distros, and they are more or less gnome-related.

3. Copy the code of thunar-vfs, and create our fork. We can do what we want, and try to minimize XFCE dependencies. However, it’s difficult to keep sync with XFCE/thunar, and removing those XFCE dependencies is not quite easy. Besides, this can make XFCE guys angry since we only steal their code and rename all the libs, then strip their XFCE dependencies. In addition, our improvement cannot get into XFCE source tree. So duplicated work will be done by both project, and we’ll become out of sync grdually.

4. Keep current work, and try to fix all bugs (Not quite possible). If specs changes (happens frequently), we just rewrite our programs to fit them (a great waste of time and this definitely blocks our development in other areas). This could even make our work totally broken if they change something in the spec or the future versions of gtk+/gio. Then we’ll be busy fixing broken compatability all the time.

So, it’s a important and difficult decision.
Personally I’ll suggest adopting GIO/GVFS and accept its deps, then try to keep our program lightweight (This is still possible). This will make PCManFM heavier and slower than current implementation, but since the current code is buggy and not functioning well…. It’s not a fair comparison anyways.
Any thoughts or better ideas?

If we start using gio/gvfs, that doesn’t mean we’ll be slow just like current nautilus.
On the contrary, if we use ready-made VFS library like gio, we can focus on what we really want to do. Of course, this includes doing optimizations and adding handy new features.
In the long run I think this is more constructive than fixing old bugs and broken compatibility all the time. I believed that judicious use of gio/gvfs can still make things lightweight and fast “enough”. “Enough” means, it won’t be the fastest, but it will be acceptible by the users.

People think that GTK+ is slow, but we prooved that you can still develop fast and light apps with it. So, I think we can do well with GIO/GVFS or thunar-vfs, too. Having some inevitable dependencies on other desktop environments doesn’t mean that we’ll be slow. That’s totally dependent on how we use them. After all, many other existing applications are using those libraries,too. So it’s not possible to get rid all of them on modern distros. Since they are already there and is now an essential part of the system, why not make judicious use of them? :-)

For me, provided the performance is still good and the memory footprint is still acceptible,
some (minimal) gnome or xfce dependencies are acceptible. How about the opinion of our users?

LXDE now accessible in local languages for 685 million people

As of yesterday the LXDE and PCManFM repositories are updated and all translations synchronized with there sources. It was a huge task to complete and lasted for almost 5 straight hours but here are the numbers!

LXDE is truly a international project with complete or started translations for most continents (Africa is laking but we are trying to fill that gap too!), as of now we have 35 languages in “official” support (including English). Of these 35 only three are 100% complet at the component level – big ups to Polish, Spanish (Castilian) and Swedish. Together with English these translations make LXDE accessible for about 685 million people (that’s a low count not including those who know and can use English as a second language).
In close range of reaching 100% complete we find Danish, French, Slovenian and Ukrainian at over 90% (adding 120 million speakers to the total).

Since the last update a month ago we have seen two new languages sky rocketing, Slovenian and Lithuanian, a huge effort by the Lithuanian translator and now only LXPanel is left out. For Slovenian we have a sole translator doing a huge work just the last week and I am confident it will be complete soon. At the Pootle server I have added PCManFM as a translateable component for the LXDE project, it is hooked with write access to the SVN server for that project The LXPanel Plugins have been added as a seperate “project” in Pootle too and hooked using the usual mechanisms to the SVN server for LXDE this to maximize the translatable content in the Pootle server.

Allowing translations via Transifex has been started and might be popping up during the spring for those wihing to use that platform instead, subscribe to the translation mailing list for more information about that or hang out at the IRC channel #lxde at In the mean time use Pootle or download PO files from SVN/Pootle and submit to the tracker. One string translated is one string closer to the goal of being 100% translated. We really need some effort in some languages and I am really keen in adding new languages to the project if you are willing to give it a try.

I would like to see progress in the following languages (when they are complete we add another 430 million speakers!)
Norweigan (both Bokmål and Nynorsk)

For a quick start in translating LXDE components in Pootle read the illustrated crash course in the wiki.

With regards to the subject then, we are a highly translated DE and the numbers above shows that, the on going development of the LXDEcomponents have changed strings to the extent that while we had six languages completed a month ago we only have four left. And Indonesian and Slovak don’t even pass the 60% marker (mainly due to the addition of PCManFM but still, that’s one of the core pieces of software we have). We have decreased the overall degree of completeness but on the other hand progress have been made in many areas. Keep the good work up!

Summer of Code: Please submit your project ideas

Google Summer of Code

I have submitted our application for the Google Summer of Code 2009 and we are looking forward to the participation of the LXDE project. We are applying with LXDE and PCMan File Manager as dedicated software projects.

We are gathering project ideas for LXDE in the wiki.  If you are interested to join LXDE at the summer of code and would like to discuss project ideas, please also join us on IRC at #lxde.

Ideas for the PCMan File Manager project are on a seperate project page here: PCMan File Manager Ideas. The pages will be continuously updated with more information starting at the week from Monday, March 16, 2009.

Please visit our idea pages and add your project ideas. We are looking forward to your involvement and contributions!

LXDE Project Ideas:

PMan File Manger Project Ideas: