summaryrefslogtreecommitdiff
path: root/indra/viewer_components
AgeCommit message (Collapse)Author
2013-05-07merge changes for DRTVWR-299Oz Linden
2013-04-19merge up to latest viewer-development for merge to 3.5.2Oz Linden
2013-04-19merge changes for DRTVWR-294Oz Linden
2013-04-16merge up to 3.5.2 developmentOz Linden
2013-03-29Update Mac and Windows breakpad builds to latestGraham Madarasz
2013-03-11Viewer-chui mergeprep
2013-02-21MAINT-2389: Tell CMake viewer_components/login depends on Boost.ContextNat Goodspeed
This addresses a Linux link failure due to the Linux linker making a single left-to-right pass through libraries.
2013-02-21MAINT-2389: Change viewer to Boost package without ucontext.h.Nat Goodspeed
In autobuild.xml, specify today's build of the Boost package that includes the Boost.Context library, and whose boost::dcoroutines library uses Boost.Context exclusively instead of its previous context-switching underpinnings (source of the ucontext.h dependency). Add BOOST_CONTEXT_LIBRARY to Boost.cmake and Copy3rdPartyLibs.cmake. Link it with the viewer and with the lllogin.cpp test executable. Track new Boost package convention that our (early, unofficial) Boost.Coroutine library is now accessed as boost/dcoroutine/etc.h and boost::dcoroutines::etc. Remove #include <boost/coroutine/coroutine.hpp> from llviewerprecompiledheaders.h and lllogin.cpp: old rule that Boost.Coroutine header must be #included before anything else that might use ucontext.h is gone now that we no longer depend on ucontext.h. In fact remove -D_XOPEN_SOURCE in 00-Common.cmake because that was inserted specifically to work around a known problem with the ucontext.h facilities.
2013-02-13Merge from viewer-betaprep
2013-01-30Pull merge from lindenlab/viewer-developementMerov Linden
2013-01-28Fix test failureMerov Linden
2013-01-24merging in viewer-beta.Nyx Linden
Most of the merge was clean, a couple conflicts. Brought over a couple patches manually for llpolymesh.
2013-01-11MAINT-1481: use 'mktemp -d' to generate tempdir.Nat Goodspeed
Responding to Lex's code-review comments.
2013-01-11MAINT-1481: Clean up update_install UI, including error output.Nat Goodspeed
Capture actual error output from mkdir and mv; display it to user. Introduce mysudo function used by sudo_mv function for graphical sudo command. Since update_install actually only displays a single status message, just use zenity --info instead of a zenity progress box: need not update its message. Borrow semantics for clear_message and status functions from xmenity script. Introduce errorbox function so we only have to make zenity/xmessage test once. Move cleanup, onexit to top so we can use for clear_message.
2013-01-11MAINT-1481: Remove xmenity script and viewer_manifest.py references.Nat Goodspeed
2013-01-10MAINT-1481: minor bug fix plus incomplete UI tweaks.Nat Goodspeed
Test for existence of target name using -e rather than -f. (-d would work too, but in this case we must respond to any name collision, whether file or directory.) Instead of terminating on failure, make sudo_mv return rc of the [sudo] mv command to its caller. If the attempt to move new install to actual viewer directory fails, restore previous viewer before failing. When redirecting the script's stderr to updater.log, first save existing stderr to another file descriptor, and restore it when we launch viewer. Otherwise updater.log ends up collecting the viewer's duplicate stderr log output! The construct 'exec ... | program' doesn't work. In fact it causes any other redirections on that command to fail too. Remove it -- real fix pending.
2013-01-09MAINT-1481: remove linux-updater; move logic to Linux update_installNat Goodspeed
Now that the viewer's own background updater logic is responsible for downloading a new installer, the only functionality we still use in linux-updater that couldn't be expressed more simply in bash is the UI. But since most Linux distros capable of running SL at all have zenity, and all will have xmessage, we can handle even the UI part. Add xmenity wrapper script so update_install doesn't have to care which is present, and make the bash script that used to launch linux-updater do the real work.
2012-12-11Merged from viewer-releaseAura Linden
2012-11-28SH-3563. Pull and merge from viewer-development. Modest code changes to fix ↵prep
alignment issue in llAppearance.
2012-11-12Ported slplugin and some other missing components for cocoa.Aura Linden
2013-03-27add platform and platform version to login request parameters for new ↵Oz Linden
version manager query
2013-03-26log any error code and text received as an llsd body in a failure responseOz Linden
2013-03-08merge changes for 3.5.0-beta2Oz Linden
2013-03-06more cosmetic logging improvementsOz Linden
2013-03-06merge changes for DRTVWR-278Oz Linden
2013-03-06cosmetic logging fixOz Linden
2013-03-05remove old hack for legacy mac updates (no system that needed that will run ↵Oz Linden
this version anyway)
2013-02-27finish changes to update handling, including notices of channel changesOz Linden
2013-02-25MAINT-2155, DRTVWR-278: Make Mac updater honor app bundle name in .dmg.Nat Goodspeed
If you run "/Applications/Second Life Beta Materials.app", and the version manager directs you to update to a .dmg containing a release candidate whose app bundle name is "Second Life Viewer.app", update_install.py used to copy the contents of "Second Life Viewer.app" into "/Applications/Second Life Beta Materials.app". Changed it so that if the application bundle name differs, we leave the running app bundle alone, installing instead to the app bundle name from the .dmg.
2013-02-22MAINT-2328: Mac updater should not clear (part of) viewer cache.Nat Goodspeed
Remove the offending code.
2013-02-21add use of v1.1 update request protocol, with fallback to v1.0Oz Linden
2013-02-12remove regeneration control where not needed in updater serviceOz Linden
2013-02-12correct dependencies for forcing version number recompilationsOz Linden
2013-02-07derive version number from indra/VIEWER_VERSION.txtOz Linden
2013-01-08MAINT-2155: Match window title of mac-updater.app's message windowNat Goodspeed
2013-01-08MAINT-2155: when permitting missing old logfile, check for ENOENTNat Goodspeed
instead of errno.EEXIST. Sigh.
2013-01-05MAINT-2155: replace embedded mac-updater.app with a Python script.Nat Goodspeed
Remove mac-updater subtree from viewer source, along with the update_install bash script that invoked it. Remove all mention of mac-updater in CMakeLists.txt files and in viewer_manifest.py. Change Mac update_install bash script references in viewer_manifest.py and in llupdaterservice.cpp (which invokes it) to new Python update_install.py. Add update_install.py, messageframe.py (which puts up some Tkinter UI) and janitor.py (cloned from vita, it's exactly what we need here).
2012-10-11Updating linux build to gcc4.6Don Kjer
2012-10-03Fix non-thread-safe refcounting of LLHTTPClient::Responder and fix ↵Dave Parks
out-of-order deletion of LLTextureFetch on shutdown
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-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