KDesktopFileAction solves such a problem by storing the desktop file path instead.

In D28367#691880, @dfaure wrote:

Hmm, turn KServicePtr m_service; into a raw pointer? Not sure the action can outlive its parent service?

Hmm, turn KServicePtr m_service; into a raw pointer? Not sure the action can outlive its parent service?

serviceClone is leaked because both KServiceAction and KService hold strong references to each other. In other words, when you destroy a KService with actions, you always leak a bit of memory. At the moment, I'm not sure how to resolve the issue without breaking the API compatibility.

And created https://invent.kde.org/frameworks/kio/-/merge_requests/1828 for KF6

Could not think of any reason, so created a patch to approach the octet-stream default extension in another way, some autotest included;
https://invent.kde.org/frameworks/kio/-/merge_requests/1827

Sadly now for octet-stream if ,currentExtension emtpy then extension becomes bogus ".". Was there any reason to make the new option not still also depend on currentExtension (edi: being empty)?

And now reported the challenge of drop objects lifetime vs user input on decisions by https://bugreports.qt.io/browse/QTBUG-125229

Hi. I just came across dropping random data (in my case an image) into file views not working, i.e. not creating any new files due to no more data in the QMimeData instance referred to in the DropJob.

KRunner/Milou:
https://invent.kde.org/frameworks/krunner/-/merge_requests/148
https://invent.kde.org/plasma/milou/-/merge_requests/69

This is done now.

• Replacement for Dialog is in progress
• Issues of FrameSvgItem are still valid on KSvg's FrameSgItem

All of the usages are in Plasma, so we could move it there to avoid carrying it in Frameworks

Remaining: