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 305895 - URL's (file:///) should be URL encoded.
URL's (file:///) should be URL encoded.
Status: RESOLVED FIXED
Product: muine
Classification: Other
Component: general
trunk
Other All
: Normal normal
: ---
Assigned To: Muine Maintainers
Muine Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-05-30 06:35 UTC by Brian Kerrick Nickel
Modified: 2006-01-22 20:34 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to src directory (1.21 KB, patch)
2005-06-01 01:21 UTC, Brian Kerrick Nickel
none Details | Review
Real Patch, should work this time. (935 bytes, patch)
2005-06-01 02:32 UTC, Brian Kerrick Nickel
none Details | Review

Description Brian Kerrick Nickel 2005-05-30 06:35:49 UTC
Please describe the problem:
Currently, muine does not URL encode URL strings. This creates an unexpected
behavior when the URL's given by Muine are processed by functions like
URL.LocalPath. Filenames with % and ? in them are processed incorrectly, making
functions that depend on them broken.

I think the ideal solution would be to drop the "file://" on ISong.Filename
(It's a file name not a URL) or to change ISong.Filename to ISong.URI and
properly encode it. Drag and drop uri-lists too need to be handled properly.

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Brian Kerrick Nickel 2005-06-01 01:21:41 UTC
Created attachment 47087 [details] [review]
Patch to src directory

Okay, never mind on the Filename part, I was mistaken. As for the drag-and-drop
URI problem, this is solved by making FileUtils.UriFromLocalPath symetrical to
FileUtils.LocalPathFromUri
Comment 2 Brian Kerrick Nickel 2005-06-01 02:32:06 UTC
Created attachment 47090 [details] [review]
Real Patch, should work this time.

Accidentally converted tabs to spaces in previous patch.
Comment 3 Jorn Baayen 2005-06-13 07:53:56 UTC
This will be fixed properly once the switch to GnomeVfs# (in the works) is done.
Comment 4 Brian Kerrick Nickel 2005-07-26 22:49:37 UTC
In debugging MuineTagger, I found that GnomeVFS functions can't decode "file://"
prepended paths that contain "#". If you rename a file to contain a "#" and try
dragging it into nautilus from muine, it should copy, but nothing happens.

Could we apply my patch as a temporary solution until the GnomeVfs# transition
is complete?
Comment 5 Peter Johanson 2006-01-22 20:34:49 UTC
I agree that this is a good intermediary solution. The file named '#.mp3' is certainly not handled properly with just prepending 'file://', as a simple test case. I've just commited this patch, we'll revisit this with Gnome.Vfs love soon though.