So clicking outside the edited name item is either a mistake or a "oh, I wanted to do something else before". So I think, for my use-case, it's better to have the user to confirm an edit action by pressing Enter or Return rather than clicking somewhere outside the editor.

Maybe a corner-case ;-)

Out of curiosity, why do you want that behavior ?

It's kind of counter intuitive with regard to how applications work with that kind of editing feature.

void PlayersEditor::keyPressEvent(QKeyEvent *event)
{
    if (event->key() == Qt::Key_Return || event->key() == Qt::Key_Enter) {
        m_enterPressed = true;
    }
    QLineEdit::keyPressEvent(event);
}

and

bool PlayersEditor::enterPressed() const
{
    return m_enterPressed;
}

And in my QStyledItemDelegate's setModelData, I simply do

if (! m_editor->enterPressed()) {
    return;
}

Which leaves the model unchanged and "just" closes the editor. Maybe not the "right" way, but it works …

Edit: Just to mention this: one has to declare m_editor as mutable to be able tol set it inside createEditor, as this function is const.

The problem is that I don't know what to change to achieve this and where to change it (in a custom editor or the delegate) … also, I don't know at which point which signals from the editor are connected to the delegate.

What I don't understand is: If the focusOutEvent causes editingFinshed to be emitted which finally causes commitData to be emitted and setModelData to be called, then why is setModelData called before I see focusOutEvent being called?!

#0  0x00005555556783de in PlayersPageDelegate::setModelData(QWidget*, QAbstractItemModel*, QModelIndex const&) const ()
#1  0x00007ffff7a8f325 in QAbstractItemView::commitData(QWidget*) ()
from /usr/lib64/libQt5Widgets.so.5
#2  0x00007ffff7a8e480 in ?? () from /usr/lib64/libQt5Widgets.so.5
#3  0x00007ffff6f5daae in QMetaObject::activate(QObject*, int, int, void**) ()
from /usr/lib64/libQt5Core.so.5
#4  0x00007ffff7aa8adf in QAbstractItemDelegate::commitData(QWidget*) ()
from /usr/lib64/libQt5Widgets.so.5
#5  0x00007ffff7aa9845 in ?? () from /usr/lib64/libQt5Widgets.so.5
#6  0x00007ffff7aa99a8 in ?? () from /usr/lib64/libQt5Widgets.so.5
#7  0x00007ffff6f5e66a in QObject::event(QEvent*) () from /usr/lib64/libQt5Core.so.5
#8  0x00007ffff7841501 in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
from /usr/lib64/libQt5Widgets.so.5
#9  0x00007ffff7848af8 in QApplication::notify(QObject*, QEvent*) ()
from /usr/lib64/libQt5Widgets.so.5
#10 0x00007ffff6f358a1 in QCoreApplication::notifyInternal2(QObject*, QEvent*) ()
from /usr/lib64/libQt5Core.so.5
#11 0x00007ffff6f389c6 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ()
from /usr/lib64/libQt5Core.so.5
#12 0x00007ffff6f86763 in ?? () from /usr/lib64/libQt5Core.so.5
#13 0x00007ffff5b046fd in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#14 0x00007ffff5b04998 in ?? () from /usr/lib64/libglib-2.0.so.0
#15 0x00007ffff5b04a2c in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#16 0x00007ffff6f86503 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
    () from /usr/lib64/libQt5Core.so.5
#17 0x00007ffff6f34873 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
from /usr/lib64/libQt5Core.so.5
#18 0x00007ffff6f3c482 in QCoreApplication::exec() () from /usr/lib64/libQt5Core.so.5
#19 0x00005555556034c6 in main ()

Seems like it's called by QAbstractItemDelegate::commitData, but I can't override it in my delegate ("… is marked as override but doesn't")? [Edit:] Okay, that's because it's a signal, not a function.

but I still don't know how it works …

You should not know how it works you should take a look at the backtrace to see from where it is triggered - somewhere the text must be read from the QLineEdit which is nearby the place you can jump in.

Apparently, setModelData is called via QAbstractItemDelegate::commitData(QWidget*), but I still don't know how it works …

Question is if I need to know how the internals work, as I only want to handle the editingFinished signal (I suppose) and decide, based on if Enter/Return has been pressed or the focus was lost, if I reset or commit the data …