I get the first paramter. signalMapper is used because it's the Object of action, right?
But how and why did the map()-function become a Signal too? (Usually this line has no comments unfortunately).
The third is clear, that's the parent...
But since when does the clicked-Signal really have a QString as parameter...?

Map doesn't become a signal, it's a slot that will be used to generate the various mapped signals.

The clicked signal never has any QString parameter. When calling setMapping you associate a QWidget with e.g. a QString. Then when map is called it gets the string matching the object that call map and emit the corresponding mapped signal

Hi, I recently had good use of QSignalMapper, but it's like you say, it takes a while to wrap your head around it.

First, motivation for its existence: while Qt's signal/slot mechanism generally works fine and dandy, sometimes there are some roadkill/missing information during those signal/slot transits. What I mean, your slot() function in your code, to work properly perhaps needs some extra stuff that the Qt standard signals do not supply.

In my case, it's a plugin that's registered lots of keystrokes inside Qt Creator. Problem was, Qt Creator's ActionManager wakes my plugin up with an triggered signal() that has no parameters. So how can I deduce what keystroke(s) are pressed? QSignalMapper to the rescue.

QSignalMapper acts as a proxy/middleman. So instead of me directly connecting ActionManager's signal to my keyprocessing slot() function, I create a new instance of QSignalMapper and connect ActionManager's signal to the map() slot of that QSignalMapper instance:
@
// new up an action and a signalmapper and connect them
auto action = new QAction(tr(baDescription), this);
auto signalMapper = new QSignalMapper(this);
signalMapper->setMapping(action,ks.toString()); // use the string representation as the key/index
connect(action, SIGNAL(triggered()), signalMapper, SLOT(map()));
@

Note the setMapping() call prior to the connect(), this is where I instruct QSignalMapper to augment the vanilla triggered() signal with a string value.

About QSignalMapper's slot/signal names, agree they can be somewhat confusing: map() is QSignalMapper's fixed "receptacle" slot name, setMapping() is the important proxy/augmentation data setup, and mapped() is the fixed outgoing signal name.

(If I change that string later during runtime QString's implicit sharing/copy-on-write will kick in so QSignalMapper will not be bothered by that.)

Then that QString lies dormant inside the bowels of QSignalMapper, waiting for someone to trigger the map() slot in it. When that happens, it will fetch the QString from its QHash and emit it with the mapped() signal to the "real" receiver inside your code.

bq. What would happen if I’d add a different slot here?

Well it's standard Qt stuff, so I advise against it. (You could try and subclass it.)