summaryrefslogtreecommitdiff
path: root/indra/llui/lluictrlfactory.h
AgeCommit message (Collapse)Author
2020-07-23SL-13642 Get rid of that ugly ignore -Wdelete-incompleteAndrey Lihatskiy
Get rid of that ugly '#pragma clang diagnostic ignored "-Wdelete-incomplete"' by making sure the delete always happens inside llview.cpp, where the type of LLView is known.
2020-07-22There was an idiom to test with LL_DARWIN if the compiler used is clang. ↵Nicky Dasmijn
This is not correct, as clang is available on all 3 platforms. The correct way to check for this is via __clang__ (https://clang.llvm.org/docs/LanguageExtensions.html#builtin-macros)
2019-11-18SL-12305 More missing-file handlingandreykproductengine
instance().getCurFileName() was returning empty value despite supposedly non-empty filename
2016-10-13MAINT-5232: Use LLHeteroMap for LLUICtrlFactory::ParamDefaults objsNat Goodspeed
instead of making every ParamDefaults specialization an LLSingleton in its own right.
2016-09-15MAINT-5232: Normalize LLSingleton subclasses.Nat Goodspeed
A shocking number of LLSingleton subclasses had public constructors -- and in several instances, were being explicitly instantiated independently of the LLSingleton machinery. This breaks the new LLSingleton dependency-tracking machinery. It seems only fair that if you say you want an LLSingleton, there should only be ONE INSTANCE! Introduce LLSINGLETON() and LLSINGLETON_EMPTY_CTOR() macros. These handle the friend class LLSingleton<whatevah>; and explicitly declare a private nullary constructor. To try to enforce the LLSINGLETON() convention, introduce a new pure virtual LLSingleton method you_must_use_LLSINGLETON_macro() which is, as you might suspect, defined by the macro. If you declare an LLSingleton subclass without using LLSINGLETON() or LLSINGLETON_EMPTY_CTOR() in the class body, you can't instantiate the subclass for lack of a you_must_use_LLSINGLETON_macro() implementation -- which will hopefully remind the coder. Trawl through ALL LLSingleton subclass definitions, sprinkling in LLSINGLETON() or LLSINGLETON_EMPTY_CTOR() as appropriate. Remove all explicit constructor declarations, public or private, along with relevant 'friend class LLSingleton<myself>' declarations. Where destructors are declared, move them into private section as well. Where the constructor was inline but nontrivial, move out of class body. Fix several LLSingleton abuses revealed by making ctors/dtors private: LLGlobalEconomy was both an LLSingleton and the base class for LLRegionEconomy, a non-LLSingleton. (Therefore every LLRegionEconomy instance contained another instance of the LLGlobalEconomy "singleton.") Extract LLBaseEconomy; LLGlobalEconomy is now a trivial subclass of that. LLRegionEconomy, as you might suspect, now derives from LLBaseEconomy. LLToolGrab, an LLSingleton, was also explicitly instantiated by LLToolCompGun's constructor. Extract LLToolGrabBase, explicitly instantiated, with trivial subclass LLToolGrab, the LLSingleton instance. (WARNING: LLToolGrabBase methods have an unnerving tendency to go after LLToolGrab::getInstance(). I DO NOT KNOW what should be the relationship between the instance in LLToolCompGun and the LLToolGrab singleton instance.) LLGridManager declared a variant constructor accepting (const std::string&), with the comment: // initialize with an explicity grid file for testing. As there is no evidence of this being called from anywhere, delete it. LLChicletBar's constructor accepted an optional (const LLSD&). As the LLSD parameter wasn't used, and as there is no evidence of it being passed from anywhere, delete the parameter. LLViewerWindow::shutdownViews() was checking LLNavigationBar:: instanceExists(), then deleting its getInstance() pointer -- leaving a dangling LLSingleton instance pointer, a land mine if any subsequent code should attempt to reference it. Use deleteSingleton() instead. ~LLAppViewer() was calling LLViewerEventRecorder::instance() and then explicitly calling ~LLViewerEventRecorder() on that instance -- leaving the LLSingleton instance pointer pointing to an allocated-but-destroyed instance. Use deleteSingleton() instead.
2015-11-10remove execute permission from many files that should not have itOz Linden
2014-12-10Fix for incorrectly formatted #if statements (worked on clang FWIW!)callum_linden
2014-10-17Update to build on Xcode 6.0: Change tactic about turning off warnings about ↵callum_linden
-Wdelete-incomplete in anywhere lluictrlfactory.h is used - richard okay'd
2013-10-15renamed TimeBlock to BlockTimerStatHandleRichard Linden
2013-09-05changed fast timer over to using macroRichard Linden
another attempt to move mem stat into base class
2013-08-09second phase summer cleaningRichard Linden
replace llinfos, lldebugs, etc with new LL_INFOS(), LL_DEBUGS(), etc.
2013-06-05merge with viewer-releaseRichard Linden
2013-03-29Update Mac and Windows breakpad builds to latestGraham Madarasz
2012-11-20Pull and merge from ssh://hg@bitbucket.org/lindenlab/viewer-beta.William Todd Stinson
2012-11-19merge with viewer-developmentRichard Linden
2012-11-02SH-3499 Ensure asset stats output is correctRichard Linden
improvements to predicate API default rules encapsulated in LLInitParam removed empty flag from viewer asset stats
2012-11-01SH-3499 Ensure asset stats output is correctRichard Linden
added support for specifying predicates for xui and llsd serialization
2012-11-06Automated merge with http://hg.secondlife.com/viewer-developmentNat Goodspeed
2012-10-15Remove LLUICtrlFactory::findSkinnedFilename(): cf. LLDir method.Nat Goodspeed
Richard points out that LLUICtrlFactory::findSkinnedFilename() adds little value. It was called from exactly one place, and that one place could easily obtain the information another way. The concern is that it could confuse a reader of the code with regard to the other findSkinnedFilename[s]() methods in LLDir. Clarifying the code base is a Good Thing. Removing.
2012-10-12LLUICtrlFactory::getLayeredXMLNode() gets LLDir::ESkinConstraint.Nat Goodspeed
At this point, LLUICtrlFactory::getLayeredXMLNode() is a pretty thin wrapper around LLDir::findSkinnedFilenames() and LLXMLNode::getLayeredXMLNode(). Until now, LLUICtrlFactory::getLayeredXMLNode() passed (by default) LLDir::CURRENT_SKIN to LLDir::findSkinnedFilenames(). But that meant that a caller such as LLTransUtil::parseStrings() that wants almost the same functionality, but with LLDir::ALL_SKINS instead, had to clone the logic from LLUICtrlFactory::getLayeredXMLNode(). Allowing its caller to pass the desired LLDir::ESkinConstraint enum value eliminates the need to clone its logic. Remove cloned logic from LLTransUtil::parseStrings().
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-09Pull and merge from ssh://hg@bitbucket.org/lindenlab/viewer-development.Todd Stinson
2012-07-30CHUI-217 FIX Items are not visible in Merchant OutboxRichard Linden
cleaned up a lot custom code for folder view item creation in inbox and outbox proper initialization of views from inventory panel starting folder
2012-07-18MAINT-1175: Ditch LLTypeInfoLookup, make map<const type_info*> work.Nat Goodspeed
Instead of forbidding std::map<const std::type_info*, ...> outright (which includes LLRegistry<const std::type_info*, ...> and LLRegistrySingleton<const std::type_info*, ...>), try to make it work by specializing std::less<const std::type_info*> to use std::type_info::before(). Make LLRegistryDefaultComparator<T> use std::less<T> so it can capitalize on that specialization.
2012-07-18MAINT-1175: merge backout LLRegistrySingleton<std::type_info::name()>Nat Goodspeed
2012-07-18Backed out changeset a25bfa87418d (using std::type_info::name())Nat Goodspeed
The changeset above touched every consumer of the two LLRegistrySingletons originally defined with std::type_info* as keys. Those two LLRegistrySingletons were changed to use const char* as keys, then all consumers were changed to pass std::type_info::name() instead of the plain std::type_info* pointer -- to deal with the observed fact that on Linux, a given type might produce different std::type_info* pointers in different load modules. Since then, Richard turned up the fascinating fact that at least some implementations of gcc's std::type_info::before() method already accommodate this peculiarity. It seems worth backing out the (dismayingly pervasive) change to see if properly using std::type_info::before() as the map comparator will work just as well, with conceptually simpler source code. This backout is transitional: we don't expect things to build/run properly until we've cherry-picked certain other pertinent changes.
2012-07-11MAINT-1175: Properly pass LLRegistry's COMPARATOR to underlying map.Nat Goodspeed
Although LLRegistry and LLRegistrySingleton have always defined a COMPARATOR template parameter, it wasn't used for the underlying map. Therefore every type, including any pointer type, was being compared using std::less. This happens to work most of the time -- but is tripping us up now. Pass COMPARATOR to underlying std::map. Fix a couple minor bugs in LLRegistryDefaultComparator (never before used!). Specialize for const char*. Remove CompareTypeID and LLCompareTypeID because we now actively forbid using LLRegistry<std::type_info*, ...>; remove only known reference (LLWidgetNameRegistry definition).
2012-07-11MAINT-1175: Forbid LLRegistry[Singleton]<std::type_info*, ...>.Nat Goodspeed
Back out code that selects LLTypeInfoLookup for the underlying map implementation when KEY = [const] std::type_info*, because LLTypeInfoLookup's API is changing to become incompatible with std::map. Instead, fail with STATIC_ASSERT when LLRegistry's KEY is [const] std::type_info*. Fix all existing uses to use std::type_info::name() string instead.
2012-06-22CHUI-101 WIP Make LLFolderView general purposeRichard Linden
build fix for gcc added detection of duplicate widget registration
2011-09-30param block cleanupRichard Nelson
added Flag as value type moved Batch to BatchBlock renamed Choice to ChoiceBlock made merging of parameters for ValueParams consistent (fillFrom and overwriteFrom are inverses of each other now) made iteration over Multiple<T> type params easier initial schema param blocks
2011-09-23EXP-1207 : More on lltoolbarview. Still not renderingMerov Linden
2011-09-16added Flag as new param type...Richard Nelson
usage: <foo><bar/></foo> will set the bar flag on foo LLSD foo; foo["bar"]; will set the bar flag on foo converted notifications unique to use flag
2011-09-06EXP-1196 FIX Fix param block template orderingRichard Linden
changed ordering of template loading relative to constructor setting of params moved a lot of constructor-set params to template files reviewed by Leslie
2010-08-27Post-convert merge by convert_monolith.py from ./viewer-experienceMonroe Linden
2010-08-24mergeRichard Nelson
2010-08-23fix for gccRichard Nelson
2010-08-23made Params parsers not act as singletonsRichard Nelson
2010-08-20changed buildPanel/buildFloater to member functions buildFromFileRichard Nelson
streamlined LLUICtrlFactory's interface
2010-08-16mergeRichard Nelson
2010-08-16moved buildFloater out of lluictrlfactory to llfloater.cppRichard Nelson
2010-08-16fix for gccRichard Nelson
2010-08-16cleaned up LLUICtrlFactory...Richard Nelson
removed redundant functionality moved buildPanel to LLPanel
2010-08-13Change license from GPL to LGPL (version 2.1)Oz Linden
2010-07-27Backed out changeset: 58571b4e704bRichard Linden
2010-07-15Reverted changeset 2bb10eae42bfDessie Linden
2010-07-12Changing "typename const T" to "const typename T" makes gcc much happier. cool.Tofu Linden
2010-07-09EXT-8237 FIX Opening up Edit Outfit- Add More->Shirt causes FPS to drop from ↵Richard Linden
60fps to 18fps for a really long time EXT-8235 FIX HUGE long delay when reopening and/or closing edit outfit sidepanel if "Add More..." is active EXT-7695 FIX UI lockup after add wearable, right click av -> Change Outfit reviewed by Vir
2010-07-01eliminated a bunch of silent warnings on startup about multiple widget ↵Richard Linden
registration
2010-06-22EXT-7729 WIP LLWARNS: Tons of "Making dummy class..." warnings on startupRichard Linden
improved filename output for XUI parser errors
2009-12-18ext-3307 - nearby chat stays scrolled at bottomrichard