Updating IDeviceFactory to resolve [FEATURE]-Refactor Plugin loading mechanism #1065.
This change should be backwards-compatible with existing plugins that use the EssentialsPluginDeviceFactory<T> class,
as the interfaces are implemented by the various base classes.
In addition, the correct assembly name is now printed when a type is loaded.
In some cases, multiple device info update events are triggering,
causing the queue to be flooded with multiple unneccessary messages containing the same info.
This clogs the queue and makes it harder for UIs to come online when Essentials restarts,
especially in systems with a lot of NVX devices.
The events are now debounced. If there are no new messages for 1 second, then the MC message
is sent out.
Introduced a new method `ApplyLayout` in the `IHasScreensWithLayouts` interface. This method enables the application of a specific layout to a screen using the provided screen ID and layout index. XML documentation has been added to clarify its purpose and parameters.
Added `LayoutType` and `Windows` properties to the `LayoutInfo` class. Introduced a new `WindowConfig` class with `Label` and `Input` properties to represent window configurations within a layout.
Introduces a new enumeration `PresenterTrackMode` that defines four tracking modes for the Cisco codec's Presenter Track feature: `Off`, `Follow`, `Background`, and `Persistent`. Each mode includes a summary comment for clarity.
Introduced new interfaces and classes for screen and layout management, including `IHasScreensWithLayouts`, `ScreenInfo`, and `LayoutInfo`. Enhanced `IPresenterTrack` and `ISpeakerTrack` interfaces with additional properties and methods for managing presenter and speaker tracking. Added `IHasCodecRoomPresets` interface for room preset management and updated `CodecRoomPreset` class with a new constructor.
Introduced two new interfaces, `IPresenterTrack` and `ISpeakerTrack`, in the `PepperDash.Essentials.Devices.Common.Codec.Cisco` namespace. These interfaces provide properties and methods for managing presenter and speaker tracking functionalities in Cisco codecs, including availability, status feedback, and control methods.
When MC is running on a processor with a control subnet and a user
attempts to access the UI via the control subnet, the return _config.local.json
needs to reflect the CS LAN IP address for the processor rather than the LAN IP Address.
In order to accomplish this, there will now be 2 config files written to disk on startup:
1. the original file, /user/programX/mcUserApp/_local-config/_config.local.json
2. A file with the correct CS IP Address /user/programX/mcUserApp/_local-config/_config.cs.json
When a user requests the _config.local.json, the processor will compare the remote IP address
with the CS LAN IP Address and determine if they're in the same subnet, the assumption being
that if the IP Addresses are in the same subnet, then the app or end user is on the CS LAN and needs the CS config.
If the addresses are in the same subnet, then the contents of the _config.cs.json will be returned.
