Data set on unsupported clipboard mode. QMimeData object will be deleted.

410 views
Skip to first unread message

Largo84

unread,
Nov 24, 2015, 10:12:18 AM11/24/15
to leo-editor
I don't recall seeing this message in the startup log (terminal window) before today. I just updated to the most current version on GitHub.

reading settings in C:\Users\Rob\.leo\workbook.leo
Data set on unsupported clipboard mode. QMimeData object will be deleted.
cleaning C:\Users\Rob\.leo\spellpyx.txt
Data set on unsupported clipboard mode. QMimeData object will be deleted.
Data set on unsupported clipboard mode. QMimeData object will be deleted.
Data set on unsupported clipboard mode. QMimeData object will be deleted.


...and many more lines just like it after opening a Leo file.

Any idea what's causing that and if I should be concerned about it?
Rob.......

Leo Log Window
Leo 5.1-final, build 20151120111022, Fri Nov 20 11:10:22 CST 2015
Git repo info: branch = master, commit = a9465468020e
Python 3.4.3, PyQt version 5.4.1
Windows 8 AMD64 (build 6.2.9200) 

Terry Brown

unread,
Nov 24, 2015, 10:52:28 AM11/24/15
to leo-e...@googlegroups.com
On Tue, 24 Nov 2015 07:12:17 -0800 (PST)
Largo84 <Lar...@gmail.com> wrote:

> I don't recall seeing this message in the startup log (terminal
> window) before today. I just updated to the most current version on
> GitHub.

Hmm, this must be

https://github.com/leo-editor/leo-editor/commit/0c89affbb86adf2ad5b828bb8eb6b8c6517cf69d
and
https://github.com/leo-editor/leo-editor/commit/b9f0c578dd9aedf05bdd5fe3962c727f9d4b1f7f

Although I'm not seeing the "unsupported clipboard mode" error I think
a @setting would be good for this behavior, the changes subtly alter
the interaction with the rest of the system in a way I don't prefer -
used to be able to simply select text in another app. and middle button
paste it into Leo, now it seems you have to use Ctrl-C in the other
app. for anything except a very immediate paste.

It looks like the changes set the clipboard content sort of on focus
or on update rather than on a new selection, which is probably not
ideal although I can see why catching selection changes would be
trickier. So maybe two things here, a preference for the old behavior,
and somehow avoiding the unsupported clipboard mode.

Cheers -Terry

Largo84

unread,
Nov 24, 2015, 1:47:08 PM11/24/15
to leo-editor
Hmm, sorry I don't really understand what any of that means, but I'm not sure I need to. As a practical matter, should I be concerned about losing data or is this simply a change in the way Leo 'behaves'?

Rob.........

Terry Brown

unread,
Nov 24, 2015, 2:39:07 PM11/24/15
to leo-e...@googlegroups.com
On Tue, 24 Nov 2015 10:47:08 -0800 (PST)
Largo84 <Lar...@gmail.com> wrote:

> Hmm, sorry I don't really understand what any of that means, but I'm
> not sure I need to. As a practical matter, should I be concerned
> about losing data or is this simply a change in the way Leo 'behaves'?

No need to be concerned about losing data other than clipboard content,
and even then, I'm guessing you won't see any change - some systems
have two "clipboards", one that you explicitly copy to, and another
which is just the current selection, I think the last selection made in
multi-app. scenarios. I'd guess that your normal clipboard will be
unaffected, and the second one, which doesn't exist in all systems, is
the one that's bleating.

But Leo will need to be fixed to avoid generating the message. I'm
guessing QClipboard::supportsSelection() might need to be checked.

Cheers -Terry

Edward K. Ream

unread,
Mar 2, 2016, 6:38:00 PM3/2/16
to leo-editor
On Tue, Nov 24, 2015 at 1:39 PM, 'Terry Brown' via leo-editor <leo-e...@googlegroups.com> wrote:

On Tue, 24 Nov 2015 10:47:08 -0800 (PST)
Largo84 <Lar...@gmail.com> wrote:

> As a practical matter, should I be concerned
​ ​
about losing data or is this simply a change in the way Leo 'behaves'?

No need to be concerned about losing data other than clipboard content,
and even then, I'm guessing you won't see any change - some systems
have two "clipboards", one that you explicitly copy to, and another
which is just the current selection, I think the last selection made in
multi-app. scenarios.  I'd guess that your normal clipboard will be
unaffected, and the second one, which doesn't exist in all systems, is
the one that's bleating.

But Leo will need to be fixed to avoid generating the message.  I'm
guessing QClipboard::
​​
supportsSelection() might need to be checked.

​What's the status of this? Is it worth an official bug report?

Edward

Largo84

unread,
Mar 2, 2016, 11:59:04 PM3/2/16
to leo-editor
I still see the error from time to time, but I don't know if it needs a bug report since there doesn't appear to be any harm done. I can post a report the next I can duplicate the error reliably if you think I should.

Rob...............

Edward K. Ream

unread,
Mar 3, 2016, 5:03:57 AM3/3/16
to leo-editor
On Wed, Mar 2, 2016 at 10:59 PM, Largo84 <Lar...@gmail.com> wrote:
I still see the error from time to time, but I don't know if it needs a bug report since there doesn't appear to be any harm done. I can post a report the next I can duplicate the error reliably if you think I should.

​Please do. The report will be good data. The bug itself could be assign "minor" status. It's much easier to track issues with the tracker than with email.

Edward
Reply all
Reply to author
Forward
0 new messages