Qt - break long running GUI-update / event handling, e.g. by ESC key

Question

My Qt-Application (currently on PySide2 (Qt 5.15.6)) uses QTreeViews and appropriate Models to show big hierarchical structures, some of them really deep and/or containing reference loops. For displaying only nodes that match a given QRegExp I derived QSortFilterProxyModel and reimplemented filterAcceptsRow to decide if a node should be displayed. In case a node doesn't match the RegExp, I walk down recursively to check if any of its' descendants match... more or less that's shown in the code below.

def filterAcceptsRow( self, row, parent ):
    def _match( index ):
        return regExp.exactMatch( pathOf(index) )

    def _check( *indices ):
        return any( _match(idx) for idx in indices ) or \
               any( _walk(idx)  for idx in indices )
    
    def _walk( index ):# . o O (how to determine that break was requested?)
        if _breakRequested(): return False
        else                : return any( _check(idx) for idx in childrenOf(index) )

    return _check( indexOf( row, col, parent )

This works usually quite well and (with some optimization) fast. However, in case of a deep tree structure and a careless user input the recursive descent might take a while what is leading to a blocked GUI.

So long story short: Is there any way of aborting an intensive GUI update (like here filtering nodes) by e.g. pressing ESC?
Here some thoughts and/or what I tried so far...

• Since filterAcceptsRow is called from Qt for updating the GUI I guess I can't really shift it to some worker thread, right? Well, I tried and it ended fatally ... :-S
• In the dummy code above I put a call to _breakRequested() where I would ask for a break request. But how would such function look like?
• Since we're right in processing some Event that led to our filtering the event loop is blocked and can't register any key strokes, right?
• Calling processEvents() here (in order to detect key strokes) would mix the processing order of events. According to the try I gave it, bad idea :-(.

I searched and tried a lot of different approaches, without luck. Am I really the only one who wants to escape from a blocked GUI while the blocking part can't be shifted to another thread?

• Basically I don't need to (and must not) process the events at that point (_breakRequested()). I would be fine with an event look ahead by sneaking along the event queue and looking for an according key event. However this doesn't seem possible in Qt before version 6.
• Even if it was possible, is Qt registering Events (adding them to the event queue) between subsequent calls to filterAcceptsRow? Is there something like queueEvents() without processing them?
• While the GUI is busy, is it possible to open another (modal) Widget with its' own thread and event loop listening for key strokes?

Sorry if this all is just bullshit but as you see, I got a bit stuck ... can somebody show me the light, please?

Answer 1

I'm not sure about your use case, but for blocked code segments I would generally try moving the computationally expensive task to a QThread so the mainwindow is still usable and then use for example a hotkey to send an "abort-signal" into the threaded object if needed

(see Background thread with QThread in PyQt for different methods)

and: https://realpython.com/python-pyqt-qthread/

---

Edit: "ugly approach" using QShortcut:

Events do not necessarily propagate among all widgets, if a widget consumes it then it will no longer propagate to the parent. In the case of the keyboard events will only be consumed first by the widget that has the focus, in your case QWebEngineView consumes them before and prevents it from being projected in other widgets. If you want to hear events from the keyboard of a window then you must use the QShortcuts

since you made a custom class already, you could add something like:

from PyQt5 import QtCore, QtGui, QtWidgets
class YourCustomClass(QSortFilterProxyModel):
    def __init__(self, parent=None):
        super(YourCustomClass, self).__init__(parent)
        self.flag = True
        QtWidgets.QShortcut(
            QtGui.QKeySequence("Escape"), self, activated=self.on_Escape
        )
    @QtCore.pyqtSlot()
    def on_Escape(self):
        self.flag = False

    def filterAcceptsRow( self, row, parent ):
        if self.flag:
            # ...
        else: return

im not sure if this will also block the event loop, but seems worth a try.

btw: you could also try limiting the maximum recursion depth for a user input.