* 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.
* This is supported currently in the API inspector, constant buffer previewer, and resource inspector.
* The saved expansions are only saved while the capture is open, and will be reset each time.
* The GUIInvoke object takes a QObject, and uses QPointer to check that
it hasn't been deleted when the callback fires. This prevents delayed
callbacks from executing after the object has been deleted and
crashing.
* In most cases the pointer is just 'this'.
Disable the warning on 3rdparty files
${glslang_dir}/hlsl/hlslParseHelper.cpp
Disable the warning on files where fixing it would cause a non-OSX compile error
os/os_specific.cpp
* Because many of QHeaderView's functions are annoyingly not virtual,
we need some stub data available in QHeaderView even if it won't be
used for anything much, like the number of sections.
* 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.
* The Qt behaviour is that if you call setMinimumSize on a widget, then
the minimumSizeHint is IGNORED. So it is impossible to say "use this
minimum size, unless the widget wants a higher minimum size".
* So instead we do this ourselves in RDLabel. Sigh.
baldurk