Thanks much for the long discussion.
Alexander Larsson wrote: > On Fri, 2007-07-27 at 20:12 +0900, Takao Fujiwara - Tokyo S/W Center > wrote: > > >>>I don't think any solution is really right at this time. Neither >>>solution is ideal, and we add hacks that are visible to the user (env >>>vars) that we have to keep supporting in the future, and hacks that >>>doesn't fully fix the issue. And all this is for something that is >>>scheduled for replacement. >> >>Thanks for your reply. Now I agreed with your point and also I feel it's >>quite difficult to fix this problem fully in the current nautilus and >>gnome-vfs without gvfs. >>However my point is a slightly different from yours. I think gvfs is a new >>feature and currently gnome-vfs has this bug. I completely agree gvfs will >>resolve almost problems against gnome-vfs but e.g. there are no solutions >>when I want any fixes in three months. I haven't thought to provide full >>supports for samba of equal gvfs at the moment but I'm asked to fix the >>critical problems with samba. >>If I think the previous version of GNOME, e.g. 2.6, it may be difficult to >>use gvfs since backports something will be needed. >>But I understood it's not good for you to hack the visible env values because >>those env values won't be used once gvfs is available. >> >>I don't find which resolutions I should take. >>What do you think this kind of patches are applied by each vendors and the >>vendors will maintain the patches by themselves until gvfs is available but >>the patches are not integrated in nautilus/gnome-vfs head and/or branch? Are >>there any concerns/suggestions in your side? > > > I think carrying a vendor patch for this seems like a good idea. > > >>When is the target to release gvfs? > > > The target is the next (major) release of glib. The exact date is > unknown, but a guess would be to see a stable release of it in 11 months > or so. > > > -- nautilus-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/nautilus-list
