I suppose this could be fixed in at least a couple of ways:
- implementing the escapePressed handler on the top-level Popover element, instead of on its foreground child (I just did a quick test and it seems that in this case, if overriden, both the original handler and the override are called, not sure whether that’s intended or a bug in QML, but in any case that would work for our use case)
- adding a cancel() or escape() signal on the popover which would be emitted when ESC is pressed, thus allowing embedders to do specific processing, while keeping the default behaviour of closing the popover
I suppose this could be fixed in at least a couple of ways:
- implementing the escapePressed handler on the top-level Popover element, instead of on its foreground child (I just did a quick test and it seems that in this case, if overriden, both the original handler and the override are called, not sure whether that’s intended or a bug in QML, but in any case that would work for our use case)
- adding a cancel() or escape() signal on the popover which would be emitted when ESC is pressed, thus allowing embedders to do specific processing, while keeping the default behaviour of closing the popover