Many thanks to your post. 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-dev/2008-February/024263.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 cautious, 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. On Thu, May 28, 2009 at 2:44 PM, Juergen Hoetzel <[email protected]> wrote: > First of all: Thanks for the summarization of options and democratic > voting process. This is indeed an important decision. > > On Thu, May 28, 2009 at 01:09:39AM +0800, PCMan wrote: >> 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. > >> 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. > >> 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. > >> 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. > >> Options are: >> >> 1. Shift to GIO + GVFS, and accept the inevitable GNOME dependencies > > Maybe someone could fork gvfs (get rid of gnome backends). > >> 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 > > ------------------------------------------------------------------------------ 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
