| Age | Commit message (Collapse) | Author |
|---|
|
Including a very important one which is so assets are fetched!
|
|
source for viewer 7.1.7.8974243247
|
|
Maintenance X
|
|
(cherry picked from commit dc0b3aed4782e4e4835fd6b9d59d1d70b78be4a7)
|
|
|
|
LF, and trim trailing whitespaces as needed
|
|
source for viewer 7.1.6.8745209917
|
|
|
|
source for viewer 7.1.5.8443591509
|
|
# Conflicts:
# indra/llimage/llimageworker.cpp
# indra/llimage/llimageworker.h
# indra/newview/llcontrolavatar.cpp
# indra/newview/llfloaterprofiletexture.cpp
# indra/newview/lloutfitslist.cpp
# indra/newview/lloutfitslist.h
# indra/newview/lltexturefetch.cpp
|
|
# Conflicts:
# autobuild.xml
# indra/llcommon/llsys.cpp
|
|
looks like file that was being parced got corrupted 'in progress'
|
|
source for viewer 7.1.4.8149792635
|
|
|
|
# Conflicts:
# indra/llui/lltransutil.cpp
# indra/newview/app_settings/settings.xml
# indra/newview/llfloaterenvironmentadjust.cpp
# indra/newview/llpaneleditwater.cpp
# indra/newview/llpanelface.cpp
# indra/newview/lltexturectrl.cpp
# indra/newview/lltexturectrl.h
|
|
# Conflicts:
# .github/workflows/build.yaml
|
|
Closing window correctly caused a significant amount of logout freezes
with no known reproes. Temporarily returning to old behavior were thread
was killes without closing window and will reenable in later maints to
hopefully get a scenario or at least more data of what is causing the
freeze.
|
|
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.
|
|
Under debug LL_ERRS will show a message as well, but release won't show
anything and will quit silently so show a notification when applicable.
|
|
# Conflicts:
# indra/llcommon/llstring.cpp
# indra/llcommon/llstring.h
|
|
source for viewer 7.1.3.7878383867
|
|
|
|
# Conflicts:
# indra/newview/llinventorygallery.cpp
|
|
|
|
|
|
Note that crash happened when setting LLProgressView::setMessage
|
|
|
|
|
|
|
|
|
|
|
|
# Conflicts:
# indra/newview/llchiclet.h
|
|
|
|
UIImgInvisibleUUID doesn't exist
Default normal for material is 'null'
|
|
1. After window closes viewer still takes some time to shut down, so
added splash screen to not confuse users (and to see if something gets
stuck)
2. Having two identical mWindowHandle caused confusion for me, so I
split them. It looks like there might have been issues with thread being
stuck because thread's handle wasn't cleaned up.
3. Made region clean mCacheMap immediately instead of spending time
making copies on shutdown
|
|
|
|
a preset...' option of the 'Preferences' floater
|
|
|
|
|
|
coroutines).
|
|
|
|
|
|
Under debug LL_ERRS will show a message as well, but release won't show
anything and will quit silently so show a notification when applicable.
|
|
Just maybe M3 implements cpufrequency, which should be more accurate
than the alternative (different results on my Intel Mac).
|
|
This solution was retrieved from
https://listman.redhat.com/archives/libvir-list/2022-February/228217.html
sysctl hw.cpufrequency would result as empty on Apple Silicon (at least) M1,
when run natively. Ironically (and that's why it's been working with viewers
relying on Rosetta 2), arch -x86_64 /bin/bash -c 'sysctl hw.cpufrequency'
run on an Apple Silicon would result in the correct number.
|
|
# Conflicts:
# doc/contributions.txt
# indra/newview/llpanelprofile.cpp
# indra/newview/llspatialpartition.cpp
|
|
|
|
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
|
|
# Conflicts:
# indra/newview/llspatialpartition.cpp
|
