summaryrefslogtreecommitdiff
path: root/indra/viewer_components
AgeCommit message (Collapse)Author
2012-11-14Automated merge with http://hg.secondlife.com/viewer-developmentNat Goodspeed
2012-11-06Automated merge with http://hg.secondlife.com/viewer-developmentNat Goodspeed
2012-10-10Introduce new LLDir::findSkinnedFilenames() method. Use as needed.Nat Goodspeed
In a number of different places, for different reasons, the viewer wants to load a UI-related file that might be overridden by a non-default skin; and within that skin, might further be overridden by a non-default language. Apparently, for each of those use cases, every individual developer approached it as an entirely new problem, solving it idiosyncratically for that one case. Not only is this a maintenance problem, but it rubs one's nose in the fact that most such solutions consider only a subset of the relevant skin directories. Richard and I evolved an API intended to address all such cases: a central LLDir method returning a list of relevant pathnames, from most general to most localized, filtered to present only existing files; plus a couple of convenience methods to specifically obtain the most general and most localized available file. There were several load-skinned-file methods (LLFloater::buildFromFile(), LLPanel::buildFromFile() and LLUICtrlFactory::createFromFile() -- apparently cloned-and-modified from each other) that contained funky bolted-on logic to output the loaded data to an optional passed LLXMLNodePtr param. The trouble is that passing that param forced each of these methods to subvert its normal search: specifically for that case, it needed to find the baseline XML file instead of the localized one. Richard agreed that for the intended usage (reformatting XML files) we should use XML schema instead, and that the hacky functionality should be removed. Remove it. Also remove LLUICtrlFactory::getLocalizedXMLNode(), only used for those three special cases. Some callers explicitly passed the optional LLXMLNodePtr param as NULL. Remove that. Remove LLFloaterUIPreview::displayFloater(save) param, which relied on the optional output LLXMLNodePtr param. Make onClickSaveFloater() and onClickSaveAll() emit popupAndPrintWarning() about discontinued functionality. Recast LLFloater::buildFromFile(), LLPanel::buildFromFile(), LLUICtrlFactory::createFromFile(), LLNotifications::loadTemplates(), LLUI::locateSkin(), LLFontRegistry::parseFontInfo(), LLUIColorTable::loadFromSettings(), LLUICtrlFactory::loadWidgetTemplate(), LLUICtrlFactory::getLayeredXMLNode(), LLUIImageList::initFromFile(), LLAppViewer::launchUpdater() and LLMediaCtrl::navigateToLocalPage() to use findSkinnedFilenames(). (Is LLAppViewer::launchUpdater() ever called any more? Apparently so -- though the linux-updater.bin logic to process the relevant command-line switch has been disabled. Shrug.) (Is LLMediaCtrl::navigateToLocalPage() ever used?? If so, why?) Remove LLUI::setupPaths(), getXUIPaths(), getSkinPath() and getLocalizedSkinPath(). Remove the skins/paths.xml file read by setupPaths(). The only configuration it contained was the pair of partial paths "xui/en" and "xui/[LANGUAGE]" -- hardly likely to change. getSkinPath() specifically returned the first of these, while getLocalizedSkinPath() specifically returned the second. This knowledge is now embedded in findSkinnedFilenames(). Also remove paths.xml from viewer_manifest.py. Remove injected xui_paths from LLFontGL::initClass() and LLFontRegistry::LLFontRegistry(). These are no longer needed since LLFontRegistry can now directly consult LLDir for its path search. Stop passing LLUI::getXUIPaths() to LLFontGL::initClass() in LLViewerWindow's constructor and initFonts() method. Add LLDir::append() and add() methods for the simple task of combining two path components separated by getDirDelimiter() -- but only if they're both non-empty. Amazing how often that logic is replicated. Replace some existing concatenations with add() or append(). New LLDir::findSkinnedFilenames() method must know current language. Allow injecting current language by adding an LLDir::setSkinFolder(language) param, and pass it where LLAppViewer::init() and initConfiguration() currently call setSkinFolder(). Also add LLDir::getSkinFolder() and getLanguage() methods. Change LLFLoaterUIPreview's LLLocalizationResetForcer helper to "forcibly reset language" using LLDir::setSkinFolder() instead of LLUI::setupPaths(). Update LLDir stubs in lldir_stub.cpp and llupdaterservice_test.cpp. Add LLDir::getUserDefaultSkinDir() to obtain often-overlooked possible skin directory -- like getUserSkinDir() but with "default" in place of the current skin name as the last path component. (However, we hope findSkinnedFilenames() obviates most explicit use of such individual skin directory pathnames.) Add LLDir unit tests for new findSkinnedFilenames() and add() methods -- the latter exercises append() as well. Tweak indra/integration_tests/llui_libtest/llui_libtest.cpp for all the above. Notably, comment out its export_test_floaters() function, since the essential LLFloater::buildFromFile(optional LLXMLNodePtr) functionality has been removed. This may mean that llui_libtest.cpp has little remaining value, not sure.
2012-10-03Fix non-thread-safe refcounting of LLHTTPClient::Responder and fix ↵Dave Parks
out-of-order deletion of LLTextureFetch on shutdown
2012-08-1510.5 macs will begin looking for mac_legacy rather than macAura Linden
2012-08-26Gracefully handle 'Started' status. Ignore it and continue login.Nicky
2012-05-09Automated merge with http://hg.secondlife.com/viewer-releaseNat Goodspeed
2012-05-09CHOP-900: Use new apr_procattr_constrain_handle_set() extension.Nat Goodspeed
Now LLProcess explicitly requests APR to limit the handles passed to any child process, instead of wantonly passing whatever happens to be lying around the parent process at the time. This requires the latest APR build. Also revert LLUpdateDownloader::Implementation::mDownloadStream to llofstream (as in rev 1878a57aebd7) instead of apr_file_t*. Using APR for that file was a Band-Aid -- a single whacked mole -- for the problem more systemically addressed by apr_procattr_constrain_handle_set().
2012-04-23IQA-463: Add apr_file_open(APR_CREATE) flag for downloaded installer.Nat Goodspeed
This handles the case when the target file doesn't exist, just as APR_TRUNCATE handles the case when it does. Strengthen error checks concerning downloaded installer file from ll_apr_warn_status() to ll_apr_assert_status(). Failing to recognize (e.g.) failure to open that file only leads to mysterious crashes down the road; this removes the mystery.
2012-04-23IQA-463: Use APR file I/O for downloaded viewer installer .exe.Nat Goodspeed
On Windows, calling CreateProcess(bInheritHandles=FALSE) is the wrong idea. In that case, CreateProcess() passes NO handles -- even the files you've explicitly designated as the child's stdin, stdout, stderr in the STARTUPINFO struct! Remove LLProcess code to tweak bInheritHandles; we should also remove the corresponding (useless) APR extension. Instead, given that the Windows file-locking problem we've observed is specific to the viewer installer .exe file downloaded by the background updater logic, use APR file I/O for that specific file. Empirically, both llofstream and std::ofstream seem to make the open file handle inheritable; but apr_file_open() documentation says: "By default, the returned file descriptor will not be inherited by child processes created by apr_proc_create()." And indeed, it does appear to sidestep the locking problem.
2012-02-12Automated merge with ssh://hg.lindenlab.com/nat/viewer-new-aprNat Goodspeed
2012-02-06Automated merge with http://hg.secondlife.com/viewer-developmentRichard Linden
2012-02-01converted a bunch of narrowing implicit conversions to explicitRichard Linden
2012-01-21Convert LLProcess consumers from LLSD to LLProcess::Params block.Nat Goodspeed
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.
2012-01-20Per Richard, replace LLProcessLauncher with LLProcess.Nat Goodspeed
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.
2012-01-17Add log message if LLProcessLauncher child fails to execv().Nat Goodspeed
On a Posix platform (vfork()/execv() implementation), if for any reason the execv() failed (e.g. executable not on PATH), the viewer would never know, nor the user: the vfork() child produced no output, and terminated with rc 0! Add logging, make child terminate with nonzero rc. Remove pointless addArgument(const char*) overload: this does nothing for you that the compiler won't do implicitly. In llupdateinstaller.cpp, remove pointless c_str() call in addArgument() arg: we were starting with a std::string, then extracting its c_str(), only to construct a whole new std::string from it!
2012-01-12fix for SH-2845, SH-2846, SH-2847, SH-2851: curl crashes and out-of-memory ↵Xiaohong Bao
crashes.
2011-11-15mergeDave Parks
2011-10-18mergeBrad Payne (Vir Linden)
2011-09-30SH-2515 WIP - changed app name in linux updater, dir name in windows installerBrad Payne (Vir Linden)
2011-09-30SH-2515 WIP - changed app name in mac-updaterBrad Payne (Vir Linden)
2011-08-31MergeXiaohong Bao
2011-08-17convert tabs to spaces where they are forbiddenOz Linden
2011-07-15Merge from viewer-developmentXiaohong Bao
2011-05-26EXP-772: If URIs returned by SRV fail, fall back on original URI.Nat Goodspeed
2011-05-16mergeDave Parks
2011-05-12mergeDave Parks
2011-05-11STORM-477 Restored the backed out changeset: b62b260aa04dSeth ProductEngine
2011-05-05Remove Pth library from viewer build.Nat Goodspeed
This library was only needed on the Mac, and only with the OS X 10.4 SDK. As of October 2010, we no longer build the viewer with that SDK. The 10.5 SDK we're currently using directly supports the functionality for which we originally brought in Pth.
2011-02-05Introduces a LLThreadLocalData class that can beAleric Inglewood
accessed through the static LLThread::tldata(). Currently this object contains two (public) thread-local objects: a LLAPRRootPool and a LLVolatileAPRPool. The first is the general memory pool used by this thread (and this thread alone), while the second is intended for short lived memory allocations (needed for APR). The advantages of not mixing those two is that the latter is used most frequently, and as a result of it's nature can be destroyed and reconstructed on a "regular" basis. This patch adds LLAPRPool (completely replacing the old one), which is a wrapper around apr_pool_t* and has complete thread-safity checking. Whenever an apr call requires memory for some resource, a memory pool in the form of an LLAPRPool object can be created with the same life-time as this resource; assuring clean up of the memory no sooner, but also not much later than the life-time of the resource that needs the memory. Many, many function calls and constructors had the pool parameter simply removed (it is no longer the concern of the developer, if you don't write code that actually does an libapr call then you are no longer bothered with memory pools at all). However, I kept the notion of short-lived and long-lived allocations alive (see my remark in the jira here: https://jira.secondlife.com/browse/STORM-864?focusedCommentId=235356&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-235356 which requires that the LLAPRFile API needs to allow the user to specify how long they think a file will stay open. By choosing 'short_lived' as default for the constructor that immediately opens a file, the number of instances where this needs to be specified is drastically reduced however (obviously, any automatic LLAPRFile is short lived). *** Addressed Boroondas remarks in https://codereview.secondlife.com/r/99/ regarding (doxygen) comments. This patch effectively only changes comments. Includes some 'merge' stuff that ended up in llvocache.cpp (while starting as a bug fix, now only resulting in a cleanup). *** Added comment 'The use of apr_pool_t is OK here'. Added this comment on every line where apr_pool_t is correctly being used. This should make it easier to spot (future) errors where someone started to use apr_pool_t; you can just grep all sources for 'apr_pool_t' and immediately see where it's being used while LLAPRPool should have been used. Note that merging this patch is very easy: If there are no other uses of apr_pool_t in the code (one grep) and it compiles, then it will work. *** Second Merge (needed to remove 'delete mCreationMutex' from LLImageDecodeThread::~LLImageDecodeThread). *** Added back #include <apr_pools.h>. Apparently that is needed on libapr version 1.2.8., the version used by Linden Lab, for calls to apr_queue_*. This is a bug in libapr (we also include <apr_queue.h>, that is fixed in (at least) 1.3.7. Note that 1.2.8 is VERY old. Even 1.3.x is old. *** License fixes (GPL -> LGPL). And typo in comments. Addresses merov's comments on the review board. *** Added Merov's compile fixes for windows.
2011-02-01Automated merge up from viewer-development into mesh-developmentLoren Shih
2011-02-01merge changes back from beta branchOz Linden
2011-01-24a less brain dead fix for CHOP-369Andrew A. de Laix
2011-01-24fix CHOP-369: catch case of synchronous download failure.Andrew A. de Laix
2011-01-21Automated merge up from viewer-developmentLoren Shih
2011-01-20merge changes from viewer-betaOz Linden
2011-01-14fix CHOP-366, on temporary errors (e.g. version manager returns other than ↵Andrew A. de Laix
200) show error dialog instructing the user to manually install the latest viewer.
2011-01-13STORM-477 : backout changeset 6f5cb303d3e2Merov Linden
2011-01-11STORM-477 FIXED Re-implemented LLDir::getNextFileInDir() as an iterator object.Seth ProductEngine
- Replaced all existing usages of LLDir::getNextFileInDir() with the new directory iterator object. - Removed platform specific LLDir::getNextFileInDir() implementation.
2011-01-10Automated merge up from viewer-developmentLoren Shih
2011-01-06STORM-826 (workaround): correct mixed and dos-style line endingsOz Linden
2010-12-29Automated merge up from viewer-developmentLoren Shih
2010-12-20fix windows build?Andrew A. de Laix
2010-12-17Better fix for CHOP-286 - reenabled bandwidth limits on linux now that we've ↵brad kittenbrink
fixed the freeze.
2010-12-17Temporary workaround for CHOP-286: bandwidth limits freeze the downloader ↵brad kittenbrink
thread on linux
2010-12-17Automated merge with https://bitbucket.org/mani_linden/viewer-developmentAndrew A. de Laix
2010-12-17ich bin stupid; this should actually fix the windows build.Andrew A. de Laix
2010-12-17don't rely on stream cast to bool behavior; use explicit fail call.Andrew A. de Laix
2010-12-17and don't break other builds.Andrew A. de Laix
2010-12-17fix windows build (suppress warning from lexical_cast)Andrew A. de Laix