Re: [Lxde-list] [Pcmanfm-develop] Please vote for future of PCManFM (Very important!!)

[PCMan <pcm...@gm...>]

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 <ho...@gm...> 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
>> Pcm...@li...
>> https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop
>>
>>
>
>