pvdk wrote:
I would love to start on the Editor, however, I'm not a real programmer. I suck at math and I don't know C++ too well. The backend will be a problem for me as I imagine it will use all kinds of C++ trickery I just don't know about.
I happen to have 8 free days starting from thursday, but I won't have access to a compiler then. I could do some reading on the stuff I should know for the backend, if you provide me with a list of things/paradigms/etc. I should know about.
I will also continue working out my GUI ideas.
Zini wrote:
I have added two more tasks (see 0.12.0 thread), that should serve as a preparation for
Load and Save. If we can find people to handle them, the backend part of this task should be just a question of iterating over all records and calling save (the load part can be taken with little modifications from components/esm_store/store). And the rest should be pure GUI.
Based on your posting, the task
Data Storage on the other hand sounds like it will turn into a problem. It is fundamental to the editor and we can't afford to divert any manpower from OpenMW for it. This is tricky business and I am not sure myself yet how to handle it.
Maybe it would be best, if you work around the backend for now, and do purely GUI tasks. But you won't get very far with it.
I could do some reading on the stuff I should know for the backend, if you provide me with a list of things/paradigms/etc. I should know about.
Can't help you with that, sorry. I haven't given much thought to how to implement the record storage. I suspect it will rely heavily on template usage, but that is just an educated guess.
pvdk wrote:
There's quite a lot of GUI related stuff I could start with. For instance, the tabbed interface we discussed and making windows detachable, figuring out how to have one or more main windows separate from the core application, etc.
For the data storage we could subclass QAbstractItemModel, but I wonder: each record its own model? Or a big model with all the records in it?
Zini wrote:
For instance, the tabbed interface we discussed
Did we ended up with a tabbed interface? I honestly don't remember, what the outcome was.
making windows detachable, figuring out how to have one or more main windows separate from the core application, etc.
I think you did already some experimenting with this? Some prototyping? So the actual task would be to write these functions in a way that they can be used when the backend is ready without the need for another rewrite.
For the data storage we could subclass QAbstractItemModel, but I wonder: each record its own model? Or a big model with all the records in it?
One model for each record type sounds reasonable. But from what I see QAbstractItemModel assumes a table like data structure. Therefore it can't be used for all record types.
We also need to consider those record types, that can be referenced (in MW-terminology). We decided that these should share a single view. Is that even possible with separate models? If not, we need to build another abstraction layer around these records.
Zini wrote:
Right. We agreed on a tabbed interface. Just found the thread.
Thinking about it a bit more, merging all the referencable record types into one model seems reasonable. We need to provide a proper abstraction anyway.
I guess we should start with categorizing record types:
* TES3
special case (there can only be one)
* GMST, GLOB, CLAS, FACT, RACE, SOUN, SCPT, REGN, BSGN, SPEL, ENCH
A model each, accessible via a string handle (note that all records with string handles share a single namespace)
* SKIL, MGEF
A model each, accessible via an integer handle.
* STAT, DOOR, MISC, WEAP, CONT, CREA, LIGH, NPC_, ARMO, CLOT, REPA, ACTI, APPA, LOCK, PROB, INGR, BOOK, ALCH, LEVI, LEVC,
A single model for all of them, accessible via a string handle
* CELL
Special case. Maybe we need to split them up into interior and exterior.
* DIAL, INFO
DIAL accessible via string handle (topic), but several sub-categories. Also
contains INFO records as sub-records (even though this is not represented in the structure of the ESM/P files).
I am unsure about these: LTEX, BODY, LAND, PGRD, SNDG