After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 42265 - automatically make a local copy to edit remote files with local-only programs
automatically make a local copy to edit remote files with local-only programs
Status: RESOLVED OBSOLETE
Product: nautilus
Classification: Core
Component: Navigation
2.11.x
Other All
: Normal enhancement
: future
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 42890 97042 300038 (view as bug list)
Depends on:
Blocks: 44932
 
 
Reported: 2000-08-22 03:43 UTC by victor
Modified: 2008-05-03 15:31 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12



Description victor 2001-09-10 00:37:51 UTC
Date        Time      Type            Category             Subject
----        ----      ----            --------             -------
08:18:2000  12:11:09  Feature Reques  Sidebar Panels       Remote viewing and
                                                           components
IP: 24.128.254.59    Email: rpmuldoon@students.wisc.edu

Right now, if I use nautilus to browse, I get the siderbar option buttons to
view the content with different programs.  This is an excellent idea.  (and it
should all be in a right-click menu as well...)  However, if I try to use Emacs
to view the source of the web page, I can't, since emacs can't look at remote
documents.  Is there some kind of way around this?  Would it be possible to
check if the component can view remote files, and if not, fall back to viewing a
local cached copy of the file?  Although I think that programs should be
migrating to being able to view remote files, it would be a very useful feature
to allow more smooth integration of viewers if nautilus/bonobo could offer a
local version of the content as a fallback.



------- Additional Comments From arlo@workthatmouse.com 2000-08-22 10:30:19 ----

Can we make a local copy of the file in this case, but mark it read only?



------- Additional Comments From darin@bentspoon.com 2000-08-22 10:34:07 ----

We're pretty sure this is the duplicate of an existing bug (we definitely
discussed this feature before and deferred it), but John and I can't find that
bug report.

The local version fallback requires some thought to design well. There's the
trick of explaining why the local copy is read-only, or somehow allowing
read-write access. It's also unclear what would delete the local copies and
when.



------- Additional Comments From darin@bentspoon.com 2000-09-12 15:16:56 ----

*** Bug 42890 has been marked as a duplicate of this bug. ***



------- Additional Comments From eli@eazel.com 2000-10-16 19:48:57 ----

Batch-assigning QA ownership of remaining bugs to eli@eazel.com



------- Additional Comments From eli@eazel.com 2001-03-26 11:20:30 ----

SPAAAAAAAAAM! 

(Jon Allen has taken these components; QA Assigning bugs to him.)



------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 20:37 -------

The original reporter (victor@eazel.com) of this bug does not have an account here.
Reassigning to the exporter, unknown@bugzilla.gnome.org.

Comment 1 John Fleck 2002-01-05 04:13:41 UTC
Changing to "old" target milestone for all bugs laying around with no milestone set.
Comment 2 Dave Bordoley [Not Reading Bug Mail] 2002-10-30 07:04:29 UTC
*** Bug 97042 has been marked as a duplicate of this bug. ***
Comment 3 Aschwin van der Woude 2002-11-17 11:24:35 UTC
To get developers notice this bug, I will confirm it. The amount of
duplcates is enough confirmation as well.
Comment 4 Christian Neumair 2005-07-10 15:07:41 UTC
*** Bug 300038 has been marked as a duplicate of this bug. ***
Comment 5 A. Walton 2008-05-03 15:31:02 UTC
Marking as obsolete; applications that don't handle remote URIs should be handed local FUSE paths under GIO/GVFS, which will allow them to behave as if they are working on local files, which I believe is the behavior intended by this bug.