Re: URIs, D&D and bug #48423

[Michael Meeks <michael ximian com>]

Hi Alex,

On Tue, 2002-05-21 at 16:15, Alex Larsson wrote:
> > 	Is. I ask this because in bug #48423, we blindly accept that the
> > incoming URI in the D&D list is in fact a URI, and not a mangled
> > filename. And we emit a 'location_changed' signal with it as the string,
> > all of which ends up doing:
> 
> I don't think we should be sending broken URI-lists like that. We should 
> be using g_filename_to_uri() so all apps use the same way of encoding the 
> URIs. We spent a lot of time getting the behaviour of that function right, 
> and it's what the Gtk+ fileselector uses for DnD.

	Um; wait - we already have a correctly escaped URI in the method I
mentioned, and we deliberately break it so it works with Gnome 1.4's
gnome-libs. Are you certain that you want to break compatibility with
that ? if so fine.

> > 	Which for the un-initiated means that this unescaped (%20 for spaces)
> > URI goes into the nautilus-directory as a separate entry from the
> > (pre-existing) properly escaped entry of the same name.
> > 
> > 	What should be done about that ? would a correct fix be to use
> > eel_make_uri_from_input on the incoming URIs ?
> 
> No. We should probably use g_filename_from_uri(), and then fix all apps 
> that send broken URI-lists. 

	Well - I tend to agree for Gnome 2.0 - _but_ it took me in excess of an
hour or two to find this problem. I do not plan to go looking for it
again, is there some way to validate that a URI is correctly encoded ?
ie. I could write a little 'eel_string_is_uri' method, that would as a
minimum check that we don't have any unescaped spaces lurking around in
the URI, and warn / complain if we do.

	Alternatively of course, we could use eel_string_is_uri to test and
then use eel_make_uri_from_input 

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot