I understand... so gio/gvfs seems the better solution. You already have an alpha tester if you want. ;)
I already have an Ubuntu Minimal + LXDE built from SVN, and another Ubuntu + Compiz + an experimental LXDE built. Hotnuma. PCMan wrote: > It's hard to keep sync with upstream, the original thunar-vfs. > Besides, if they shift to gio/gvfs.... Then we are alone again. > Dependencies to several gnome components doesn't mean bloat-ware, if > you use them carefully. > Besides, those libs exist on most distros already. > If you are using firefox compiled with gnome support, you're already using > them. > If you're using gksu, you're using them already, too. > Gnome developers nowadays are trying to get rid of those old gnome libs, too. > So I feel this won't break our LXDE if we use them judiciously. > > On Thu, May 28, 2009 at 1:43 AM, Manu <[email protected]> wrote: > >> Hi, >> >> I would fork thunar-vfs. Dependencies with Gnome sounds >> like bloat-ware... Even Xorg is bloated, so it's really >> difficult to design a lightweight system nowadays. >> >> IMHO, PCManFM and LxPanel need some code cleanup... >> A shared library should be created with a cleaner API. >> >> I've found some duplicated code from PCManFM into >> Lxpanel for example. Doing some changes in the code >> adds more and more dirty things in it. >> >> Hotnuma. >> >> >> PCMan wrote: >> >>> 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 >>> >>> >>> >> > > ------------------------------------------------------------------------------ > 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 > > ------------------------------------------------------------------------------ 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
