20,741
edits
Reset & re-init: Difference between revisions
Jump to navigation
Jump to search
m
→Future Changes (post 3.2): canvas PropertyBasedElement would managing RunLevels kept in SGSubsystemGroups, controlled via SGPropertyChangeListener
m (→Future Changes (post 3.2): canvas PropertyBasedElement would managing RunLevels kept in SGSubsystemGroups, controlled via SGPropertyChangeListener) |
|||
| Line 107: | Line 107: | ||
* getting rid of singletons could help simplify the init process | * getting rid of singletons could help simplify the init process | ||
* lots of problems result from the ambiguity of resets vs. re-init/repositioning, it would make sense to extend SGSubsystem accordingly and expose two virtual methods to handle reset and repositioning explicitly per object, and not separately | * lots of problems result from the ambiguity of resets vs. re-init/repositioning, it would make sense to extend SGSubsystem accordingly and expose two virtual methods to handle reset and repositioning explicitly per object, and not separately-we'd want to extend SGSubsystemGroup accordingly, to ensure it can delegate events to each member | ||
* making sure that all subsystems actually implement SGSubsystem would be helpful (e.g. NavDataCache) | * making sure that all subsystems actually implement SGSubsystem would be helpful (e.g. NavDataCache) | ||
* there are a few subsystems that are intended to remain PERSISTENT per session, e.g. terragear, time, lighting, events - those should probably be put into a dedicated SGSubsystemGroup that isn't subject to reset/re-init at all, e.g. outside the actual subsystem_mgr ? | * there are a few subsystems that are intended to remain PERSISTENT per session, e.g. terragear, time, lighting, events - those should probably be put into a dedicated SGSubsystemGroup that isn't subject to reset/re-init at all, e.g. outside the actual subsystem_mgr ? | ||
* we can emulate '''run-levels''' by grouping related SGSubsystems into SGSubsystemGroups which would greatly simplify things | * we can emulate '''run-levels''' by grouping related SGSubsystems into SGSubsystemGroups which would greatly simplify things Tom's Canvas code is already using the notion of a PropertyBasedElement which wraps SGSubsystemGroup and SGPropertyChangeListener. This means we could allocate/free groups of subsystems and treat them as run-levels e.g.: | ||
** CORE: logger, prop-interpolator, performance-mon | ** CORE: logger, prop-interpolator, performance-mon | ||
** AUDIO: sound, fgcom, voice | ** AUDIO: sound, fgcom, voice | ||