| Age | Commit message (Collapse) | Author |
|---|
|
Cause 2.5.2 on MacPorts and FBSD ports are safe, while 2.5.0 on
Debian/Ubuntu would cause a crash that we stick to LL's 2.5.0.
|
|
This reverts commit 0797257992ee7f88456d3083ebf214485b75c139.
|
|
Compiling would fail otherwise at least on Fedora 40 and Ubuntu 24.04
with their GCC 13 or newer.
|
|
source for viewer 7.1.7.8974243247
|
|
|
|
LF, and trim trailing whitespaces as needed
|
|
fallback fonts.
With the emojis support, a new font was added, which not only provides emojis
but also fancy colorful replacements for UTF-8 characters that used to be
supported by our fallback (monochrome) fonts: this causes discrepancies and
unwanted/undesired changes in scripted objects menus (e.g. an empty circle or
square may render as a black, full one, a heart may render red instead of white),
not to mention the larger font size used by the emoji characters...
This patch restores the aspect of such menus/dialogs/UI elements with UTF-8
characters that *are* supported by the usual fallback fonts (fonts which may
also vary from one viewer to another, and from one OS to another), so that
everything keeps working/rendering as it always did so far, while not impairing
the use of new colorful emojis.
This second proposal ensures that:
- "genuine" emojis (in the 0x1f000-0x1ffff range), will *always* be rendered
using the new emojis font (this solves, for example, the monochrome "yellow
faces" issue seen with some characters in my first proposal).
- Special UTF-8 characters (in the 0x2000-0x32FF range) which have been used by
scripters so far, will render as they used to, using the monochrome fallback
fonts (this repairs scripted dialogs menus).
- Remaining special characters, that do not have a corresponding glyph in the
monochrome font, but do have one in the emojis font, will use the latter font
to render.
It also got the nice side-effect of removing the dependency on the ICU4C library.
Note however that the recent commit:
https://github.com/secondlife/viewer/commit/326055ba82c22fedde186c6a56bafd4fe87e613a
will need to be reverted to allow this patch to actually fix scripted dialogs.
Also, some cleanup might be needed in skins/default/xui/*/emoji_characters.xml to
remove from it the special UTF-8 characters that will no longer be rendered with
fanciful colors, but instead with the monochrome font glyphs.
|
|
source for viewer 7.1.3.7878383867
|
|
The lllibs need to be built as static libs now, otherwise SLPlugin
would lose reference to gSavedSettings. The media plugins still need to
be built as dynamic libs however, so they can't rely on the condition in
LibraryInstall.cmake any more.
Since the Megapahit viewer, when built using GCC, is using the default
value for _GLIBCXX_USE_CXX11_ABI (which is 1 for the newer C++11 ABI as
opposed to 0 for the older C++03 ABI), the Dullahan dependency needs to
be built with the very same _GLIBCXX_USE_CXX11_ABI setting too, otherwise
apr_dso would fail at loading libmedia_plugin_cef.so because of the failure
to refer to the setOnConsoleMessageCallback function with strictly the same
(not differing between std::__cxx11::basic_string vs. std::basic_string)
parameter types.
The CEF build is Spotify's, so no live streaming support, while the
Dullahan package used by the viewer was built using Kokua's dullahan
fork. After rebuilding it with _GLIBCXX_USE_CXX11_ABI kept at default
by not overriding it in variables (from the build-variables repo), the
order of the target link libraries in CEFPlugin.cmake doesn't seem to
matter any more (it did before!).
Now EXTERNAL_TOS can be safely omitted from GNU/Linux added compile
definitions (but still used on FreeBSD).
|
|
so we follow its encapsulating directory naming.
Looks like we're still going to be using LL's 3p-openjpeg for a while
more.
|
|
because (at least) the vlc/plugins dirs are inside it in the same way
it's been inside llplugin. This is so the app can find system VLC
plugins. And for this, BUILD_SHARED_LIBS set on must work first on Linux
(has already been working on FreeBSD), since libmedia_plugin_libvlc is a
shared library (which now gets installed to system library dir too, on
both OSes).
|
|
This reverts commit 33691f2fa52e3b9c2146391413234472769b13ed.
|
|
source for viewer 7.1.1.7039128750
|
|
# Conflicts:
# indra/newview/fonts/DejaVu-license.txt
# indra/newview/fonts/DejaVuSans-Bold.ttf
# indra/newview/fonts/DejaVuSans-BoldOblique.ttf
# indra/newview/fonts/DejaVuSans-Oblique.ttf
# indra/newview/fonts/DejaVuSans.ttf
# indra/newview/fonts/DejaVuSansMono.ttf
|
|
Just untar Dullahan package manually in prebuilt libs dir.
|
|
|
|
|
|
# Conflicts:
# indra/llcommon/CMakeLists.txt
# indra/newview/llspatialpartition.cpp
# indra/newview/llviewergenericmessage.cpp
# indra/newview/llvoavatar.cpp
|
|
|
|
since we don't have any web browser there either.
|
|
This reverts commit 9d49edbc48d81f820870d43edb2c975beffa5485.
|
|
|
|
|
|
source for viewer 6.6.16.6566955269
|
|
|
|
|
|
# Conflicts:
# autobuild.xml
# indra/llcommon/tests/llleap_test.cpp
# indra/newview/viewer_manifest.py
|
|
Add python 3.12 to FindPython search path
|
|
Look for python 3.12 in the registry along with all the other versions.
|
|
|
|
Vulkan glTF doesn't seem to be used yet.
TINYGLTF_INCLUDE_DIR doesn't seem to be used yet either.
Tiny GLTF can be headers only, easy to install to system.
|
|
|
|
until we figure out what's causing crashes with vanilla OpenJPEG.
|
|
|
|
|
|
Elsewhere in CMake land, we reference PYTHONINTERP_FOUND and
PYTHON_EXECUTABLE, both of which are explicitly set by Python.cmake. We don't
seem to need the find_package(Python3 COMPONENTS Interpreter) call. Given that
we take some pains to be careful about which Windows Python interpreter we
find, this eliminates a wildcard.
|
|
|
|
Otherwise it would fail to link SLPlugin.
|
|
This forces the use of external browser for links too for now, as we
don't have a solution for the HTML media plugin yet.
|
|
For runtime, they're already part of the executable.
For development, we're not there yet.
So this reduces the overall package size for now.
|
|
until we've tried building another project, but based on this project's
liblinden. It's also because these headers would be in a separate -dev
Debian package.
|
|
Since we could use the dynamic versioning from the configuration phase
of CMake, the inclusion is put in BuildVersion.cmake.
Other CPACK variables are usually static so can be set when running
cmake.
CPack somehow doesn't pick up the DESTINATION values in ViewerInstall
(slplugin & libvlc too) from UnixInstall, so they're they're partially
hardcoded again there.
|
|
When cross-compiling, the host's /usr/local/include would be unsafely
included before. The problem with this was that it leaked other host
library headers unexpectedly, like Boost. The target compilation caught
some function from the host headers which of a newer version, and then
when trying to link to the target libraries, the function wasn't
available yet in the older version.
|
|
source for viewer 6.6.14.581101
|
|
# Conflicts:
# indra/llcommon/llsdserialize.cpp
# indra/llcommon/llsdserialize.h
# indra/llmath/llvolume.cpp
# indra/llrender/llgl.cpp
# indra/llxml/llcontrol.cpp
# indra/newview/llpanelnearbymedia.cpp
# indra/newview/llsceneview.cpp
# indra/newview/llselectmgr.cpp
# indra/newview/llstartup.cpp
# indra/newview/lltextureview.cpp
# indra/newview/llvovolume.cpp
# indra/newview/skins/default/xui/en/menu_viewer.xml
|
|
|
|
Only found out after using CMake 3.26 for Darwin.
It wasn't an error when using CMake 3.24.
|
|
Useful when cross compiling.
|
|
The alt mouse click to cam is broken for now on macOS,
but this is the path we've chosen.
|
|
This reverts commit d883a11567252d9a0baff653bb16c38817a7c21c.
|
