Age | Commit message (Collapse) | Author |
|
|
|
(STORM-717) to develop a more generic one (applicable to all notification toasts).
|
|
* Normally toasts are as opaque as specified by "inactive floater opacity" setting.
* When mouse is hovering a toast, the toast uses "active floater opacity" setting.
* Fading toasts have 1/2 of "inactive floater opacity".
|
|
before it fades. Please add fade time back to Chat preferences.
- Added two spinners to the Chat preferences tab that control NearbyToastLifeTime and NearbyToastFadingTime
- Added callbacks to the LLNearbyChatScreenChannel that update these properties if they were changed
Refactoring of LLToast:
- Removed code that was making toast transparent from LLToast::draw()
- Modified LLToast interface that relates to showing and hiding toast, so that all screen channels can use LLToast universally.
- Replaced in LLScreenChannel calling methods of old interface to new ones.
|
|
|
|
|
|
all floaters).
The crash was introduced by my previous fix of this ticket in changeset 8ceebd3612f0.
The problem was that, suprisingly, even invisible (faded) toasts were destroyed when you hit Ctrl_Shift+W,
however they were still referenced by the toast pool, so the references were invalidated.
The easiest fix would be to remove all references to the toast being destroyed, no matter is it visible or not.
However, then we'd have to search for each destroyed toast in the pool, which is slow.
Besides, removing toasts from the pool compromises the whole idea of pooling (which was introduced to speed up creation of new toasts).
Another possible fix is not to destroy any nearby chat toasts when user hits Ctrl+Shift+W.
That would save us from any crashes at a price of changing existing behaviour (the toasts will remain visible).
So I went for a third option: when closing all floaters, skip invisible ones.
Then there won't be attempts to destroy invisible (pooled) toasts, so the crash won't happen,
and we don't seem to change any existing behavior.
However I'm not 100% sure of the latter statement, so the fix requires extensive testing.
|
|
|
|
Bug reason: The fix of EXT-1419 disables showing nearby chat showing toasts at all whenever you close one.
That was done to prevent a crash when viewer is exiting, but closing a toast manually should be handled differently.
Fix: If a toast is being closed (destroyed) manually, just remove it from the toast pool
(to prevent further references to the invalid pointer), but keep on showing new toasts.
I've overriden LLFloater::onClose() to differentiate the two cases.
|
|
|
|
|
|
removed redundant functionality
moved buildPanel to LLPanel
|
|
|
|
|
|
|
|
objects.
reviewed by Mike Antipov at https://codereview.productengine.com/secondlife/r/570/
--HG--
branch : product-engine
|
|
message with enabled setting 'show script errors in separate window'.
reviewed by Vadim Savchuk at https://codereview.productengine.com/secondlife/r/541
--HG--
branch : product-engine
|
|
reviewed by Alexei Arabadji at https://codereview.productengine.com/secondlife/r/536/
--HG--
branch : product-engine
|
|
and EXT-6714 Normal Old chat toast is shown while chat log is open
reviwed https://codereview.productengine.com/secondlife/r/212/ manttipov
--HG--
branch : product-engine
|
|
used reverse order to provide correct z-order and avoid toast blinking caused
by z-reordering;
reviewed by Vadim at https://codereview.productengine.com/secondlife/r/57/
|
|
name changes
--HG--
branch : product-engine
|
|
Solution:
Nearby Chat toasts has been aligned with the chat input field
--HG--
branch : product-engine
|
|
host spot.
Close button is partially positioned out of toast(floater). Usually, hovering or clicking
that "outer" part of the button can not be handled. The workaround is to position the button
on the floater and make the floater background invisible. Now close button is properly handled,
but toast is transparent. To fix this i added wrapper_panel that looks and behaves like a floater.
--HG--
branch : product-engine
|
|
still shows in nearby chat toasts.)
--HG--
branch : product-engine
|
|
displays under prior toasts.
Implemented same fix for notification toasts.
--HG--
branch : product-engine
|
|
Plumbing to pass the owner ID for a chatting object down into the
LLChatHistory::appendMessage() method where we create the objectim
SLapp that will bring up the remote object inspector. Pheww.
For object notifications that are displayed as text chat, we
|
|
displayed as nearby chat toast when floater closed
--HG--
branch : product-engine
|
|
--HG--
branch : product-engine
|
|
text mode)
--HG--
branch : product-engine
|
|
removed overflow toast related functionality;
--HG--
branch : product-engine
|
|
|
|
--HG--
branch : product-engine
|
|
nearby chat toasts and log
revert name changes since this may break some functionality...
--HG--
branch : product-engine
|
|
nearby chat toasts and log
for information - since I think that messages from nowhere is bad practice for user - if object that send message has no name I use object id as name
--HG--
branch : product-engine
|
|
--HG--
branch : product-engine
|
|
|
|
|
|
|
|
ok toast for objects are back...
also add object inspector to nearby chat object context menu
--HG--
branch : product-engine
|
|
|
|
Reply in any IM toast"
--HG--
branch : product-engine
|
|
|
|
getWorldViewRect (scaled vs. raw)
Reduces chance of future UI bugs related to UI size.
Discussed with Richard.
|
|
--HG--
branch : product-engine
|
|
--HG--
branch : product-engine
|
|
--HG--
branch : product-engine
|
|
--HG--
branch : product-engine
|
|
|
|
https://svn.aws.productengine.com/secondlife/pe/stable-2 into P:\svn\viewer-2.0.0, respecting ancestry
* Bugs: EXT-1605 EXT-1506 EXT-1663 EXT-1616 EXT-1599 EXT-1587
* Dev: EXT-748 EXT-1447
* IM Cleanup
|
|
https://svn.aws.productengine.com/secondlife/export-from-ll/viewer-2-0@1967 https://svn.aws.productengine.com/secondlife/pe/stable-2@1971 -> viewer-2.0.0-3
* Bugs: EXT-1431 EXT-1237 EXT-1151 EXT-1165 EXT-1410 EXT-1419
* Dev: EXT-1232
|