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/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.
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?
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?
12 responses to “Please vote for the future of PCManFM.”
Sticking with gnome has given great adaptability. But we have it now–so I am torn to the choice of sticking with gnome or keeping current work. Gnome support will help in the long run.
Do we need PCManFM to perform volume management? I just do it all manually.
I love PCManFM because it’s simple and snappy. Add a couple features (such as a delete confirmation option), but please don’t slow it down noticeably. Adding lag just to support volume management isn’t worth it IMO.
Would it be outrageous to consider a separate app just for volume management? Then you could go to town with it without having to worry about compromising the sleekness that is PCManFM.
It would be nice to at least offer a compile option to omit compiling with volume management. I’d happily recompile to get rid of lag.
That aside, to me it seems like GTK/GIO is the best long term option.
My vote goes for thunar-vfs.
thunar-vfs being picked up by you guys may even spur its further development.
Please look at the lxde design guidelines:
“- If only several simple APIs of another big library are needed, try to extract them and add them to your program instead of depending on the whole library whenever possible. (Beware of license)
– Only use libraries from other desktops when they are small or efficient enough and have few dependencies.
– Only create a daemon if there is a really good reason.
– Try to keep maximal compatibility with lower gtk+ versions (gtk+ 2.6 is preferred). Try to make features requiring higher gtk+ versions optional with proper conditional compilation and compatibility macros.”
In this sentiment, pcmanfm should have less dependencies, not more. The added funtionality of handling remote volumes isn’t worth sacrificing speed, or having few dependencies (thus occupying less space on the harddrive), or the modularity which defined lxde in the first place.
My take: Fork thunar-vfs (or whatever code base that suits your purpose best). Fork it not as part of the pcmanfm codebase, but as an standalone project. Give it a new name, make it as lightweight possible providing just the funcionality that you need. Look out for developers to work on this and keep it as a separated project (but coordinating efforts) from the development of pcmanfm.
Please, keep lxde lightweight.
Gnome is platform development by infection. So you have to avoid the infection but I agree with your pragmatism on the low level stuff. LXDE solves the Gnome infection culture bug.
“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.”
LXDE is about to become number 3. An enterprise ready fast desktop environment for the masses which delivers what Gnome can’t, while KDE slowly eliminates the bugs for his next generation to win back its 3.5 users. LXDE has no toolkit nazi attitude, in fact it is totally modular and low risk. Concentrate on running code and simplicity, outsource the common cruft to others. Linux desktops together have less than 2% market share, so we don’t compete with the allmighty Gnome which is just another dwarf. LXDE = the LinuX Desktop done right, focused on responsiveness and less performance/memory taxation. VFS is on a lower level. It is a bit like to ask whether to take ubuntu, red hat linux, freebsd or opensolaris. If thunar throws away thunar-vfs it would be a total waste and it looks to me that thunar itself is getting very little attention.
thunar-vfs is a pretty bad name. It is a pragmatic aspect to use the gnome stuff and later to a joint project with thunar developers and others based on the thunar stuff as a replacement to get rid off this gnome library. It depends on the developer community to grow first. Immature solutions here would block broad LXDE adoption.
Pragmatism and running code over ideology.
I really hope you will go with gio/gvfs and get all the *great* work already done (and being done in the future) for free!
I realize there are a lot of people who don’t really like GNOME in the lxde community. But keep in mind that you already use technology primarily shaped by GNOME (glib, gtk) and that gio/gvfs are proven and well-maintained extensions to those. Also, using gio in LXDE means better integration of GNOME- and GNOME-tech-using apps on LXDE.
Instead of reinventing the wheel you should use what “GNOME” provides and contribute to it (speed/memory fixes always welcome I guess!)
Go with thunar-vfs. Fork it, especially if XFCE is going to drop it (which is foolish.) +1 to rafael’s reasoning.
m a r
Consult w/ Dear Xfce folks, GIO folks, FreeDesltop folks, everybody finding the best solution (i feel: fork thunar-vfs :-)))
How is it difficult to make speed tests for thunar-vfs and gnome gio??
Probably 5% thunar-vfs’s speed over gnome isn’t worth maintaining code…
Please, please, do not depend on gnome. That would be a very bad move. I’ve been using pcmanfm happily for a long time now and I wouldn’t be able to use it anymore if it depended on gnome. I’m using slackware which does not ship gnome and to get gnome on slackware, some solutions involve replacing many system libraries.
LXDE depending on gnome would be a no-go for 95% of slackware users.
Gnome is really annoying for being invasive.
And how could pcmanfm stay light if it required half of the gnome libs ? It may be nearly light in memory but it wouldn’t be light on the disk (think livecd systems).
Actually, I wouldn’t mind not having volume management, but that’s a very personal thing. A ./configure –disable-volume-management switch would probably be nice to have, no matter the decision that is taken.
Only GIO/GVFS. Remote filesystem support is quietly required, even with cost of being less lightweight. Also, it would be a good chance to use it with gnome.
I think that LXDE should remain lightweight and minimal, depending over Gnome or XFCE seems to me like a bad move.
It is not because they are slow or something, but because of the tons of daemons running in background and wasting memory. LXDE, as of now, has daemons only when necessary, and does just what it is supposed to do.
I’d say to implement something just for LXDE or leave it as it is.
Just my opinion.