https://bugs.kde.org/show_bug.cgi?id=457529
--- Comment #27 from Felix Ernst <felixer...@kde.org> --- (In reply to Harald Sitter from comment #26) > It's not lining up with our requirements anymore. QMimeData creation for > drag events is synchronous, we'd need it to be asynchronous because fusing > URLs for non-KDE apps does take [time]. I familiarised myself with the issue a bit now and have an idea. Let me know if I am missing something. How about we duplicate the `QMimeData` object, run `exportUrlsToPortal()` in a separate thread on that copy of the data while the drag operation with the original `QMimeData` is already happening, and then as soon as `exportUrlsToPortal()` is complete, we switch the `QMimeData` of the on-going drag-operation with the enriched `QMimeData` from the `exportUrlsToPortal()` call by using `QDrag::setMimeData()`? If we do this, the only remaining problem is when quickly drag-hovering over a sandboxed application while `exportUrlsToPortal` hasn't completed yet. To avoid any confusion with this we should show a loading cursor as long as `exportUrlsToPortal()` is still ongoing. -- You are receiving this mail because: You are watching all bug changes.
