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

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

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 <ho...@gm...> 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 <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
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>>
>
>