| Age | Commit message (Collapse) | Author |
|---|
|
background for CONTENT_TYPE_HTML. (The color we pass to CEF has 4 compontents red, blue, green and alpha. We were only passing 3 and setting the color and not the alpha. At somepoint in CEF's history the default value must have changed. Passing 0xFF for alpha too - i.e. fully opaque - fixes this)
|
|
|
|
browser window
|
|
|
|
Whatever we were trying to do with LLSharedLibs.cmake hasn't worked on the Mac
for a long time, and trying to fix it only digs up more problems. Skip it:
we've already worked around it.
Update the media_plugins_example CMakeLists.txt to eliminate some CMake
non-existent dependency warnings.
|
|
away (different region even) sometimes plays at maximum volume when entering a region or moving camera slightly.' - until we can understand how to make real mac_volume_catcher work
|
|
even) sometimes plays at maximum volume when entering a region or moving camera slightly.
|
|
|
|
|
|
studio
|
|
useful during testing SLPlugin changes. Not shipped with release versions of viewer
|
|
working ' appears.
|
|
browser. (Surprisingly large amount of changes and new version of Dullahan to support this fix)
|
|
scheme handler was broken)
|
|
/INCREMENTAL due to '/LTCG' specification' in LibVLC, JPEGLIB etc.
|
|
|
|
is working
|
|
for native keyboard injection to match OSX version
|
|
|
|
|
|
|
|
|
|
changes in this batch since I'm working on Windows box but some speculative macOS ones too although they are quite untested
|
|
|
|
|
|
fails to start because of an as-yet undiagnosed issue with VLC plugin files related to their extyended attributes
|
|
and SDK 10.12
|
|
|
|
|
|
|
|
|
|
plugin using Windows system call. WinMMShim was only needed for XP systems and since we no longer support XP, it is not required.
|
|
The present CMake logic wants to pass FIXED:NO to the linker for 64-bit
builds, which on the face of it seems like a Good Thing: it permits code to be
relocated in memory, preventing collisions if two libraries happen to want to
load into overlapping address ranges.
However the way it's being specified is wrong and harmful. Passing /FIXED:NO
to the compiler command line engages /FI (Forced Include!) of a nonexistent
file XED:NO -- producing lots of baffling fatal compile errors.
Thanks Callum for diagnosing this!
|
|
Specifically, DriverCallback() was accepting several DWORD arguments that
should really be DWORD_PTR arguments. In a 32-bit compile, evidently that was
okay, but for 64 bits they're different sizes.
|
|
|
|
|
|
|
|
autobuild 1.1 now supports expanding $variables within a config file --
support that was explicitly added to address this very problem. So now the
windows platform in autobuild.xml uses $AUTOBUILD_ADDRSIZE,
$AUTOBUILD_WIN_VSPLATFORM and $AUTOBUILD_WIN_CMAKE_GEN, which should handle
most of the deltas between the windows platform and windows64.
This permits removing the windows64 platform definition from autobuild.xml.
The one remaining delta between the windows64 and windows platform definitions
was -DLL_64BIT_BUILD=TRUE. But we can handle that instead by checking
ADDRESS_SIZE. Change all existing references to WORD_SIZE to ADDRESS_SIZE
instead, and set ADDRESS_SIZE to $AUTOBUILD_ADDRSIZE. Change the one existing
LL_64BIT_BUILD reference to test (ADDRESS_SIZE EQUAL 64) instead.
|
|
|
|
small to read
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
but it broke things
|
|
that follow
|
|
additions (status, titles, looping)
|
|
viewer setting
|
