Thanks all.

I went for this solution:
After I created a tool that I wanted to have some help available for, I registered it in a central help object with its "parentPath" and the name of the helpfile I wanted to associate it with.

The parentPath, I found by connecting the objectName() of all the ancestors. This key would uniqely identify the help file to open for that object. This allows for more detailed help files further down the hierarchy.

When I wanted to open a help file, I simply used the focusWidget() widget and built the parentPath from that. I opened the helpfile with the longest parentPath that still fit with the parentPath:

":BOCS__Main::qt_workspacechild:ConfigureDlg:cmbB_ mode" would open the helpfile associated with ":BOCS__Main::qt_workspacechild:ConfigureDlg" and when I focus on a widget with more detailed help: ":BOCS__Main::qt_workspacechild:ConfigureDlg:split ter:groupBox_2:cmbB_stratType" it would open the file associated with ":BOCS__Main::qt_workspacechild:ConfigureDlg:split ter:groupBox_2:cmbB_stratType"

It may not be the most elegant solution, but it works and would always come up with a helpfile as it traverses back up the ancestry tree until it would probably find some smaller file or just open the default helpfile for the application.

One problem though: When you create a dialog and put it in the workspace, you automatically give away the ownership and the parentPath will change, e.g., the qt_workspacechild-part in my example. I therefore don't register the dialogs in their constructor, but rather call a registerHelp() after the dialog is shown.

This opens for detailed help associated with a single widget anywhere in my system, e.g. a more elaborate help for my "execute"-button as well as automatically opening the most detailed help for a widget.

There probably are endless problems that can occur, but as long as I'm aware of how it works, I can probably prevent most strange problems from happening.