Age | Commit message (Collapse) | Author |
|
# Conflicts:
# .github/workflows/build.yaml
# indra/newview/app_settings/shaders/class2/deferred/alphaF.glsl
# indra/newview/app_settings/shaders/class3/deferred/reflectionProbeF.glsl
# indra/newview/app_settings/shaders/class3/deferred/softenLightF.glsl
# indra/newview/llfilepicker.cpp
|
|
|
|
# Conflicts:
# autobuild.xml
# indra/cmake/ConfigurePkgConfig.cmake
# indra/cmake/ICU4C.cmake
# indra/media_plugins/gstreamer010/llmediaimplgstreamer_syms.cpp
# indra/media_plugins/gstreamer010/llmediaimplgstreamer_syms.h
# indra/media_plugins/gstreamer010/llmediaimplgstreamertriviallogging.h
# indra/media_plugins/gstreamer010/llmediaimplgstreamervidplug.cpp
# indra/media_plugins/gstreamer010/llmediaimplgstreamervidplug.h
# indra/media_plugins/gstreamer010/media_plugin_gstreamer010.cpp
# indra/newview/llappviewerlinux_api.h
# indra/newview/llappviewerlinux_api_dbus.cpp
# indra/newview/llappviewerlinux_api_dbus.h
# indra/newview/llfloateremojipicker.cpp
# indra/newview/lloutfitslist.cpp
|
|
Co-authored-by: AiraYumi <aira.youme@airanyumi.net>
|
|
|
|
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.
|
|
# 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
|
|
|
|
|
|
With VS 2022 on Windows GitHub Actions runners, we can't build apr_suite at
all with the upstream .sln / .vcxproj files, so we had to switch to
"experimental" CMake support. However there's no CMakeLists.txt file for
apr-iconv, so the Windows package omits that library.
|
|
The package doesn't include that any more.
|
|
|
|
gigantic CMake patch. Sadly, my macOS box updated to Xcode14.3 overnight and that caused many warnings/errors with variables being initialized and then used but not in a way that affected anything.. Building on Xcode 14.3 also requires that MACOSX_DEPLOYMENT_TARGET be set to > 10.13. Waiting on a decision about that but checking this in in the meantime. Builds on macOS with appropriate build variables set for MACOSX_DEPLOYMENT_TARGET = 10.14 but not really expecting this to build in TC because (REDACTED). Windows version probably hopelessly broken - switching to that now.
|
|
# Conflicts:
# indra/cmake/Copy3rdPartyLibs.cmake
# indra/cmake/FindOpenJPEG.cmake
# indra/cmake/OpenJPEG.cmake
# indra/integration_tests/llui_libtest/CMakeLists.txt
# indra/newview/CMakeLists.txt
|
|
|
|
# Conflicts:
# doc/contributions.txt
# indra/cmake/Copy3rdPartyLibs.cmake
# indra/cmake/FindOpenJPEG.cmake
# indra/cmake/OpenJPEG.cmake
# indra/integration_tests/llui_libtest/CMakeLists.txt
# indra/newview/CMakeLists.txt
|
|
the right place in Windows builds
|
|
|
|
This reverts commit 31917709d9f4d9d4742910ae7990009a1580b150.
|
|
|
|
enable partial bitstreams
Openjpeg was modified: "p_max_len -= l_nb_bytes_read;" was causing an overflow.
I'm not sure if I did something incorectly in opj_skip/opj_seek viewer side, but seems like openjpeg should have been checking remaining space in p_max_len either way.
P.S. Many thanks to Chafey and Neopallium for implementing openjpeg's partial bitstream support
|
|
|
|
Part of his change was omly taking Release builds into account, the other
part from me made the same mistake.
Use a generator expression with a custom command to get the symlink the way
we want.
|
|
DRTVWR-568_cmake
|
|
Converting on DRTVWR-568 as the project branch going forward.
|
|
|
|
into autobuild.xml for VS 2022 and update cmake script to copy the MSVC runtime (proper fix coming
|
|
Always search for python3[.exe] instead of plain 'python'. macOS Monterey no
longer bundles Python 2 at all.
Explicitly make PYTHON_EXECUTABLE a cached value so if the user edits it in
CMakeCache.txt, it won't be overwritten by indra/cmake/Python.cmake.
Do NOT set DYLD_LIBRARY_PATH for test executables! That has Bad Effects, as
discussed in https://stackoverflow.com/q/73418423/5533635. Instead, create
symlinks from build-mumble/sharedlibs/Resources -> Release/Resources and from
build-mumble/test/Resources -> ../sharedlibs/Release/Resources. For test
executables in sharedlibs/RelWithDebInfo and test/RelWithDebInfo, this
supports our dylibs' baked-in load path @executable_path/../Resources. That
load path assumes running in a standard app bundle (which the viewer in fact
does), but we've been avoiding creating an app bundle for every test program.
These symlinks allow us to continue doing that while avoiding
DYLD_LIBRARY_PATH.
Add indra/llcommon/apply.h. The LL::apply() function and its wrapper macro
VAPPLY were very useful in diagnosing the problem.
Tweak llleap_test.cpp. This source was modified extensively for diagnostic
purposes; these are the small improvements that remain.
|
|
allow us to reuse the macro for more than just conan.
|
|
DRTVWR-543-maint_cmake
|
|
|
|
|
|
configuration specific, rather than staging files to Release and
RelWithdebInfo all the time
|
|
on Linux again.
|
|
case insesitive fielsystem, this is why it was not issues there
- Remove input files that are obsolete.
|
|
- Targets now define the appropriate c++ defines, no more hand magic needed for llstartup.cpp
- Switch cmakeflage to USE_xxx rather than xxx as it was before. I personally find the USE_X notion more intuitive and it follows how KDU is used.
- To be backward compatible OPENAL/FMODSTUDIO flag will be mapped to USE_OPENAL/USE_FMODSTUDIO
|
|
what's with that, maybe it gets set by LLs teamcity builds?
|
|
(seems to be the case for Windows)
|
|
|
|
|
|
|
|
|
|
|
|
Moving a copy of OpenSSL 1.1.1 to D543 from D520 to have less conflicts with zlib-ng integration later
|
|
# Conflicts:
# autobuild.xml
# indra/CMakeLists.txt
# indra/newview/CMakeLists.txt
# indra/newview/llappviewerwin32.h
# indra/win_crash_logger/llcrashloggerwindows.cpp
Cherry picked from DRTVWR-520
|
|
# Conflicts:
# autobuild.xml
# build.sh
# indra/CMakeLists.txt
# indra/newview/CMakeLists.txt
# indra/newview/llappviewermacosx.cpp
# indra/newview/llappviewerwin32.h
# indra/newview/viewer_manifest.py
# indra/win_crash_logger/llcrashloggerwindows.cpp
|
|
|
|
Bring in Oz's tweaks to the way BugSplat is engaged and tested, plus a few
other miscellaneous goodies.
|
|
|
|
|