This is related to #1136. The issue is that the custom copy/search/delete action is executed and then on top the default implementation.
Once the Slot of copyRequest is executed the Clipboard is set with the correct contents and the keyEvent of the view continues with its default implementation. However, here the default copy action is executed next (only copying the highlighted element instead of all selected items, thus overriding the clipboard!).
Simply disabling the default copy/search/delete function would do no good, since some views may rely on the default implementation. Thus I would propose to add extra flags to the derived view classes to disable a certain default behavior (e.g. the default copy behavior).
A use case could look like this:
auto* view = new GtTableView(GtTableView::CustomCopy);
connect(view, &GtTableView::copyRequest, this, &MyCLass::onCopyRequest);
I cannot find a better solution.
Impact on the codebase
Since we need to add flags and thus extend the class with member variables there is an ABI chage. But since the current behavior is bugged, it should be addressed!
Summary
This is related to #1136. The issue is that the custom copy/search/delete action is executed and then on top the default implementation.
Once the Slot of
copyRequest
is executed the Clipboard is set with the correct contents and thekeyEvent
of the view continues with its default implementation. However, here the default copy action is executed next (only copying the highlighted element instead of all selected items, thus overriding the clipboard!).Simply disabling the default copy/search/delete function would do no good, since some views may rely on the default implementation. Thus I would propose to add extra flags to the derived view classes to disable a certain default behavior (e.g. the default copy behavior).
A use case could look like this:
I cannot find a better solution.
Impact on the codebase
Since we need to add flags and thus extend the class with member variables there is an ABI chage. But since the current behavior is bugged, it should be addressed!
Current workarounds
No response