Zini wrote: Definition: A component is a view (including controls) that handles a certain aspect of the ESM/ESP data.
We should create a component base class or even a flat hierarchy of component base classes.
On the framework side we need at least the ability to:
- move components between container windows
- open top-level views (like ID-list, Cell-list and such)
Each component should be closable and clone-able (new view). Also we might consider the ability to lock components programatically for editing.
Here is an example how this last feature could be used: If we offload saving into a separate thread, we can do this lock-free, if we disable editing during the save. The user could still view the content of the plugin while the save is progressing and we would avoid the GUI locking up completely.
We may move the lock-flag to the model instead of the view, because if one view for a record is locked, all views for this record will be locked.
There are different types of components, that we might want to represent with a separate base class each.
I. Top-Level Record Lists
A few examples would be the ID list and the cell list.
Please note, that these components still might be used to change records other than their own, e.g. the Region component will change region records and cell records.
II. Non-List Top-Level
A component, that does not directly corresponds to a single record type. An example would be the 3D editing component.
III. Single Record, identified by a string ID.
Examples: A class, a weapon or a script.
In the TES-CS these are handled via dialogue windows. We should avoid making the same mistake and turn them into full-blown components instead.
IV. Single Record, identified by a numeric ID.
Basically the same as above. Example: Magic effect.
Involved development of the OpenMW construction set.
1 post • Page 1 of 1