make it possible for clients to access the qmenu instance
as is needed by the folderview containment to tweak the
entries provided by the copy job (move/link/copy)
just adding actions isn't enough as the containment
actually needs access to the actual QMenu
Details
- Reviewers
- None
- Group Reviewers
Plasma
the menu returned is valid and new items added in work
Diff Detail
- Repository
- R241 KIO
- Branch
- phab/dropmenu
- Lint
No Linters Available - Unit
No Unit Test Coverage
In the review comment you write that users of the API can use the MIME data to decide whether to call setApplicationActions, but in 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?