Avatar links are now underlined only on hover. Also they have the same color as other links.
- Underlining text and getting it back to normal are done in handleHover() and draw() of new LLOnHoverChangeableTextSegment
class derived from LLNormalTextSegment. This class has two pointers to styles- one for style which will be used for text
on hover, and another otherwise. This special type of text segment is used if link's boolean member mUnderlineOnHoverOnly
is true. So it is URL's flag depending on which textbase adds new text segment(like it currently happens with mDisabledLink).
- Changed avatar link color in colors.xml to emphasis (because it was white before and was inconsistent with other links).
Reviewed by Richard Nelson at https://codereview.productengine.com/secondlife/r/749/
--HG--
branch : product-engine
- Don't let object names that are URLs override links to display the
remote object inspector
- Don't hyperlink the object name in the remote object inspector
- Made the <nolink>...</nolink> regex more robust and made it support
non-URLs between the tags, so that we don't get random <nolink> tags
when trying to disable URLs in user-typed text.
- Improved the llurlentry unit test and added some more test cases.
- Hooked up another LLViewerMessage code path to objectim SLapps to
pass down the owner and slurl information.
- Made a few LLUrlEntryBase methods be const methods, because they are
- Fixed a bug in the remote object inspector where it would never show
the teleport URL.
We are running into a bunch of places where we don't want to allow
hyperlinking of URLs like secondlife.com in text boxes. I've therefore
added a new type of URL regex that disables URL hyperlinking. Simply
enclose the URL in a <nolink> tag, e.g.:
<nolink>secondlife.com</nolink>
If the user enters a string into the navigation bar that is not
recognized as an SL location, the behavior is now:
- handle any secondlife:// SLapps, or
- open any http: or https: URLs in the media browser, or
- otherwise, send the text to the search floater
Changes:
This task had been already implemented. llurlentyinventory and llurlregistry have been changed to correct parsing of offer url
--HG--
branch : product-engine
These are no longer generated in Viewer 2.0 (instead we use
notifications to send object IMs to the user), so there's no
need to look for them in every textbox. Users can get details
on any objects spamming them via the new remote object inspector.
SLurls to the LLUrlRegistry. These are now displayed with the more
human-readable label of "Show Map for XXXX" and sport a context menu
with various operations.
I also added "Show on Map" options to the context menus for other
location-based SLurls.
I also internationalized the text for "Teleport to" and the new "Show
Map for" strings.
parsing in text editors. Any time we are looking up segment start/end
ranges we should do this on a wide string.
Also added a convenience LLUrlRegistry::hasUrl() method to easily
determine if a string contains a valid SLURL.
Resolved conflicts in lltexteditor.cpp, llchatitemscontainerctrl.cpp, llchatmsgbox.cpp, llfloaterbuycurrency.cpp, llnearbychat.cpp, floater_buy_currency.xml, and ru/strings.xml
Merging revisions 134925-135157 of svn+ssh://svn.lindenlab.com/svn/linden/branches/gooey/gooey-4 into C:\source\viewer-2.0.0-3, respecting ancestry
I've now added an explicit LLUrlRegistry::findUrl() method
for LLWStrings. This deals with correcting the start/end
range for the url appropriately. Now the API can be used
without worrying about utf8/utf32 character offset issues.
Internal JIRAs: DEV-40127 DEV-39966.
This didn't work on Windows because wchar_t is 2 bytes on that
platform, not 4 bytes (whereas llwchar is 4 bytes everywhere).
Boost's regex methods need to work on wchar_t, but I believe
that using a UTF-16 string would still be prone to crashing on
Windows as UTF-16 is still a variable-length encoding. Besides,
trying to compile a UTF-16 solution generates weird link errors.
Instead, I'm going to fix this problem a different way. And
I'm starting by reverting the previous attempt. Thanks Win32.
work on an LLWString instead of a std::string, so that we don't have
to worry about character offsets for variable-length-encoded UTF-8
strings.
This was causing crashes whenever we would try to show a textbox with
a URL and foreign characters (> 1 byte chars). Damn, I suck!
Ansariel