LXDE - Lightweight X Desktop Environment

If we start using gio/gvfs, that doesn't mean we'll be slow just like
current nautilus.
On the contrary, if we use ready-made VFS library like gio, we can
focus on what we really want to do.
Of course, this includes doing optimizations and adding handy new features.
In the long run I think this is more constructive than fixing old bugs
and broken compatibility all the time.
I believed that judicious use of gio/gvfs can still make things
lightweight and fast "enough".
"Enough" means, it won't be the fastest, but it will be acceptible by the users.

People think that GTK+ is slow, but we prooved that you can still
develop fast and light apps with it.
So, I think we can do well with GIO/GVFS or thunar-vfs, too.
Having some inevitable dependencies on other desktop environments
doesn't mean that we'll be slow.
That's totally dependent on how we use them.
After all, many other existing applications are using those libraries,too.
So it's not possible to get rid all of them on modern distros.
Since they are already there and is now an essential part of the
system, why not make judicious use of them?

For me, provided the performance is still good and the memory
footprint is still acceptible,
some (minimal) gnome or xfce dependencies are acceptible. How about
the opinion of our users?

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
> Pcmanfm-develop@...
> https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop
>
>

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 <hotnuma@...> 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
>> Pcmanfm-develop@...
>> https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop
>>
>>
>
>

---------- Forwarded message ----------
From: PCMan <pcman.tw@...>
Date: Thu, May 28, 2009 at 2:02 AM
Subject: Re: [Pcmanfm-develop] Please vote for future of PCManFM (Very
important!!)
To: Sebastian Pipping <webmaster@...>


OK. Thank you.
I'll try to do it recently. (I'm not on my Linux laptop now)
Why I'm calling for opinions here is because if we're going to adopt
another vfs,
those file I/O code will be totally re-written. So there is no need to
fix those old bugs.

On Thu, May 28, 2009 at 1:56 AM, Sebastian Pipping
<webmaster@...> wrote:
> I cannot suggest anything on this very topic yet,
> I hope on a friend though, will see ..
>
>
> The reason I'm replying here is simple and urgent:
>
> The latest release of pcmanfm (0.5) has bugs that can delete files
> without the user wanting or expecting it, a bug that we have fixed
> in trunk for a while now (#2710035):
>
> http://sourceforge.net/tracker/?func=detail&aid=2710035&group_id=156956&atid=801864
>
> The bug is fixed since r790.  We need a new release today,
> I should have asked for that way earlier.
>
>  Please consider pushing out a new release as as soon as possible.
>
> Either of 0.5.1 or 0.6.0 would make me happy.
> Thanks in advance,
>
>
>
> Sebastian
>
>

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 <hotnuma@...> 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
>>> Pcmanfm-develop@...
>>> 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
> Pcmanfm-develop@...
> https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop
>
>

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 <hotnuma@...> 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 <hotnuma@...> 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
>>>> Pcmanfm-develop@...
>>>> 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
>> Pcmanfm-develop@...
>> https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop
>>
>>
>
>

Apart from one message of one guy in the XFCE community who said he
was going to port thunar to GIO, I've not been able to find any
discussion about that in their forum or their mailing list. Could you
tell what were their arguments about this switch ?

I think for now that reusing and improving their vfs is the best
solution, we then will be able to make what we want and free ourselves
from the heavy gnome dependencies. In the best world, we can grow a
project with xfce guys to make some code common so they do not loose
in the deal.

2009/5/27 PCMan <pcman.tw@...>:
> 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 <hotnuma@...> 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 <hotnuma@...> 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
>>>>> Pcmanfm-develop@...
>>>>> 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
>>> Pcmanfm-develop@...
>>> 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
> _______________________________________________
> Lxde-list mailing list
> Lxde-list@...
> https://lists.sourceforge.net/lists/listinfo/lxde-list
>

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

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 <juergen@...> 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
>
>

After this issue is settled, the development of the next-generation
new PCManFM will be started soon! I stopped all the development of
PCManFM earlier because I felt that we already arrived at a point of
no return. Before we continue, we'd better make sure that we are
moving toward correct direction.

So, all users/developers, please help us make this critical decision.

Thank you all.

If we're going to use GIO/GVFS (quite possible), maybe we can start a
new project aiming at creating a gnome-free fork of GVFS. Maybe it can
be named gvfs-lite or gvfs-gf (gf means gnome-free, lol). In this way
we have advantages of gio/gvfs, and can get rid of gnome dependencies.
Cooperation with XFCE guys is possible since they also want to use
gio/gvfs but hate gnome dependencies very much.

What do you think?

On Thu, May 28, 2009 at 3:30 PM, PCMan <pcman.tw@...> wrote:
> After this issue is settled, the development of the next-generation
> new PCManFM will be started soon! I stopped all the development of
> PCManFM earlier because I felt that we already arrived at a point of
> no return. Before we continue, we'd better make sure that we are
> moving toward correct direction.
>
> So, all users/developers, please help us make this critical decision.
>
> Thank you all.
>

Hi PCMan,

Here are my 2 cents, from the point of view of a maintainer of
a "software environment" (think distro, even though it is not).

We are preparing all kinds of (*nix-like) software on a global file
system so that it can be run immediately without "installation".
Our approach implies that updates are testable and safe, invisible for
the end user and that any programs and their different versions can be
used simultaneously even by the same user without collisions.

For the moment we maintain some limited desktop environment,
and consider Lxde as a good candidate for including on our setup.

As an contrasting example, Gnome is very badly suited for transparent
global maintenance and updates due to its architecture.

That's why I am concerned about Gnome dependencies. If this is just
a few free-standing libraries, that's no problem from my point of view.
If the dependencies imply some Gnome infrastructure (like the libraries
being expected to be present at certain hardcoded paths), it would
be detrimental.

In the latter case I would like to suggest you to look for some different
toolkit, at such a crucial point in the development (despite what is
said about the matter on http://wiki.lxde.org/en/LXDE:Questions).

Otherwise, getting rid of Gnome dependencies while still using Gtk is
in my eyes a sane approach.

[It is a pity that freedesktop.org establishes standards which are hard
to implement efficiently. It may be worth not taking full compliance as
an absolute goal.]

Best wishes and good luck.

Regards,
Rune

On Thu, May 28, 2009 at 03:30:07PM +0800, PCMan wrote:
> After this issue is settled, the development of the next-generation
> new PCManFM will be started soon! I stopped all the development of
> PCManFM earlier because I felt that we already arrived at a point of
> no return. Before we continue, we'd better make sure that we are
> moving toward correct direction.
> 
> So, all users/developers, please help us make this critical decision.
> 
> Thank you all.

For the PCManFM next-generation, I would suggest to move
the source code to LXDE/trunk, to create a build script as
I submitted in the patches area and also adopting a more
standard coding convention like in LXTerminal. ;)

My 2 cents,
Hotnuma.

PCMan wrote:
> After this issue is settled, the development of the next-generation
> new PCManFM will be started soon! I stopped all the development of
> PCManFM earlier because I felt that we already arrived at a point of
> no return. Before we continue, we'd better make sure that we are
> moving toward correct direction.
>
> So, all users/developers, please help us make this critical decision.
>
> Thank you all.
>
> ------------------------------------------------------------------------------
> 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
> Pcmanfm-develop@...
> https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop
>
>

Il giorno gio, 28/05/2009 alle 01.09 +0800, PCMan ha scritto:

> 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.

I think that supporting network volumes (and auto-mounting local
volumes) is essential nowadays (and one of the reasons I am still using
nautilus instead of pcmanfm).

I think LXDE project has too few developers to try and fork a library
just to have an incompatible (with all other gtk software) API, and this
would result in more bloat (having both gnome and lxde libraries that do
the same thing) when you use some gtk software.

So, as LXDE cannot rewrite all the gnome software (epiphany, evince,
pidgin, etc.), I vote for using gnome-gvfs and gio and keep the bloat at
minimum.

I am still hoping that with the gtk+ improvements and gnome libs
integration and refactoring, the gnome team will try to provide a
smaller and more efficient gtk in the future.

Bye.

-- 
Alessandro Pellizzari