Vote: Future of PCManFM (Very important!!)

The dedicated forum for PCMan File Manager - http://wiki.lxde.org/en/PCManFM

Select the VFS implementation for future PCManFM.

Poll ended at Fri Jun 26, 2009 5:01 pm

Shift to gio/gvfs, accept gnome dependencies it brings, and try to maximize performance or try to fork gvfs to create a less gnome-dependent gvfs implementation.
221
59%
Shift to thunar-vfs, and accept all XFCE dependencies it brings.
47
13%
Fork thunar-vfs (Thunar will be using GIO/GVFS, and we'll need to maintain all of these by ourselves later)
78
21%
Write our own vfs (Only select this if you're willing to join the development or you know someone who can help. Otherwise choosing this option is not constructive... After all, who is going to do the coding?)
30
8%
 
Total votes: 376

PCMan
Posts: 85
Joined: Mon Oct 06, 2008 9:52 am

Vote: Future of PCManFM (Very important!!)

Post by PCMan »

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.

After this issue is settled, the development of the next-generation new PCManFM will be started soon!

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.
This is now being done in their svn repository.
Besides, the author and maintainer of Thunar/thunar-vfs also agreed the move.
Quote Benedikt Meurer (Author of Thunar):
Thunar will use GIO/GVfs, as everything else simply doesn't make sense,
and would be useless duplication of efforts.
Please see the original mail from him on xfce4-dev mailing list: http://foo-projects.org/pipermail/xfce4 ... 24263.html
So, it's pretty sure that even XFCE is going to adopt GIO/GVFS.

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?
PCMan
Posts: 85
Joined: Mon Oct 06, 2008 9:52 am

Re: Vote: Future of PCManFM (Very important!!)

Post by PCMan »

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?
Ceno
Posts: 4
Joined: Fri Feb 13, 2009 6:06 pm

Re: Vote: Future of PCManFM (Very important!!)

Post by Ceno »

Hi PcMan,

I find it very interesting that you're asking the community for their opinion on this. I know nothing of the subject at hand, but I would just like to point the following.
I've spent a lot of time using PCManFM over the past year. The reason I used it, the reason you go to the ubuntu forums for instance and see tutorials on how to dump nautilus and use PMF, is because of the speed. There a lot of things I really like in the file manager, some features that really come in handy, but the biggest feature it has is being lightning fast. Without the speed, using it outside of lxde makes little sense. Whatever solution is chosen, please keep that in mind!

And by the way, thank you so much for your work. big fan of lxde and pcmanfm and I'm very glad it exists : -)

Cheers
madmarv
Posts: 3
Joined: Wed May 27, 2009 7:42 pm

Re: Vote: Future of PCManFM (Very important!!)

Post by madmarv »

I'm a new user, have only tried lxde and pcmanfm on a couple of systems (zenwalk and knoppix, and pcmanfm on puppy) and have been impressed with how far you've come in a relatively short time. Now have just dl'd Debian + LXDE for an old and very minimal spec laptop I rescued.

From everything I've seen, having used Xfce for the last six years or so, the Xfce devs are slowly turning their baby into a mini-Gnome. I don't think it would be too efficient to switch to the Thunar base. I think (as you seem to) that it will eventually change. Zenwalk 6.0 with Xfce4.6 already requires the gnome gvfs. If you make the switch now, you should get ahead of the game.

As for developing your own, that would be great, but why re-invent the wheel? GIO is already there and ready. And raw speed isn't always enough, I'll trade a little speed for reliability anytime.
juergenhoetzel
Posts: 6
Joined: Fri Mar 27, 2009 6:07 am

Re: Vote: Future of PCManFM (Very important!!)

Post by juergenhoetzel »

PCMan wrote: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.
This is the first argument for GIO because we can stick with it's high
level IO interface (not only for volume monitoring) and make LXDE
stuff even more portable. gvfs-hal-volume-monitor is just one
implementation of volume monitoring. Non HAL-Platforms could provide
different backends. Maybe there will be more lightweight GIO Module
extensions besides gvfs available in the future. We just don't have to
care about changes in HAL and platform dependent code.
PCMan wrote: 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.
theoretical NO. practically YES ;-) Because there is no other HAL back-end.

But we still benefit from GIO design: We don't depend on gvfs shared
libs. There isn't even HAL code in modules loaded by GIO at runtime
because gvfs back-end implementation is out of process spawned as dbus
service. This makes GIO applications more stable because buggy back-end
code can't crash your application and make applications more resource
efficient (sharing connections provided by backend). Connections become
available to all applications in the DBUS session. Users can benefit
from single sign on to remote Resources....

Nevertheless IO is still efficient because of file-descriptor-passing
from the gvfs backend process.

PCMan wrote:
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.
XFCE guys made a gnome-mount replacement:
http://wiki.xfce.org/gnomemount-replacement. Well this obviously
depends on exo-mount.
PCMan wrote:
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.
gnome guys learned from gnome-gvfs design errors, so will xfce:
gnome-gvfs and thunar-vfs implement vfs in the wrong
place. "In-process" VFS backends prevent easy sharing of IO Resources
between processes.
PCMan wrote:
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
Maybe someone could fork gvfs (get rid of gnome backends).
PCMan wrote:
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.
I obviously vote for GIO. Users will benefit from session based
application interoperability and don't get confused about Resources
available in GtkFileChooserDialog but missing in some LXDE
application. We can still stick with lightweight gtk+/(glib+gio)
dependencies (even if some magic is done in the background) and
prevent yet-onother-vfs.

Jürgen
PCMan
Posts: 85
Joined: Mon Oct 06, 2008 9:52 am

Re: Vote: Future of PCManFM (Very important!!)

Post by PCMan »

Many thanks to your post, Juergen.
Some good points are addressed.

Earlier I just found some importatnt information.

Quote Benedikt Meurer (Author of Thunar):
> Thunar will use GIO/GVfs, as everything else simply doesn't make sense,
> and would be useless duplication of efforts.

Please see the original mail from him on xfce4-dev mailing list:
http://foo-projects.org/pipermail/xfce4 ... 24263.html
So, it's pretty sure that even XFCE/Thunar is going to adopt GIO/GVFS.

If we don't use it, we'll have to maintain all the things ourselves and we'll be the only one incompatible with all other GTK+-based solutions, which will hurt our future development.

The reason why I consider using GVFS despite its various gnome dependencies is quite apparent. I already reviewed their code, and found that if it's used with extreme caution, we won't necessarily get slower. On the contrary, we can save all duplicated efforts, and focus on things that are really important.
Besides, we can fork gvfs to remove gnome dependencies, if it really cause problems later.

Since XFCE/Thunar is also moving to GIO/GVFS, I personally feel that it's the right time to do it for us. However, if we're going to adopt GIO, it should be done in a way preserving all the performance of LXDE. Given original performance is preserved, we can be more permissive on adding some minimal gnome dependencies.
This is my opinion.
PCMan
Posts: 85
Joined: Mon Oct 06, 2008 9:52 am

Re: Vote: Future of PCManFM (Very important!!)

Post by PCMan »

If we're going to use GIO/GVFS (quite possible), maybe we can start a new project aiming at creating a gnome-free fork of GVFS. Maybe it can be named gvfs-lite or gvfs-gf (gf means gnome-free, lol). In this way we have advantages of gio/gvfs, and can get rid of gnome dependencies. Cooperation with XFCE guys is possible since they also want to use gio/gvfs but hate gnome dependencies very much.

What do you think?
maces
Posts: 503
Joined: Sat Oct 25, 2008 6:04 pm
Contact:

Re: Vote: Future of PCManFM (Very important!!)

Post by maces »

Hi
PCMan wrote:If we're going to use GIO/GVFS (quite possible), maybe we can start a new project aiming at creating a gnome-free fork of GVFS. Maybe it can be named gvfs-lite or gvfs-gf (gf means gnome-free, lol). In this way we have advantages of gio/gvfs, and can get rid of gnome dependencies. Cooperation with XFCE guys is possible since they also want to use gio/gvfs but hate gnome dependencies very much.

What do you think?
I personally like this idea very much. As you said we would be compatible, can use the features and still be fast. I'm nor familiar with C, so I don't know how much work this would be.

maces
julius
Posts: 1
Joined: Thu May 28, 2009 6:14 pm

Re: Vote: Future of PCManFM (Very important!!)

Post by julius »

I also think that it would be the best option.
Julius
LXDE translator
shiki08
Posts: 6
Joined: Thu May 28, 2009 8:24 pm

Re: Vote: Future of PCManFM (Very important!!)

Post by shiki08 »

Voted for the 1. I think the same.. it'd be the same to keep up-to-date, but forget Gnome dependencies.
Locked