* Most cases don't have other text together with a ResourceId, so handle an
isolated ResourceId specially and manually render it.
* Further work - we could cache the name the same way as the RichResourceText
does. So far it doesn't seem to appear on profiling.
* This allows us to add rich text support much more easily into other itemviews
like RDTableView.
* We set it up for debug messages so that resource links in debug messages can
be linked.
* We need to inherit to chain these two, as otherwise when the tree view
delegate calls sizeHint() it passes to the tree widget delegate, but
then has no way to return back to the tree view for the overridden
initStyleOption.
* If there was a built-in way to chain delegates like styles (which
solve this problem by calling back to baseStyle when going from one
function to another), or better yet a way to avoid the base
QStyledItemDelegate initStyleOption from completely trampling all over
the option passed in to any function, this wouldn't be necessary.
* Reported by Coverity Scan - most of these are not an issue and a
couple of them are coverity getting really confused (like seeing a
pointer being assigned to NULL and a count to 0, then a few lines
later declaring that a loop 0..count will dereference the pointer).
* However it's harmless in all cases to add a bit of robustness to keep
the analysis happy.
* Annoyingly although Qt has an internal bool allowUserMoveOfSection0
which does exactly what we want allowing the tree column to be
movable, we can't enable it because it's private. So instead we have
to re-implement section moving ourselves.
* Minor tweak - also made RDTreeWidgets non-movable by default since
usually we don't want to allow it.
* There's a messy order-of-operations thing to deal with various
different themes, as well as a couple of minor problems, but at least
the highlight and selection bars draw fairly consistently and don't
leave an ugly gap over the branches.
* This still isn't perfect with some custom style stuff but it's next
to impossible to get working right. In theory we should manually
draw PE_PanelItemViewItem in the gap in drawRow() or so to make sure
we also draw any on-hover highlight over objects, but that doesn't
seem to work.
* We add our own custom item model to handle the cases we need. We can
also make a few assumptions and optimisations around things we can
safely assume like e.g. nodel columns won't really change after init.
* This lets us have full control over batching updates, which was the
main motivation, but it makes it easier to extend in future (e.g.
adding single per-item tags instead of the heavyweight Qt::UserRole
data elements).
baldurk