Age | Commit message (Collapse) | Author |
|
LLNotifications::ChannelMap went away when LLNotificationChannel became an
LLInstanceTracker subclass. Iterate the universe of channels using
LLNotificationChannel::beginInstances(), endInstances() instead.
More troubling is that LLNotificationChannel::getParentChannelName() went away
too. When LLNotificationChannel acquired a Params block and corresponding
constructor, it acquired the ability to listen on multiple upstream sources.
That meant that a single mParent string became inapplicable, and its access
method was removed. (Curiously, mParent was not itself removed, but it was
left unused.) Change mParent to mParents, a vector<string>, built by
connectToChannel(). Introduce getParents(), an accessor returning an
iterator_range over that vector.
Change LLNotificationsListener::listChannels() to collect a "parents" key in
the map returned for each channel, and -- for backwards compatibility --
capture the first entry in the "parents" array as "parent".
|
|
and its caller.
|
|
|
|
LLNotifications.
|
|
phase 2, removal of extraneous signaling in favor of llnotificationchannels
made notificationchannels work better with overrides and lifetime managed
by creator
|
|
variables
|
|
|
|
|
|
respond to or cancel an individual notification by UUID; or forward
notifications through a specified LLEventPump.
|
|
with an event API. In addition to the LLEventPump name on which to listen,
LLEventAPI accepts a documentation string for event API introspection.
Give every LLEventDispatcher::add() overload a new documentation string
parameter for event API introspection.
Convert every existing event API to new conventions, introducing suitable
documentation strings for the API and each of its operations.
|
|
- Added LLNotificationsInterface class.
- Removed LLLoginInstance use of LLNotifications EventAPI
|
|
|
|
|
|
according to https://wiki.lindenlab.com/wiki/Incremental_Viewer_Automation/Event_API
reviewed by palmer.
|