hein added a comment.
In the review comment you write that users of the API can use the MIME data to decide whether to call setApplicationActions, but in https://phabricator.kde.org/D4576 you end up manipulating the provided QMenu instance directly, including code written in awareness of KIO implementation details like the "Determining MIME type" phase ... this expands the API contract from the signal to kind of include the UI design of the popup, which means KIO can never visualize this differently or drop QMenu for DropJob. Humm. I understand it's because async, but can we instead somehow teach the DropJob API to accept actions later, and instead of passing a QMenu around work with the DropJob and QActions to keep it UI-agnostic and the API contract documentable? REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D4575 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: mart, #plasma Cc: hein, plasma-devel, #frameworks, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
