However, if there is anyone willing to help, forking thunar-vfs is also as good. Gtk file dialogs can be overriden with our own implementation by using LD_PRELOAD.
On Thu, May 28, 2009 at 2:33 AM, Manu <[email protected]> wrote: > 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
