Did tested in max 2023 and it fixes the issue with showing up help pop up window but introduces strange switching to the other publish pane....see the vid for more insight.

Need to be addressed.
Publisher_Enter_Confirm.mp4

@LiborBatek Ok, so this is due to the Help button not receiving focus but now the Create tab (top left) takes the focus and thus enter clicks that tab entry. When I disable the focus policy for the tabs themselves then the next focus is the "Save" icon bottom right. As such clicking enter "saves" the settings which I'm not sure is preferred either.

@iLLiCiTiT I feel like we're better off ensuring that the KeyPressEvents doesn't pass through to begin with from the Create Options Widgets and the Instance Publish Option widgets

Currently whenever actively being in any of the fields in this part of the UI:

And this one:

For example:

• Typing in the "Filter assets..." field and pressing enter
• Typing a comment and clicking enter
• In Publish tab typing the variant name for an instance and pressing enter
• In Publish tab instance options on a text/numerical field pressing enter
• In Create tab pressing enter in variant field or text/numerical options and pressing enter
• In Details tab selecting a plug-in, then pressing enter

Each of these then pass the enter key to the active focus object of the Window, which defaults to the "?" button and if like this PR focus policy is removed there proceeds to the Tabs (Create tab by default) and if disabled there proceeds to the bottom controls like "Save" icon.

Actually applies the Enter key event to the focused object, like the Help button, the Tabs above it or the Controls below it. I'd actually argue however that if currently any of the entries in the screenshotted areas above are active that it should not pass through key events (or at least not enter keys?) We'd still want to be able to TAB out of it however?

Basically what we want is that when active in those areas to not proceed to pass the key events to the other widgets outside of it.

Can we add the ignore logic to existing method in window?

if event.key() in {
    QtCore.Qt.Key_Return,
    QtCore.Qt.Key_Enter,
}:
    event.accept()
    return

Can we add the ignore logic to existing method in window?

if event.key() in {
    QtCore.Qt.Key_Return,
    QtCore.Qt.Key_Enter,
}:
    event.accept()
    return

As far as I know we can not put it on the Window itself - because children widgets as far as I know will still be first receiving the event before it hits the Windows' event upstream. We could install an event filter on the window which triggers for ALL children events but that'd just be slower / getting way more events than we'd like.

Basically the logic is this:

• text field, press enter. does the text field process the event?
• while not processed, does the parent process the event? (recursively going up the parents to the first one dealing with the event)

As far as I know we can not put it on the Window itself - because children widgets as far as I know will still be first receiving the event before it hits the Windows' event upstream

I've tried and it does not trigger the button... I think the default (button with default set as True) is triggered only if the event is not accepted at any child of the window hierarchy.

@iLLiCiTiT seems to work - like this?

Weird - If you open for example max and publisher, hit enter, then help window will appear. But after reset, enter won't open it anymore. Same thing in Houdini

That's because the active button then has changed to the reset button most likely (or some other field). Anyway, that goes to show that this new fix with the event capture on the window does not work and we should likely revert again to this commit 4606484

@antirotor can you confirm that commit instead works as intended?

@antirotor can you confirm that commit instead works as intended?

it doesn't work either - I replicated the original change from 4606484 in the new code:

    def keyPressEvent(self, event):
        # Ignore escape button to close window
        if event.key() == QtCore.Qt.Key_Escape:
            event.accept()
            return

        # Avoid enter key to activate the "help" dialog, fix #5791
        return super().keyPressEvent(event)

also it behaves differently when you click on different parts of the publisher window. On some parts, the help window won't pop-up, but on the others it will.

@antirotor can you confirm that commit instead works as intended?

it doesn't work either - I replicated the original change from 4606484 in the new code:

    def keyPressEvent(self, event):
        # Ignore escape button to close window
        if event.key() == QtCore.Qt.Key_Escape:
            event.accept()
            return

        # Avoid enter key to activate the "help" dialog, fix #5791
        return super().keyPressEvent(event)

also it behaves differently when you click on different parts of the publisher window. On some parts, the help window won't pop-up, but on the others it will.

Note that it was on a different class - not on the window. Did you do that? Best to just checkout that commit actually.

also it behaves differently when you click on different parts of the publisher window. On some parts, the help window won't pop-up, but on the others it will.

Correct - it will propagate "upwards" - in our case we're looking to just avoid it opening the help dialog I suppose.

Note that it was on a different class - not on the window. Did you do that? Best to just checkout that commit actually.

Well, the original commit works, but not for the first time - when you open the Publisher and immediately hit enter, help will open. But once you click on anything inside or reset, enter will no longer open help window.

Note that it was on a different class - not on the window. Did you do that? Best to just checkout that commit actually.

Well, the original commit works, but not for the first time - when you open the Publisher and immediately hit enter, help will open. But once you click on anything inside or reset, enter will no longer open help window.

That sounds fine - maybe somewhat confusing, but more acceptable than pressing enter in the text fields doing it.

@iLLiCiTiT thoughts? Revert to that commit - other options?

This issue was resolved by merging #6107

closing.