We could indeed optionally (configuration based?) create the symlink later on ...

There are 2 stages of consideration here. One of (desired) functionality, and then how to implement it.

Yeah, I have been slacking a bit in that area ...

Fine by me to add the missing 'detail' parse, you noticed it ;-)

The detail field not getting parsed probably started out intentionally and then turned into an oversight :-(
Regarding the sorting, it seems the following is needed (in suitable place);

if (m_sortOn->isChecked()) {
    m_symbols->setSortingEnabled(true);
    m_symbols->sortByColumn(0);
} else {
    m_symbols->sortByColumn(-1);
}

Otherwise, it looks/works fine now!

For some of the other files, I copied over some "boilerplate" to get going, so nothing unique in there and (almost surely) already modified by now into other ways and forms ...

Looks nice indeed!

Thanks for the new feature! However, a few regressions and concerns:

• the "show details" action is no longer enabled/disabled depending on whether useful detail info is available
• the detail is now in a separate column; if a server decides to present e.g. argument info there, it does not look that good in a separate column with not-so-useful white space in between (others thing probably also not either). While a bit hack-ish, that's why it was previously merged with the "main text".
• if the symbol view tree is (partially) collapsed, and then the item tracking kicks in to sync with cursor position, the tree is expanded again, rather than showing topmost relevant (visible) item. Previously, it was kept collapsed, as presumably so done by user for a reason.
• the flat-list option is gone as well as already mentioned (whether or not it may be deemed useful)

Oops, missed that part, but by the spec indeed.