Please go to this URL for vote. 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? ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com _______________________________________________ Pcmanfm-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop
