Using "1" here was very specific to the build system, as noted by the comment.
When run on systems with older APIs install, it resulted in java compile errors.
* If an app only relies on reflection to set up its VAO, then its VAO
will morph to match the built-in implementation defined initial
locations of attribs and fragdata.
* Then when replaying on another implementation the VAO will no longer
match the changed locations.
* So instead we save the locations (whether they're user set or still
implementation defined) and restore them explicitly.
* We need to relink programs to update attrib bindings, which means the
shaders need to be still attached. There doesn't seem to be any harm
in leaving a shader attached to a program that should be detached -
it can still be used just fine in other programs.
* For VS output we can statically determine how much space is needed and
allocate more if we need to.
* For tessellation/geometry shader output, we need to run a query to see
if there was enough output space, then reallocate and run it again.
* On GL there isn't a built-in xfb query, only as an extension with poor
support, so we just resize to allow the maximum expansion.
* I'm not clear on if this is safe or sensible - somehow the source
program can report multiple outputs bound to the same index (e.g. 0)
but that's illegal to set explicitly ourselves. So we just ignore the
subsequent variables and hope the first one we find is the valid one.
* The other alternative is to set the subsequent variables to some bind
higher than all of the rest, or fill in holes (e.g. if we see 0, 0, 1
then bind the second 0 to 2).
* Since we're promoting everything, we reset the behaviour of
RDTreeWidget so that it's not doing anything different by default.
* RDTreeWidget's interface is a bit different, exposing some useful
things like a single selected item and so on.
* We also can't set columns in the Qt Creator UI anymore, so we set them
from code.
* 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).
* VAX can get confused by the QT_NAMESPACE macro, and if it thinks Qt
objects are inside a QT_NAMESPACE namespace then various things will
break but most commonly the ui objects inside that namespace won't be
picked up properly.
* See https://forums.wholetomato.com/forum/topic.asp?TOPIC_ID=12573
* We previously were only checking if all lookups had completed before
self-deleting, but we also need to make sure nothing externally is
still holding onto the dialog.
* This is only relevant for static qrenderdoc builds where the python
used isn't the system python, so it needs to locate its libs.
Otherwise the system libpython3.so and libs will be used.
Cody Northrop