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 358203 - Improve error handling for "Open Location"
Improve error handling for "Open Location"
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: User Interface
2.2.x
Other All
: Normal minor
: 2.4
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2006-09-28 21:41 UTC by rhi
Modified: 2008-01-15 13:12 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description rhi 2006-09-28 21:41:53 UTC
Please describe the problem:
The File/"Open location" menu entry is available for Win32 although it doesn't work with Win32. This is very confusing to users which can't guess that this feature isn't available in the Win32 version.

Steps to reproduce:
1. File/Open location...
2. Enter URL
3. Does NOT work


Actual results:
A confusing error message appears which doesn't state that this feature isn't available but shows this message: "Could not open 'C:\Program Files\GIMP-2.2\bin\www.somesite.com\someimage.jpg' 
for reading: No such file or directory"

Expected results:
Either the "Open location" menu shouldn't be shown in GIMP/Win32 or there should at least be an error message stating that this feature is not available for Win32.

Does this happen every time?
of course

Other information:
See bug 300581
Comment 1 Michael Schumacher 2006-09-28 22:13:52 UTC
IMO there should be a better error message and overall behaviour if an URI scheme is not supported - even if we add http://, some other scheme might still make fail. Just hiding something which works fine for some schemes (file:// right now), but not for others isn't better than the current behaviour.
Comment 2 Sven Neumann 2006-09-29 12:11:53 UTC
File URLs work even on Windows, so there's no point in hiding the entry. Also someone might add a plug-in to the Win32 version that makes loading of remote files work.
Comment 3 Michael Schumacher 2006-09-29 13:28:28 UTC
The libcurl back-end written by Mukund woulkd be a candidate, at least.
Comment 4 rhi 2006-09-29 15:07:47 UTC
Yes it would be nice if gimp/win32 would be able to load http URIs. But it's not that tragic if it is not; this matter is discussed in bug #300581.

I don't see THIS bug (#358203) as an "enhancement" but I think it's a (minor) user interface bug that confuses users who don't know much about URI schemes, just copy or enter an URI into the "Open location..." dialog and get an incorrect error message.

So the best solution would be to show "protocol not supported" for URIs that cannot be loaded. I would make a patch if I could, but I don't know how to do.
Comment 5 weskaggs 2006-09-29 18:33:08 UTC
I agree that this is a bug report rather than an enhancement request.
Comment 6 Michael Natterer 2006-10-15 20:05:33 UTC
Fixed in CVS:

2006-10-15  Michael Natterer  <mitch@gimp.org>

	* app/file/file-utils.c (file_utils_filename_to_uri): if the
	passed filename starts with a valid, but unhandled uri scheme,
	fail with an error saying "URI scheme 'foo:' is not supported"
	instead of treating it as relative file path. Fixes bug #358203.

	* app/dialogs/file-open-location-dialog.c
	(file_open_location_response): don't close the dialog on errors
	that are related to the entered URI because these errors are
	failed user input validation, not failed open.