Age | Commit message (Collapse) | Author |
|
|
|
Per Monty's code review, it's dubious practice to have a class in which
certain members are sometimes visible, other times not. If these were virtual
methods, or non-static data members, the error would be obvious -- but even
with static data members and non-virtual methods, it looks like an ODR
violation. Extract conditional methods as free functions, as in changeset
07cd70e75473.
|
|
|
|
UI item
|
|
Changeset 07cd70e75473 moved LLSD::outstandingCount() and allocationCount() to
free functions so we could turn their visibility on/off via LLSD_DEBUG_INFO.
But on some platforms, without proper LL_COMMON_API declarations visible when
we compile llsd.cpp, those free functions lack proper linkage directives.
Declare LLSD_DEBUG_INFO in llsd.cpp so that when the llcommon library is
built, the free functions get proper linkage -- independent of compilations of
LLSD consumers.
|
|
progress bar is present
Added code to start counting the fade in time on login when STATE_STARTED is set
|
|
|
|
|
|
|
|
|
|
leave events.
The mouse position is checked every frame in relation to the toast to catch the mouse leaving the toast "i" button when the toast is moved by the screen channel.
The fix is intended to avoid the toasts that don't fade in the following scenario:
1. Have User A Send 4 IM messages to User B: a, b, c, d
2. Have User B hover their mouse over the i on toast c (don't click on it just hover)
3. As the other toasts fade observe toast c moves up to the top and does not fade
|
|
Minimum window size setting no longer forces propagation to the OS before root view is initialized.
|
|
then it obscures chatted text.
I repositioned the chat, move and camera floaters. Chat toasts now start 80 up from the bottom left rather than 10.
|
|
|
|
|
|
|
|
|
|
https://bitbucket.org/VirLinden/viewer-development-shining-fixes
|
|
|
|
|
|
|
|
|
|
|
|
call dialog is open does not move the dialog as well)
Reason:
A floater can be docked only to a button which is in visible chain, the visibility of the button itself is not enough.
After the button was added to the empty toolbar: mButtonAddSignal is called and the floater tries to dock to the button, but the button's parent(mButtonPanel) is yet invisible at this moment (so the button is not in visible chain). mButtonPanel visibility updates in draw() depending on whether it contains some buttons or not.
Solution:
Updating mButtonPanel visibility right after the button was added, before mButtonAddSignal
|
|
- Don't let chiclet list left side to be out of chiclet_container
|
|
|
|
negative fade times.
Rewrote two blocks of code to eliminate early returns.
|
|
consistent with other FUI floaters.
|
|
https://bitbucket.org/VirLinden/viewer-development-shining-fixes
|
|
|
|
* Removed debug view post build step and moved initialization to first draw for proper setup.
|
|
|
|
|
|
|
|
Free functions can be unconditionally compiled into the .o file, but
conditionally hidden in the header file. Static class methods don't have that
flexibility: without a declaration in the header file, you can't compile a
function definition in the .cpp file. That makes it awkward to use the same
llcommon build for production and for unit tests.
Why make the function declarations conditional at all? These are debugging
functions. They break the abstraction, they peek under the covers. Production
code should not use them. Making them conditional on an #ifdef symbol in the
unit-test source file means the compiler would reject any use by production
code. Put differently, it allows us to assert with confidence that only unit
tests do use them.
Put new free functions in (lowercase) llsd namespace so as not to clutter
global namespace.
Tweak the one known consumer (llsd_new_tut.cpp) accordingly.
|
|
https://bitbucket.org/VirLinden/viewer-development-shining-fixes
|
|
and SH-2671: sometimes other avatar textures don't load
|
|
|
|
|
|
|
|
|
|
|
|
context menus
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|