Age | Commit message (Collapse) | Author |
|
Much as I dislike viewer log spam, seems to me starting a child process,
killing it and observing its termination are noteworthy events.
New logging makes LLExternalEditor launch message redundant; removed.
|
|
|
|
The idea is that, with the right flag settings, this will cause the OS to
terminate remaining viewer child processes when the viewer terminates --
whether or not it terminates intentionally. Of course, if LLProcess's caller
specifies autokill=false, e.g. to run the viewer updater, that asserts that we
WANT the child to persist beyond the viewer session itself.
|
|
|
|
Using a Params block gives compile-time checking against attribute typos. One
might inadvertently set myLLSD["autofill"] = false and only discover it when
things behave strangely at runtime; but trying to set myParams.autofill will
produce a compile error.
However, it's excellent that the same LLProcess::create() method can accept
either LLProcess::Params or a properly-constructed LLSD block.
|
|
This allows callers to pass either LLSD formatted as before -- which all
callers still do -- or an actual LLProcess::Params block.
|
|
|
|
Inventory
* Refactored LLFolderBridge::buildContextMenu fetch to clear and rebuild basic
context menu options after the fetch rather than trying to merge the two.
|
|
|
|
LLProcessLauncher had the somewhat fuzzy mandate of (1) accumulating
parameters with which to launch a child process and (2) sometimes tracking the
lifespan of the ensuing child process. But a valid LLProcessLauncher object
might or might not have ever been associated with an actual child process.
LLProcess specifically tracks a child process. In effect, it's a fairly thin
wrapper around a process HANDLE (on Windows) or pid_t (elsewhere), with
lifespan management thrown in. A static LLProcess::create() method launches a
new child; create() accepts an LLSD bundle with child parameters. So building
up a parameter bundle is deferred to LLSD rather than conflated with the
process management object.
Reconcile all known LLProcessLauncher consumers in the viewer code base,
notably the class unit tests.
|
|
by everyone
|
|
https://bitbucket.org/VirLinden/viewer-development-shining-fixes
|
|
LLRefCount::unref(), bad stacks
|
|
|
|
moved LLInitParam, and LLRegistry to llcommon
moved LLUIColor, LLTrans, and LLXUIParser to llui
reviewed by Nat
|
|
Inventory
* Modified build context menu code to not disable items that are invisible so
secondary background fetch can coalesce menu options with proper state.
* Removed "Move to Merchant Outbox" context menu option.
|
|
and LLBufferArray::copyIntoBuffers
|
|
|
|
|
|
|
|
panel is maximized in Inventory window
|
|
items to be copied to Outbox with context menu option
* Updated context menu default enabled state to use the last state rather than
TRUE. Once per frame, the states are all reset to TRUE so this has the effect
of AND'ing together successive buildContextMenu functions rather than ignoring
previous states.
|
|
close automatically
* Updated auto-open behavior to ignore items that are already open.
|
|
|
|
|
|
indicating a top level drop
* Updated the outbox drop area highlight to include top level drops within the
outbox inventory panel itself.
|
|
Despite LLProcessLauncher's list-of-argument-strings API, on Windows it must
ram them all into a single command-line string anyway. This means that if
arguments contain spaces (or anything else that would confuse Windows command-
line parsing), the target process won't receive the intended arguments.
Introduce double quotes for any arguments not already double-quoted by caller.
|
|
(always use GL_STREAM_DRAW as the usage hint when mapping is disabled as geometry will be uploaded again and again)
|
|
correctly.
|
|
|
|
|
|
|
|
https://bitbucket.org/VirLinden/viewer-development-shining-fixes
|
|
|
|
|
|
* Updated to latest text per Leo's comment in the JIRA.
|
|
from Received Items panel and taking back into inventory.
* Inventory folder creation dates are now only set once, rather than being
updated every time a new item is added.
|
|
by rendering from client memory instead of using face VBO).
|
|
|
|
drop ends
* Added handleHover function to clear highlight
|
|
window is detached from side panel
EXP-1578 FIX -- received items folder shows shadows of content when scrolling through lots of folders in same window
* Put in guard to prevent the inventory panel from being created multiple times
|
|
viewer
|
|
|
|
|
|
Apparently our TeamCity build machines are still not up to Python 2.6.
|
|
|
|
typedef LLProcessLauncher::ll_pid_t to be HANDLE on Windows, pid_t elsewhere.
Then we can define getProcessID() returning ll_pid_t on all platforms,
retaining getProcessHandle() for hypothetical existing consumers... of which
there are none in practice.
This lets us define isRunning(ll_pid_t) to encapsulate the platform-specific
logic to actually check on a running child process, turning non-static
isRunning() into a fairly trivial wrapper.
|
|
|
|
|
|
Instead of free python() and python_out() functions containing a local
temporary LLProcessLauncher instance, with a 'tweak' callback param to
"do stuff" to that inaccessible object, change to a PythonProcessLauncher
class that sets up a (public) LLProcessLauncher member, then allows you to
run() or run() and then readfile() the output. Now you can construct an
instance and tweak to your heart's content -- without funky callback syntax --
before running the script.
Move all such helpers from TUT fixture struct to namespace scope. While
fixture-struct methods can freely call one another, introducing a nested class
gets awkward: constructor must explicitly require and bind a fixture-struct
pointer or reference. Namespace scope solves this.
(Truthfully, I only put them in the fixture struct originally because I
thought it necessary for calling ensure() et al. But ensure() and friends are
free functions; need only qualify them with tut:: namespace.)
|