Closed cristian64 closed 7 months ago
I' ve been seeing this for years, assumed it was intended behavior and simply edited out the file://
when dropping a file into the terminal. Note that mate-terminal is but a wrapper around VTE, so while I can confirm this is occurring it is probably something that has to be fixed in VTE (or marked WONTFIX if this is intended behavior) rather than by us
I tested other terminals (e.g. GNOME Terminal), that are also based on VTE, and they do not show this behavior.
(I, too, have been manually dropping the URI schema for years. Specially annoying when the filepath has spaces.)
Note that drag and drop between two programs is an interaction between them. Here we have caja as the source, VTE as the destination, and maybe or maybe not (I don't know) mate-terminal in between. Problem might be in Caja: I fired up Nemo, dragged some directories to it and got the proper path names. Afterwards I was unable to duplicate this issue anymore within the same session at least even from caja
It goes down to what MIME data the source application inserts in the clipboard. A quick peek shows that, when a file is copied in Caja (select file; press Ctrl+C
), the following MIME formats are made available in the clipboard:
text/plain
text/plain;charset=utf-8
text/uri-list
x-special/mate-copied-files
In my tests, I used Caja as source for all the VTE-based terminals I could find (MATE Terminal, GNOME Terminal, Terminator, and sakura), but the unexpected behavior is only seen in MATE Terminal.
I think Caja does a sensible thing making text/uri-list
available, as the user may paste it on an application that would welcome the file URI version (e.g. a web browser). However, it seems MATE Terminal (but not the others) wrongly picks up the text/uri-list
data over the text/plain
data.
I'm not sure if the same MIME data is put in the clipboard during a drag & drop operation, or how Nemo manages it, but all it's needed to trip MATE Terminal up is a source application that inserts both MIME formats (text/uri-list
and text/plain
) in the clipboard. For example, this minimal application can be used to populate the clipboard:
from PySide6 import QtCore, QtWidgets
app = QtWidgets.QApplication()
def set_mime_data():
mimedata = QtCore.QMimeData()
mimedata.setData('text/plain', b'/tmp/foobar') # GNOME Terminal (and all other VTE-based terminals I've tried) pick this one up
mimedata.setData('text/uri-list', b'file://tmp/foobar') # MATE Terminal picks this one up
app.clipboard().setMimeData(mimedata)
QtCore.QTimer.singleShot(100, set_mime_data)
QtCore.QTimer.singleShot(1000, app.quit)
app.exec()
When I say the behavior is "unexpected" (or "wrong") it's because I can't think of a general use case in which a user would want a file URI in the terminal instead of the natural filepath in the filesystem, but I can't be sure whether it's unintended behavior.
the only logical thing for mate-terminal would be to autoconvert text/uri-list
to text/plain
when pasting
current workaround: I use middle click to paste. there its replaced correctly
Do we know if anyone considersfile:///
the expected behavior?
the only logical thing for mate-terminal would be to autoconvert
text/uri-list
totext/plain
when pasting
Only if text/plain
is not available, though.
Steps to reproduce the behaviour
Expected behaviour
A regular filepath [that the filesystem can recognize] should be pasted. For example:
Actual behaviour
A file URI is entered. For example:
MATE general version
MATE 1.26.0, MATE 1.26.1
Package version
MATE Terminal 1.26.0, MATE Terminal 1.26.1
Linux Distribution