I just released PCManFM Qt file manager 0.1.0, the first Qt port of PCManFM.
You’ll need libfm to build it (which is included in many distros).
P.S. When running the program for the first time, please choose an icon theme from the [Edit] / [Preferences] menu. Otherwise you’ll get no file icons.
If you install the program into /usr/local, don’t forget to run “ldconfig” after installation, or libfm-qt won’t be correctly loaded by the loader.
This release contains no thumbnail support yet.
However a fully working thumbnail support is already in the git.
Because this requires some changes to the upstream libfm library,
it’s scheduled for the next release and not make public at the moment.
To turn on the desktop icon management feature, run with the command:
> pcmanfm-qt –desktop
Generally it’s a good idea to add this command to your session startup script.
To turn the desktop icon manager off again, do this:
> pcmanfm-qt –desktop-off
If you don’t want to use the desktop icons, you can still add the
command to your session startup script:
> pcmanfm-qt –daemon
In this way, it will becomes a background daemon. Every time you need
to open a folder with pcmanfm-qt, it can be shown “immediately”.
BTW, please don’t mail me and ask if PCManFM will shift to Qt.
The Gtk+ and Qt versions will coexist.
There will still be new releases for the Gtk+ version in the future.
The Qt port is only an alternative, not a replacement.
I, however, need to admit that working with Qt/C++ is much more pleasant and productive than messing with C/GObject/GTK+.
Since GTK+ 3 breaks backward compatibility a lot and it becomes more memory hungry and slower, I don’t see much advantage of GTK+ now. GTK+ 2 is lighter, but it’s no longer true for GTK+ 3. Ironically, fixing all of the broken compatibility is even harder than porting to Qt in some cases (PCManFM IMO is one of them).
So If someone is starting a whole new project and is thinking about what GUI toolkit to use, personally I might recommend Qt if you’re not targeting Gnome 3.
I got some feedback about the toolkit choice above. Don’t get me wrong. I’m not saying that gtk+ is bad and did not intend to start a toolkit flame war. If you’re going to use python, C#, or other scripting language, gtk+ is still a good choice due to its mature language bindings.
Vala is attractive initially, but after trying it in real development, you’ll see the shortcomings of this approach. Because it sometimes generates incorrect C code that still compiles, we got some really hard-to-find bugs. So we need to examine the generated C code to make sure it does things right. This takes much more time than just writing plain C code myself. Besides, the generated C code is not quite human-readable and debugging becomes a problem. Another issue that’ll hit you is the problems in the library bindings. Though there exists many vala bindings for various C library, their quality is uncertain. Finally, debugging, examing, and fixing the bindings all the time takes even more time and offsets the time saved by using Vala.
To sum up, for compiled binary programs, Qt IMHO is a good choice to consider if you don’t hate C++.