Fairly certain this adds the feature in which the user may click the online notification to open a chat with the user coming online.
Translators may want to look at the xml changes of this change to see what to update
Removes old LegacyMultiAttachmentSupport patch
Moves LLAvatarName-centric functions into LLAvatarName from elsewhere.
Adds boost::signals2::connections to name polling places.
Removes more old icky static callbacks
Merge from Alchemy, credit where due~
Update notifications.xml to have a bunch of the tags from upstream to ease diffing
Adds name list specific name settings, Removes boolean for having lists of speakers with legacy names in favor of having a more flexible setting for them
Have a look at the combo boxes on Adv. Chat->Chat UI to customize these new settings.
There is now a fourth option for name display: LegaCy Name (D is play Name)
Conflicts:
indra/newview/llfloateravatarpicker.cpp - Includes to v-d style, since plain alphabetical just won't cut it. Shyotl's changes for name system, here.
indra/newview/llpanelgroupinvite.cpp - Shyotl's changes for name system, here.
Also corrected new README to have less typos and be slightly more accurate.
Better viewed without space changes
Pretty much add support for sending LLAvatarName and std::string to become a name via the system...
Also a bit of a revert for llcallingcard.cpp in this regard, just allow it to use a callback along with the new support,
but still handle the actual name switching in LLAvatarNameCache.
Fixes a problem I was having with "[NAME] is Online" notifications appearing early on, only.
Only does that, dun believe me? Take a look, oh... it also corrects improper interpretations of the PhoenixNameSystem value: 1 is both, 2 is displays, 0 and anything else is Legacy.
Also replaces a bit of the display name support code with new system... by definition this shouldn't change the log file, only the title of the session..
because of my bad connection during week days, I can not confirm this working 100%,
but if it does end up changing the logs under certain unseen conditions, replace the new name check with gCacheName->getFullName(id, name) but this reallllly shouldn't happen!
This fixes the problem that existed with received headers:
The server sends some headers ("set-cookie") more than once
in the same reply, which cannot be stored in std::map.
The old code just ignored the additional cookies, while
curlthreading3 (since the introduction of AIHTTPHeaders)
caused an assertion.
AIHTTPReceivedHeaders is written around a std::multimap
and allows to retrieve multiple headers with the same key.
Also, it is case insensitive so that if a server sends
"Content-Type" it will still find it (the viewer looks for
"content-type").
This creates a separate events interface structure
for CurlResponderBuffer (AICurlResponderBufferEvents)
for dealing with received HTTP headers.
The headers are passed to the Responder, but only
if the class derived from Responder implements
completedHeaders (otherwise it makes little sense
to even decode the headers).
Basically this is a reimplementation of the functionality
of the old LLHTTPClientURLAdaptor class.
That's quite a piece of work. I have NO idea how Jess can downplay the
effort that went into this.
And it's still not complete, local chat is not affected, perhaps group
chat too.
