Ways to check if a signal or event is blocked by another widget/ class etc

[kiteh]

I apologize in advance for the vague title but I would like to know if there are any ways that I can try using to check if the signals/ events in the parent is blocking the signals/events in the child widget, or vice verse?

class QSubAction(QtGui.QAction):
    def __init__(self, text="", parent=None):
        super(QSubAction, self).__init__(text, parent)
        self.setCheckable(True)
        self.setChecked(True)

class QCustomMenu(QtGui.QMenu):
    def __init__(self, title, parent=None):
        super(QCustomMenu, self).__init__(title=str(title), parent=parent)
        self.setup_menu()
        self.parent = parent

    def setup_menu(self):
        self.setContextMenuPolicy(QtCore.Qt.DefaultContextMenu)

    def mousePressEvent(self, event):
        print '\n--- qcustommenu mouse press event ---'
        print '>>> parent : ', self.parent
        print '>>> action : ', self.activeAction()
        print '>>> actionAt : ', self.actionAt(event.pos())

        '''
        # If the option is toggled within the tool:
        --- qcustommenu mouse press event ---
        >>> parent :  <tabbed_tool.ui.tabs.TabBar object at 0x7eff3bf2c128>
        >>> action :  None

        --- qcustommenu mouse press event ---
        >>> parent :  <tabbed_tool.ui.tabs.TabBar object at 0x7eff3bf2c128>
        >>> action :  <PySide2.QtWidgets.QAction object at 0x7efdb0ccfb00>


        # If the menu is in tear off mode:
        --- qcustommenu mouse press event ---
        >>> parent :  <tabbed_tool.ui.tabs.TabBar object at 0x7eff3bf2c128>
        >>> action :  None
        '''

        action = self.activeAction()
        if event.button() == QtCore.Qt.LeftButton:
            if not isinstance(action, QSubAction) and action is not None:
                action.trigger()
                return

            elif isinstance(action, QSubAction):
                action.trigger()
                return
        return QtGui.QMenu.mousePressEvent(self, event)


class TabBar(QtGui.QTabBar):
    def __init__(self, parent=None):
        super(TabBar, self).__init__(parent)
        ...
        ...

    def mousePressEvent(self, event):
        self._rename_tab_allowed = False

        if event.button() == QtCore.Qt.RightButton:
            self.show_context_menu(event.pos(), index)

        else:
            super(TabBar, self).mousePressEvent(event)

    def show_context_menu(self, position, index):
        role = self.tabData(index)
        self.context_menu = QCustomMenu(title="", parent=self)
        self.context_menu.setTearOffEnabled(True)

In my above code example, I have a QMenu, in which its items (QAction) are checkable.

The menu items can be toggle-able, however as soon as I tear off the QMenu, the `activeAction` are no longer registering in the `mousePressEvent` nor the menu items are toggle-able in this case.

Due to the complexity I have coded my tool, this is the snippet that is seemingly causing the issues (pardon me for not being able to post a working version)

Appreciate in advance if anyone could share of a workaround (if there are any) to check for this 'blocking'

[Justin Israel]

The idea of checking for blocked signals/events is probably not the issue here. I don't have in-depth knowledge of the underlying tear-off menu logic, but a little bit of searching on it gives a good idea of what could be going on. The docs for QMenu.tearOffEnabled describe that a tear off menu is an internal copy of the original menu with all the same action instances added. So that right there lead me to believe it is the cause of your issue. When I searched a bit more, I saw various posts confirming the same thing. Then I checked the source:

https://github.com/qt/qtbase/blob/5.12/src/widgets/widgets/qmenu.cpp#L89

You can see that this uses an internal QTornOffMenu which subclasses QMenu. The constructor takes your original custom menu and copies the actions into it. This means that your custom menu event handling is no longer integrated with this tear-off menu, since the tear-off is not your actual menu. I don't have a concrete suggestion for how to go about applying your same custom class logic to the tear off menu. Some random ideas could be trying to focus all your custom logic into the actions and not the menu, since the actions get copied to a new menu. Or you would have to implement your own tear off so that you can control the new custom menu. Or you would have to detect when the tear off menu is created as a sibling to your custom QMenu (it is parented to the parent of your menu). 

 

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/7db8f7ce-4f0e-4aca-bae7-c4068268bb9f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[kiteh]

Hi Justin, thanks for replying back.
You are right about the tear off in which currently not only are my options being checkable, even when I tried to add new item within, it is not showing the new item unless I perform a new

Having said that, I am wondering if you could share insights with me on this matter ~ I have nested menus, coded in similar fashion in which during its tearoff, the sub items are actually toggleable and as I add new sub item, the items are added into the tear off too.

The only differences being, the sub items are added into the top level menu. And so, why isn’t the sub items affected?

[Justin Israel]

On Wed, Apr 17, 2019 at 3:42 PM kiteh <kiteh...@gmail.com> wrote:

Hi Justin, thanks for replying back.
You are right about the tear off in which currently not only are my options being checkable, even when I tried to add new item within, it is not showing the new item unless I perform a new

Having said that, I am wondering if you could share insights with me on this matter ~ I have nested menus, coded in similar fashion  in which during its tearoff, the sub items are actually toggleable and as I add new sub item, the items are added into the tear off too.

nested menus are wrapped in an action when they are added to a parent menu. When you use a tear-off, it adds the same action references to the tear-off menu. So any changes you make to those actions, such as adding more child menus/actions, would likely be reflected in both places. But anything custom you have done to the top level menu that is being torn-off is not going to be reflected since the tear-off is a generic copy.

 

The only differences being, the sub items are added into the top level menu. And so, why isn’t the sub items affected?

Not sure about this one. 

 

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/4043cf91-2d6a-4169-80e5-331e4bd7c18f%40googlegroups.com.