Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

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

nocnokneo opened this issue Nov 14, 2014 · 3 comments

Comments

@nocnokneo
Copy link

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
Copy link
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
Some applications may prefer Text over URL mime data, so provide both.

Related-to: #373
Signed-off-by: David Aguilar <davvid@gmail.com>
@davvid
Copy link
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
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 git-cola#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
* 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 git-cola#373
Signed-off-by: David Aguilar <davvid@gmail.com>
@davvid davvid closed this as completed in eb49ddf Nov 16, 2014
@nocnokneo
Copy link
Author

Awesome! git-cola keeps getting better and better!

davvid added a commit that referenced this issue Nov 21, 2014
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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants