https://bugs.kde.org/show_bug.cgi?id=457529
--- Comment #31 from Harald Sitter <sit...@kde.org> --- (In reply to Felix Ernst from comment #27) > (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. I've been talking about this with David Edmundson a while ago and IIRC this isn't going to be possible - right now. Currently the mimedata business must be a blocking operation, doing it any other way requires somewhat invasive changes to Qt's QPAs where at least on wayland we can make things more async. The core problem is that our mimedata **must** be finished by the time the drop/paste happens, simply running it in a thread wouldn't help one way or another because the thread might take longer than the user and then we have a race condition between user dropping and mimedata being complete. What we would need to happen is Qt supporting "temporary" mimetypes, where we set the mimetype "application/vnd.portal.filetransfer" with some temporary dummy data (so the potential receiver can see this mimetype as available) and when the actual drop/paste happens Qt goes "right, this mimedata is now being consumed, complete it **right now**" which would then force the async qmimedata filling to become sync. e.g. - drag initiates - dolphin fills "application/vnd.portal.filetransfer" with dummy data - dolphin starts thread to actually build the real filetransfer data - user moves the cursor to gwenview - gwenview looks at mimedata - finds "application/vnd.portal.filetransfer" and knows how to handle it - gwenview can receive the drop - user drops - dolphin receives Qt signal polishMimeData or something - dolphin waits for thread if it hasn't finished yet - dolphin fills real "application/vnd.portal.filetransfer" into mimedata - gwenview receives real data Notably this still means things are blocking, eventually, so IMO the first step is to actually improve the performance of kio-fuse so exportUrlsToPortal finishes in a more reasonable time frame than 10s. As a stop-gap measure I would still propose only exporting local urls https://bugs.kde.org/show_bug.cgi?id=457529#c24 -- You are receiving this mail because: You are watching all bug changes.
