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
