ping anyone ?

IMHO, it's such a user-visible bug with several reports and it affects all apps that use KIO; it should be included if it can catch the 5.65 train.

I can confirm it fixes the issue in my local build (and the code LGTM).

Urgh. bool members as used here to share state between methods, with the assumption that they're always called together and in a certain order, are very brittle.

If KDirOperator is a child widget, and it receives and processes a key event, it can choose to NOT let the event propagate to the parent widget
[by calling accept() on the QKeyEvent, or returning false from event(), or true from eventFilter(), depending on how the event is processed -- isn't Qt easy? ;-)]

In D25420#571163, @ahmadsamir wrote:

IMHO, it's such a user-visible bug with several reports and it affects all apps that use KIO; it should be included if it can catch the 5.65 train.

I can confirm it fixes the issue in my local build (and the code LGTM).

No objections if folks smarter than me think the code is acceptable. :)

I'm not smarter than you, but I consider this code hacky :-)

In D25420#571165, @dfaure wrote:

If KDirOperator is a child widget, and it receives and processes a key event, it can choose to NOT let the event propagate to the parent widget
[by calling accept() on the QKeyEvent, or returning false from event(), or true from eventFilter(), depending on how the event is processed -- isn't Qt easy? ;-)]

The issue is that QAbstractItemView::activated does not have a QEvent as parameter and it is emitted from different places.
Meaning I can't use the Qt Event system to stop propagation of events triggering QAbstractItemView::activated, it is a Qt limitation IMO.
So I might just move this boolean in KDirOperator or try to detect the condition when activated will be emitted, unless there is something more elegant I am missing.
Moving the hack to KDirOperator is already somewhat cleaner.

So after a double-click, activated() is emitted, the boolean is set, and much later some Key_Enter event that should have been emitted, gets eaten?

Wouldn't an event filter on the QAbstractItemView solve your problem? Then you can catch the Return key before QAbstractItemView sees it, and call _k_slotActivated yourself, and decide whether to emit returnPressed as well?

I hope this makes sense, if not I can dig further later, I'm in a bit of a rush right now.

I'm actually wondering *when* we want KDirOperator to emit returnPressed at all. When the current index isn't a directory, I assume?

In D25420#571483, @dfaure wrote:

So after a double-click, activated() is emitted, the boolean is set, and much later some Key_Enter event that should have been emitted, gets eaten?

Wouldn't an event filter on the QAbstractItemView solve your problem? Then you can catch the Return key before QAbstractItemView sees it, and call _k_slotActivated yourself, and decide whether to emit returnPressed as well?

I hope this makes sense, if not I can dig further later, I'm in a bit of a rush right now.

I'm actually wondering *when* we want KDirOperator to emit returnPressed at all. When the current index isn't a directory, I assume?

Digging around in git history I found this:
https://cgit.kde.org/kdelibs.git/commit/?id=81e69464329ddad59600dde5a1a27f58a0b91188
with a detailed/great commit message.

I think there should be a set of rules for kfilewidget in the API docs, so that future behaviour changes in this, rather tricky, area are aware of the various "requirements" involved.

And, of course, more unit tests like the one in D19824... :D

In D25420#571548, @ahmadsamir wrote:

In D25420#571483, @dfaure wrote:

So after a double-click, activated() is emitted, the boolean is set, and much later some Key_Enter event that should have been emitted, gets eaten?

Wouldn't an event filter on the QAbstractItemView solve your problem? Then you can catch the Return key before QAbstractItemView sees it, and call _k_slotActivated yourself, and decide whether to emit returnPressed as well?

I hope this makes sense, if not I can dig further later, I'm in a bit of a rush right now.

I'm actually wondering *when* we want KDirOperator to emit returnPressed at all. When the current index isn't a directory, I assume?

When the view has nothing selected, in fact.

And, of course, more unit tests like the one in D19824... :D

This was not an automated test.

And, of course, more unit tests like the one in D19824... :D

This was not an automated test.

OK, thanks for clarifying that.

FWIW, this still doesn't work:

• Open a pdf in okular
• Invoke save as, navigate via the keyboard, highlight/select a dir, Enter, the file is saved inside that dir and the dialog closes