Public bug reported:
Binary package hint: vlc
Hello! This is about VLC on Gutsy; however it probably applies to other
versions too.
The "Open File..." dialog (the complete one, not the quick one) has two
text fields for choosing the video and the subtitle file.
When drag-and-dropping a file on those fields, the content of the fields
becomes something like:
[file:///media/jester/series/Dawson's%20Creek%2C%20season%204/(411)%20Dawson's%20Creek%20-%20The%20Tao%20of%20Dawson.avi
]
Note the line break at the end; the text fields actually display the
numbers-in-a-box glyph for the 000D 000A characters (CRLF).
This is (IMO) wrong for several reasons:
(a) since the files are on the local filesystem, I think a simple path should
be used (this happens if the file is picked with the "Browse" button).
(b) the CRLF thing should be simply trimmed out, along with any other
surrounding whitespace. The video field isn't troubled by the CRLF, but if I
don't manually delete it from the subtitle field I get an error and the
subtitle doesn't load. (From the error message it's obvious that VLC
incorrectly looks for the file with the CRLF characters appended, which is
silly because they can't be part of a properly escaped URL like the one in the
box.)
(c) I see no reason why the URL would be escaped, since it's the only thing
that can be put in those fields. (The purpose of escaping is (i) to represent
the URL with a certain charset and (ii) to know where it ends (ie encode the
spaces), neither of which is necessary in those fields.)
(d) I just noticed that the fields accept multiple-file drops (yes, the
filenames are separated with CRLF) which is kind of silly since VLC can't do
anything with them. So that's probably wrong too.
(e) If I drop a file on those fields, the file's URL is _inserted_ into
whatever text was already there, at the drop point. Since the result of a file
drop is always a complete URL, and the fields can only handle one file, it
should instead _replace_ the text that was there IMO. Note that this is only
true for file drops; if I were to drop a simple piece of text, that's
different, I might want to assemble a path/URL with several drops.
A different thing: I sometimes notice VLC refuses to accept drops in
those fields (eg, no cursor change, nothing happens on button release);
I couldn't find out what the problem is. It appears sometimes, but I
can't reproduce it at others. It may be caused by some updates to
underlying libraries, I don't know.
** Affects: vlc (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
Binary package hint: vlc
Hello! This is about VLC on Gutsy; however it probably applies to other
versions too.
The "Open File..." dialog (the complete one, not the quick one) has two
text fields for choosing the video and the subtitle file.
When drag-and-dropping a file on those fields, the content of the fields
becomes something like:
[file:///media/jester/series/Dawson's%20Creek%2C%20season%204/(411)%20Dawson's%20Creek%20-%20The%20Tao%20of%20Dawson.avi
]
Note the line break at the end; the text fields actually display the
numbers-in-a-box glyph for the 000D 000A characters (CRLF).
This is (IMO) wrong for several reasons:
(a) since the files are on the local filesystem, I think a simple path should
be used (this happens if the file is picked with the "Browse" button).
- (b) the CRLF thing should be simply trimmed out. The video field isn't
troubled by it, but if I don't manually delete it from the subtitle field I get
an error and the subtitle doesn't load. (From the error message it's obvious
that VLC incorrectly looks for the file with the CRLF characters appended,
which is silly because they can't be part of a properly escaped URL like the
one in the box.)
+ (b) the CRLF thing should be simply trimmed out, along with any other
surrounding whitespace. The video field isn't troubled by the CRLF, but if I
don't manually delete it from the subtitle field I get an error and the
subtitle doesn't load. (From the error message it's obvious that VLC
incorrectly looks for the file with the CRLF characters appended, which is
silly because they can't be part of a properly escaped URL like the one in the
box.)
(c) I see no reason why the URL would be escaped, since it's the only thing
that can be put in those fields. (The purpose of escaping is (i) to represent
the URL with a certain charset and (ii) to know where it ends (ie encode the
spaces), neither of which is necessary in those fields.)
(d) I just noticed that the fields accept multiple-file drops (yes, the
filenames are separated with CRLF) which is kind of silly since VLC can't do
anything with them. So that's probably wrong too.
(e) If I drop a file on those fields, the file's URL is _inserted_ into
whatever text was already there, at the drop point. Since the result of a file
drop is always a complete URL, and the fields can only handle one file, it
should instead _replace_ the text that was there IMO. Note that this is only
true for file drops; if I were to drop a simple piece of text, that's
different, I might want to assemble a path/URL with several drops.
A different thing: I sometimes notice VLC refuses to accept drops in
those fields (eg, no cursor change, nothing happens on button release);
I couldn't find out what the problem is. It appears sometimes, but I
can't reproduce it at others. It may be caused by some updates to
underlying libraries, I don't know.
--
vlc's "Open File" dialog doesn't handle drag and drop correctly
https://bugs.launchpad.net/bugs/150380
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
