Community
Participate
Working Groups
ISVs need to be able to add new system types which are compatible with existing ones, and be able to automatically pick up subsystem implementations from 3rd parties that they don't know about initially. Corresponding wizards should be registered against the systemType to support the "primary subsystem", but other "service subsystems" which are generic should be possible to enable/disable later on in the wizard. This is part of the initiative to make RSE more service oriented (bug 150498). Additional states (and thus decorators) need to be considered by IHost objects and registered with systemTypes. More considerations need to be made for systemTypes that do not describe TCP/IP connections. * Allow contributors to disable SystemTypes (via capabilities and/or via enabler class * Allow more dynamic icon decorators (connected/disconnected/connecting/ disconnecting/error/others via decorator) DaveM: have an error decorator somewhere * Add "compatible" flag to extension point: e.g. special wizard for linux-over-HWDebug, but "compatible" with Linux * Register the wizard through the SystemType extension point, instead of separate extension point? * Extension point / API to add systemTypes dynamically? * New functionality needs to be compatible, OK with changing the syntax
Also need to consider menu action and state handling - bug 161195
A lot has been accomplished so far, only Capability support is missing now as per bug #172650. This will be added for RC1.
Much important work has been done for this as by TM 2.0RC1: * improved newConnectionWizard * full control over action contributions and state handling * Added dynamic systemTypeProvider extension point * Added systemType -> subsystem association * Made the systemType label translatable * Pass around an IRSESystemType everywhere instead of the name * Add Properties for system types Work is considered complete.
[target cleanup] 2.0 RC1 was the original target milestone for this bug