PCManFM 0.9.9 released! libfm 0.1.16 released!

PCManFM, the default file manager of LXDE, just got a new release. This application need libfm 0.1.16 to work and incidently that is also released today!

PCManFM has seen some significant improvements since the last release back in October 2010. Probably the most notable UI change is the reintroducation of the tree view in side pane that was removed in the rewrite.

pcmanfm-0.9.9.tar.gz, sha1: de7099f57d7139a3d184cd162e02f5f5601667ec
libfm-0.1.16.tar.gz, sha1: c3f4b10baa596ddfc09ae9efbd2c922a26114de8

Changelog for PCManFM
5cbad00 Explicitly link to libfm.
a672793 Fix #3094303 – Regression: Dnd to add folder to bookmarks is broken.
3c969e7 Focus folder view after switching page.
5089e13 Update to use latest libfm API. Fix #3300800 – Deletion prompt has no title.
fa7d474 Fix untranslatable messages.
792cf32 Make “%d items selected” status message translatable.
b282aec Fix #3308324 – “~ in locatio bar cause pcmanfm crash”. Fix #3286157 – “Entering path with two initial slashes // crashes”. Fix #3284001 – “Crash when entering path with trailing slash”. This is related to GTK+ bug #650114, which is already fixed.
813241d Add “Reload folder” to “View” menu.
8a2866f Apply patch #3135578 – Problems with the selection and opening a file.
11d77a6 Apply patch #3163496 – “Menu key to call context menu” with some modifications.
164a371 Apply patch #3301636 – Make slash and tilde activate location bar.
253bdaa Close tab page when the folder which it shows is deleted or unmounted.
fb74b05 Use a less problematic way to show “root mode” warnings.
9756804 Update statusbar text, volume info, and window title correctly for every pages.
792db54 Use enum values instead of integer values for bookmark open methods.
ca184dd Use new API: fm_folder_model_get_is_loaded().
32f6ac2 Rework tabbed-browsing again and create one separate GtkHPaned widget for every page.
ea5e99a Save side pane mode.
5c2f12d Fix free disk space display. Fix #3037825 – Bottom bar not updated.
9a84c1c Rework tabbed-browsing again and make the code cleaner.
25a6a7b Add correct version checks for libraries in configure.ac.
ff8faeb Deprecate fm_folder_get_for_path() API and use fm_folder_get() instead.
28a479b Rename variables for consistancy.
a1c270d Make status bar message more user-friendly and correct.
b4e898b Use new fm_path_entry_set_path() and fm_path_entry_get_path() APIs.
1dfc8e4 Fix #3114626 – PCManFM 0.9.9 Umount partitions problem.
30cf77f Prevent removing built ui files and fix #3181001 – data/ui/*.glade files missing in tarball .
c1f4b6c Set a proper default desktop font if the config value is lacking.
41ad5c3 Add a new config value tab_max_chars to limit the maximum width of tabs.
6240436 Rework tab browsing so we can have more tabs in available space just like the old pcmanfm 0.5 series.
b7a953d Little fix.
cac3de0 * Fix #3139753 – Create New asks for name of new “file” even for a new folder. * Update translations.
9197e75 Add “Create New” popup menu to “File” main menu. Close bug #3107416.
3d14164 Fix #3095516 – PCManFM does not write preferences from main menu.
13a4a38 Add checks for invalid enum values when loading config files.
6d95cbc Fix #3112447 – Daemon mode opens window.
376cc92 Update translations and fix #3114640 – PCManFM 0.9.9 Right-clic on desktop partly hard coded.
6033d80 Escape strings while passing through IPC.
d7d1289 Handle string arguments with prefix –.
1098cfe Little fixes.
cda6259 Reimplement a simpler yet cleaner IPC mechanism again.
cdf5dfc Support mouse button 8 and 9 for back and forward.
5715ba7 Fix #3094187 – Icons file no change when “Stick to Positon” is unchecked.
4e0e602 Trivial fix.
b2e074e Improve handling of backward compatibility for old config files.
2ed76de Fix #3085503 – always_show_tabs=1 don’t work.
b510014 Require correct version of libfm.
9afd9e1 Bump version number to 0.9.9. Fix #3071296 – pcman windows always show up on first desktop.
422e106 Apply patch #3089346 – Re-enbale fake transparency when using pcmanfm 0.9.X.
7fd8aba Use our own round() implementation to avoid using C99 only function.
248b813 Add missing file to data/Makefile.am

Changelog for libfm
c5595a9 Remove docs directory from make file
d036dce fixed makefile
d06d8a0 we need m4 folder
4c7b7a2 fix file authors
7f5466e added missing license header
d22b41f Try to fix Lubuntu bug #820865 – pcmanfm cut&paste a folder to a destination folder withouth write permission causes data loss. https://bugs.launchpad.net/ubuntu/+source/pcmanfm/+bug/820865
2c8fdfb Trivial fix.
fe9ea77 Add missing license info and fix some build problems found by “make distcheck”.
3153210 * Bump ABI version with libtool -version-info to 1:0:0. * Update AUTHORS info.
9c49624 Fix #3094303 – Regression: Dnd to add folder to bookmarks is broken.
70e45ab Add optional window titles to commonly used dialogs provided by fm-gtk-utils.c. Fix #3300800 – Deletion prompt has no title.
94d9f4e Fix untranslatable messages.
d20b968 Make menu of side pane translatable.
37eee68 Apply patch #3301641 – Typing “~” in location bar loads root folder.
89630cf API changed: fm_folder_get_is_loading() -> fm_folder_get_is_loaded(), fm_folder_model_get_is_loading() -> fm_folder_model_get_is_loaded(). Add fm_folder_view_get_is_loaded(). Correctly update popup menu of FmSidePane when mode is changed.
cd79d62 Add missing g_object_ref.
8a69a3d Little fixes.
90c685c Add “changed”, “removed”, “content-changed”, and “fs-info” signals to FmFolder and add filesystem size query to FmFolder.
c076d3e Check for correct required versions of libraries in configure.ac.
d3f856f Little fix for dir tree.
1d09555 Include proper headers.
29bf2a1 Add FmSidePane class for a better implementation of side pane.
b54f630 Some fixes for FmDirTreeView.
c1b0d37 Add FmDirTreeView and FmDirTreeModel to implement directory tree for left pane.
7915d1f Add new API: fm_path_depth().
682f9e2 Add new API: fm_file_info_is_hidden() and have FmFolderModel use it. Remove the unused API fm_folder_get_for_path().
fe1854e Implement %k field code for Exec key according to desktop entry spec.
debea4a Little fix for statusbar message in demo program.
03ec420 Fix #3093778 – Pasting empty string causes copying “/” to current folder.
db84c10 Remove the useless “status” signal from FmFolderView and add some APIs for accessing data members.
180db97 Update comments.
3bdd675 Add a FmPathEntryModel custom tree model for FmPathEntry to save memory.
8003719 Little fix for cancellable.
392601b Use another way to implement auto-completion for path entry and try to utilize most existing functionality provided by gtk+.
d53456f Rework FmPathEntry and make it simpler and faster.
d500b33 Add a simple and basic implementation of button-style path bar.
197c7e1 Fix #3086703 – PCManFM crashes on non existent directories.
61443ac Fix #3115734 – Copying to long path names.
26062bb * Do chdir to / if cwd is under the mounted filesystem which is going to be unmounted. * Fix #3114626 – PCManFM 0.9.9 Umount partitions problem.
2243156 Fix #3127903 – Fails to give permission denied error when overwriting.
2f61ade Fix reference of invalid widget pointer in properties dialog.
415083d Prevent removing built ui files and fix #3181001 – data/ui/*.glade files missing in tarball.
883793d Show tooltips for tab labels when the label text is ellipsized.
3204482 * Use a forward compatible way to register uri scheme handlers as in glib >= 2.27. * Fix #3094197 – Prepare deprecation of the gio module.
67375dd Fix #3132262 – Crash when trying to restore files from trash.
17511bd Fix #3148077 – Latest pcmanfm/libfm crashes when trying to open /proc/self/fd/ (or its symlink /dev/fd/). In this same system nautilus opens that directory fine.
0f04125 Fix #3143296 – spaces are still (or again) not escaped in paths to execute.
36dfad2 Fix #3135910 – “Extract here” doesn’t handle space and encoding characters.
d419535 Add some macros to validate enum values.
1b2560c Changed order of typedeffing enums and declaring them – for C++ compatibility
cf8446b Do further checks for scripts.
1a249bf List “gobject-2.0” in configure.ac explicitly.

Upcoming releases

LXDM 0.4.0 was just released. Get the file at sourceforge.

But that is not the only thing happening in LXDE land. Next week we will do at least three releases if nothing special happens. PCManFM, libfm and LXDM.

PCManFM and libfm has been in development with no updates since last October and the much sought after feature of a directory tree has returned.

LXDM will “just” be a service release to get more translations into shape; Esperanto makes its first appearance in an LXDE component by this. Happy times. All three components are scheduled for release at the 27th of July.

The best guess by now is that more components will get releases in the coming weeks, some of them has seen no releases for years but has seem interesting features hidden in the git HEAD.

UPDATE!
LXDM 0.4.0 had an error in the release, there has been a new release dubbed LXDM 0.4.1 to fix this issue and include the l10n updates as mentioned above.

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 pcman.tw@gmail.com.

Cheers!

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.

Cheers!

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!

http://sourceforge.net/projects/pcmanfm/


Cheers!

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 freedesktop.org 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://libfm.git.sourceforge.net/gitroot/libfm
  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: http://sourceforge.net/projects/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.

libfm-demo

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.

http://sourceforge.net/projects/libfm

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.

http://cia.vc/stats/project/libfm

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.

http://wiki.lxde.org/en/PCManFM_Roadmap

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.
http://forum.lxde.org/viewtopic.php?f=0&t=456

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/freedesktop.org/HAL, 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 freedesktop.org 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 freedesktop.org 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?