- 1 Notification System
- 1.1 Notification Service
- 1.1.1 (1) SDK: LXu_NOTIFYSYSSERVICE define
- 1.1.2 (2) SDK: NotifySysService::ScriptQuery
- 1.1.3 (3) SDK: NotifySysService::Spawn
- 1.1.4 (4) SDK: NotifySysService::Count
- 1.1.5 (5) SDK: NotifySysService::ByIndex
- 1.1.6 (6) SDK: NotifySysService::NameByIndex
- 1.1.7 (7) SDK: NotifySysService::Lookup
- 1.1.8 (8) SDK: empty NotifySysService User Class
- 1.1.9 (9) PY: empty Service.NotifySys user class
- 1.2 Common Notifiers
- 1.2.1 (10) Common Flags
- 1.2.2 Selection
- 1.2.3 Mesh Edits
- 1.2.4 Item Changes
- 1.2.5 Graph Changes
- 1.2.6 Channel Changes
- 1.2.7 Action Changes
- 1.3 Notifier Interface
- 1.1 Notification Service
The notification system is a high-level mechanism for reusing common named event handlers. The system was mainly designed for the command system, allowing the attribute system to be notified by commands that values and other attributes need to be updated.
The notification service is used to manage different notifiers, such as adding new notifiers or walking the notifier list.
(1) SDK: LXu_NOTIFYSYSSERVICE define
#define LXu_NOTIFYSYSSERVICE "4A3B31B0-A8F8-430A-9611-9D30E51CBBBA"
Request ScriptQuery() method.
(2) SDK: NotifySysService::ScriptQuery
A new notifier can be instanced with this function. The plug-in class name and argument string are provided. If the notifier with these arguments already exists, that notifier is used instead.
(3) SDK: NotifySysService::Spawn
These functions can be used to walk the list of instanced notifiers. As usual, the client must release any objects returned by ByIndex(), NameByIndex() and Lookup().
(4) SDK: NotifySysService::Count
(5) SDK: NotifySysService::ByIndex
(6) SDK: NotifySysService::NameByIndex
Notifiers that have been instanced can be looked up with this function.
(7) SDK: NotifySysService::Lookup
(8) SDK: empty NotifySysService User Class
Empty notifysys service Python user class.
(9) PY: empty Service.NotifySys user class
There are some very common types of events for which notifiers can be created. These are listed here just for a central place to put them.
Most of the specifications support strings to indicate the command notify flags to be sent for the notifier.
(10) Common Flags
(11) SDK: LXsNOTIFIER_SELECT define
#define LXsNOTIFIER_SELECT "select.event"
A "select.event" notifier can be created to trigger on selection events. The format for the arguments is "<type> [mode+flags]". The type is the selection type name, like "vertex" or "item". The optional modes are:
|element||Trigger only for changes to element selection, not other selection-related events.|
|exist||Trigger only if the existence of a selection changes, i.e. when the first element is selected or the last one is dropped.|
|time||Trigger on time changes.|
The argument string "item +v" would send a VALUE change when item selection changes. This is the same as just "item", since VALUE is the default event type. The string "polygon exist+dl" would send DISABLE and LABEL flags depending on there being any polygon selection or not.
(12) SDK: LXsNOTIFIER_MESHES define
#define LXsNOTIFIER_MESHES "meshes.event"
A "meshes.event" notifier can be created to trigger on mesh edits. The format is "+<edit> [+flags]". The edit flags indicate the type of mesh edit:
(13) Mesh Edit Flags
+v Vertex +p Polygon +t Polygon Tags +o Vertex Position +h Hide/Show State +f Polygon Type +l List of Maps +u UV Map Value +m Morph Map Value +a Any Vertex Map Value
The argument string "+vp +vd" would trigger on vertex or polygons edits and would send VALUE and DISABLE notification. The string "+o" would trigger on component level transforms, sending the default VALUE event.
(14) SDK: LXsNOTIFIER_ITEM define
#define LXsNOTIFIER_ITEM "item.event"
A "item.event" notifier can be created to trigger on specific item changes. The argument format is "event<[itemType]> [+flags]". The event types are:
|add, remove||When items are added and removed.|
|package||When the packages on an item change.|
|name||When the name of the item changes.|
|tag||When any tags on an item change.|
|chanlist||When the list of user channels, including their type and other attributes, changes for an item.|
Here are some examples:
|"remove"||Sends a value event on any item being deleted.|
|"add[clip] +d"||Sends a disable event when any clip item is added.|
|"tag[group] +ld"||Sends a disable+label event when the tags change on group items.|
|"chanlist +t"||Sends a data-type event when the user channels change on any item.|
(15) SDK: LXsNOTIFIER_GRAPHS define
#define LXsNOTIFIER_GRAPHS "graphs.event"
A "graphs.event" notifier can be created to trigger on graph edits. The argument format is "<graph> [+flags]". The graph is the graph name.
The string "parent +d" would trigger on parenting changes and send a DISABLE event.
(16) SDK: LXsNOTIFIER_CHANNEL define
#define LXsNOTIFIER_CHANNEL "channel.event"
A "channel.event" notifier can be created to trigger on changes to a given channel. The argument format is "+flags channel [type]". The flags determine the type of notification, and the channel is the channel name. The optional type is the item type name.
The string "+v enable" would trip a value event on any "enable" channel change.
(17) SDK: LXsNOTIFIER_ACTION define
#define LXsNOTIFIER_ACTION "action.event"
An "action.event" notifier can be created to trigger on changes to action parenting. The argument format is "action [+flags]", the name of the action followed by event flags.
Individual notifiers support this interface. The notifier itself simply monitors one or more event ports and sends an ILxNotify object as the event data to the client. Some clients might except more interfaces on the object; for example, the attribute system expects notifiers for command states to include an ILxCommandNotify interface so it can know if the command's value, label or datatype needs refreshing.
The ILxNotify object is temporary, and must be released by the ILxNotifier after the event has been sent.
(18) SDK: LXu_NOTIFIER, etc. defines
Get the name of the notifier, which should always be the same as the plug-in's name own name.
(19) SDK: Notifier::Name
These set and get the argument strings. The argument string allows specific events to be filtered through the notifier. For example, a tool notifier might only recognize specific tools, with the tool name provided through the argument string.
(20) SDK: Notifier::SetArgs
(21) SDK: Notifier::Args
A client is added to a notifier through this method. The client object has to implement an interface compatible with this type of modifier.
(22) SDK: Notifier::AddClient
This removes a client from a notifier that has been previously added.
(23) SDK: Notifier::RemoveClient
(24) SDK: empty Notifier User Class
Empty Notifier Python user class.
(25) PY: empty Notifier user class