Drag-and-Drop Failures

[tbpassin]

Dragging and dropping files from the desktop or file manager onto an open Leo outline fails. A typical error message reads

Traceback (most recent call last):
  File "c:\Tom\git\leo-editor\leo\plugins\qt_frame.py", line 3325, in dropEvent
    self.urlDrop(md, p)
  File "c:\Tom\git\leo-editor\leo\plugins\qt_frame.py", line 3463, in urlDrop
    if scheme == 'file':
             ^^^^^^^^^^
AttributeError: 'str' object has no attribute 'scheme'

This seems to be the result of an effort to correct a possible Qt bug from 2014. That bug in QUrl doesn't exist in current Qt6 implementations.

The problem is in qt_frame.py, in the method LeoQTreeWidget.urlDrop & helpers. I will submit a PR with fixes.

More specifically, the code receives a QUrl from the drop event. The QUrl will contain a scheme, and Leo's code checks whether the scheme is file or http. The existing code converts the QUrl to a string and then tries to call .scheme() on it, which of course fails, since scheme() is a method of a QUrl, not of a string. Also, most URLs one would drag from a browser are https, not http, so the code needs to look for them too.

Helper methods expect a string, not a QUrl, so the QUrl object can't be passed directly to them.

These are all easy to fix.

[edreamleo]

@tbpassin Thanks for your offer to fix this issue.

[tbpassin]

After fixing the code so that Leo outlines can be drag-and-dropped, non-Leo files still failed. Their at-file nodes were created but the body wasn't populated.

This turns out to be a problem in at.read(). The lines involved are

    fileName, file_s = at.openFileForReading(fromString=fromString)
    # #1798:
    if file_s is None:
        return False  # pragma: no cover

The problem is that even if - as in our case - the arg fromString is a non-empty string, then file_s es None and so False is returned. But before this, at.openFileForReading() will set at.read_lines so that the whole routine can "read" the string from its internal attribute instead of from a file. This is what we want.

Therefore at.openFileForReading() should not return (None, None) when there is actually a data string available. It would be easy to fix this but I'm not sure about changing at.openFileForReading() in case it is used elsewhere. Instead, I suggest the following minor change to at.read():

    fileName, file_s = at.openFileForReading(fromString=fromString)
    # #1798, #3876:
    if file_s is None and not at.read_lines:
        return False  # pragma: no cover

This change allows the contents of the external file to be placed into the new body node - which is what we want - and should either have no effect for any other use of `at.read()', or even fix similar bugs for other uses of the method.

If this is acceptable I will go ahead and add this change to my PR.

[edreamleo]

@tbpassin I agree with your analysis, but not your fix.

A cff shows that only at.read calls at.openFileForReading, but in any case at.openFileForReading should act reasonably if fromString is not None. So my suggested fix (tested) is in at.openFileForReading:

    if fromString:  # pragma: no cover
        if is_at_shadow:  # pragma: no cover
            at.error('can not call at.read from string for @shadow files')
            return None, None
        at.initReadLine(fromString)
        return None, fromString  # #3876.

What do you think?

I would be happy to create a new PR for this single change.

[tbpassin]

I would be happy with this change. I will test it and add it to my open PR, since the changes in that PR have to happen anyway.

[edreamleo]

@tbpassin Alright, I'll leave the PR to you. Thanks!