This reverts commit ef35aa7954
because it contained too much wrong things that I won't be
using. I'll re-commit stuff from it after that that I do
want to keep.
This work extends AIStateMachine to run multiplex() in the thread
that calls run(), cont() or set_state(). Note that all three
eventually call locked_cont(), so thats where multiplex() is called
from. Calling multiplex() means "running the state machine", as in
"calling multiplex_impl".
Currently only LLURLRequest uses this feature, and then only
for the HTTPGetResponder, and well only for the initializing,
start up and normal finish states.
A current/remaining problem is that we run into a situation where
the curl thread runs a statemachine to it's finish and kills it,
while the main thread is also 'running' it and tries to call
multiplex while the statemachine isn't running anymore.
This causes LLSnapshotLivePreview::getAspectSizeProblem to never return
CANNOT_CROP_HORIZONTALLY or CANNOT_CROP_VERTICALLY anymore, making
the chance to successfully upload or save to a different target larger.
Adds support for GamingData cap, and flags: PF_GAMING, DFQ_FILTER_GAMING, REGION_FLAGS_GAMING, and REGION_FLAGS_HIDE_FROM_SEARCH
Adds GamingCheck to floater_about_land.xml
Adds filter_gaming checkboxes to floater_directory* xmls
Adds "is gaming" and "hide from search" checkboxes to floater_god_tools.xml
An LLFolderView is added as child to LLScrollableContainerView,
but also adds the LLScrollableContainerView to it's mScrollContainer.
As a result, when scrolling inside a LLFolderView the event is passed to
the mScrollContainer, which then passes it first on to it's children
(see the "Bad UI design" remark in the code), causing an infinite loop.
This patch breaks that loop for those objects that have a
mScrollContainer: LLFolderView and LLContainerView.
This adds a counter and a 'dead' flag to the data stored in the linked
list. The counter counts the number of iterators (still) pointing to an
element and the dead flag is set to indicate the element was erased when
iterators are still pointing to it. As a result, iterators are NEVER
invalidated. Of course, such elements are subsequentially skipped when
iterating over the list. Assertions protect against dereferencing an
erased iterator, but incrementing or decremention still works: it is
still well-defined what the next (non erased) element is, assuming the
element wasn't erased (yet), but would be erased delayed - or assuming
the iterator would have been incremented (decremented) in advance to
erasing the element.
