Text version of drag-and-dropped file does not work as expected #373

Closed
nocnokneo opened this Issue Nov 14, 2014 · 3 comments

Comments

Projects
None yet
2 participants
@nocnokneo

Deficiencies compared to the way drag-and-drop works when dragging and dropping files from e.g. Nautilus file browser to a terminal window:

  • the path is terminated by the newline which is very inconvenient for dropping into a terminal window (Nautilus appends a space)
  • the path is not quoted
  • dragging multiple files does not work

With Nautilus the dropped string looks like: '/path/to/file a' '/path/to/file b'

@davvid

This comment has been minimized.

Show comment
Hide comment
@davvid

davvid Nov 15, 2014

Member

Interesting.. let me test a few things. The relevant code is in cola/qutils.py ~ line 798 def mimedata_from_paths.

We're using QMimeData.setUrls(list-of-QUrls), and we're definitely not adding the newlines internally. iTerm2 on mac osx handles the drop fine -- the files are separated by spaces and filenames with spaces come out as e.g. Foo\ Bar, which is at least shell-friendly.

I'll pushed up a version that uses both setText() and setUrls(). I'll test it using various Linux terminals. On iterm2, I had to comment-out the setUrls() line to start getting the text (which is quoted and space-separated via subprocess.list2cmdline()) to show up, as it seems that iterm2 handles the URLs in the mimedata...

Can you try that out and see if there's a difference between both text and urls being present, vs just text? What terminal are you using ~ could it be that its mimedata URL handling code is adding the newlines?

Member

davvid commented Nov 15, 2014

Interesting.. let me test a few things. The relevant code is in cola/qutils.py ~ line 798 def mimedata_from_paths.

We're using QMimeData.setUrls(list-of-QUrls), and we're definitely not adding the newlines internally. iTerm2 on mac osx handles the drop fine -- the files are separated by spaces and filenames with spaces come out as e.g. Foo\ Bar, which is at least shell-friendly.

I'll pushed up a version that uses both setText() and setUrls(). I'll test it using various Linux terminals. On iterm2, I had to comment-out the setUrls() line to start getting the text (which is quoted and space-separated via subprocess.list2cmdline()) to show up, as it seems that iterm2 handles the URLs in the mimedata...

Can you try that out and see if there's a difference between both text and urls being present, vs just text? What terminal are you using ~ could it be that its mimedata URL handling code is adding the newlines?

davvid added a commit that referenced this issue Nov 15, 2014

qtutils: add text to the drag-and-drop mime data
Some applications may prefer Text over URL mime data, so provide both.

Related-to: #373
Signed-off-by: David Aguilar <davvid@gmail.com>
@davvid

This comment has been minimized.

Show comment
Hide comment
@davvid

davvid Nov 16, 2014

Member

I did a bunch of testing on Linux and I learned quite a few things...

The key thing is the text/x-moz-list mime data. The tricky part is that several terminals (e.g. xfce4-terminal) will use the text/uri-list mime data, and ignore the x-moz-list.

gnome-terminal, on the other hand, uses text/x-moz-url when present, so we have to make sure that it contains valid data.

terminator breaks in almost all configurations, so I gave up on supporting it.

x-moz-list is automatically added by Qt, but it contains garbage, so we have to create it ourselves. Comparing against nautilus, there's a bunch of other keys (UTF8_STRING, etc) that are emitted, so I am adjusting git-cola to do the same.

Member

davvid commented Nov 16, 2014

I did a bunch of testing on Linux and I learned quite a few things...

The key thing is the text/x-moz-list mime data. The tricky part is that several terminals (e.g. xfce4-terminal) will use the text/uri-list mime data, and ignore the x-moz-list.

gnome-terminal, on the other hand, uses text/x-moz-url when present, so we have to make sure that it contains valid data.

terminator breaks in almost all configurations, so I gave up on supporting it.

x-moz-list is automatically added by Qt, but it contains garbage, so we have to create it ourselves. Comparing against nautilus, there's a bunch of other keys (UTF8_STRING, etc) that are emitted, so I am adjusting git-cola to do the same.

davvid added a commit to davvid/git-cola that referenced this issue Nov 16, 2014

drag-and-drop: generate better mimedata for gnome-terminal
Generate a valid text/x-moz-url mimedata entry, encoded in
utf-16, so that gnome-terminal gets the right paths when
receiving the mimedata from git-cola.

This should improve drag-and-drop for most applications.

Closes #373
Reported-by: Taylor Braun-Jones <taylor@braun-jones.org>
Signed-off-by: David Aguilar <davvid@gmail.com>

davvid added a commit to davvid/git-cola that referenced this issue Nov 16, 2014

Merge branch 'drag-and-drop'
* drag-and-drop:
  doc: update v2.0.8 release notes draft
  drag-and-drop: generate better mimedata for gnome-terminal
  widgets: add text/plain and text/uri-list mimedata hints

Closes #373
Signed-off-by: David Aguilar <davvid@gmail.com>

@davvid davvid closed this in eb49ddf Nov 16, 2014

@nocnokneo

This comment has been minimized.

Show comment
Hide comment
@nocnokneo

nocnokneo Nov 16, 2014

Awesome! git-cola keeps getting better and better!

Awesome! git-cola keeps getting better and better!

davvid added a commit that referenced this issue Nov 21, 2014

qtutils: make the drag and drop encoding configurable
While gnome-terminal expects utf-16 encoded paths, other terminals, e.g.
terminator, expect utf-8.  There's no way we can sensibly handle this
situation without making the encoding configurable.

Add a cola.dragencoding variable that can be used to control the
encoding used during the drag and drop operation.  The default value is
utf-16, but suggest utf-8 in the documentation.  Mention terminator
since it is known to have a problem with the utf-16 default value and
works correctly when set to utf-8.

utf-8 would have been a better default if gnome-terminal were not the
default terminal in most Linux distributions.

Related-to: #373
Signed-off-by: David Aguilar <davvid@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment