Editor: inconsitencies using a mod in two different views
If I open/load the same mod in two views (start OpenMW-CS twice and load the same mod) - editing something in one view does not synchronise changed data in the other. This means that there could be problems because of deleted entities or altered data in the other view which would result eventually into a corrupted omwaddon file. I find it useful to have a mod open in two windows. I have two monitors so I can place one editor to the left monitor - I use that to look/copy up data - and place the other on the other monitor, using that for editing data.
A solution to the inconsistency pictured above could be to allow adding/changing/deleting records (called r/w-access onwards) only to the OpenCS instance that loaded the mod first and set all succeeding to r/o. Closing the "write-able view" should give the r/w state to the one that was opened after that. As well the new r/w-able view needs to reload data from the mod when it gets the r/w status.
That could be achieved by having a temporary file e.g. /<users_home>/.config/openmw/openmw.cs.instances. A groups of process IDs would belong to an opened mod (section). Each time an Editor is started it would append it's process ID to that section in the list. The first instance in a section would always have r/w status. When an instance exits it removes its entry from the list and then - if it was the first on the list - does instruct the next instance to refresh the data (reload) and that it has r/w access now. For "security" reason the list should be checked if PIDs (still) belong to an OpenMW-CS instance ('pgrep openmw-cs'), just in case - that a process ID of a crashed instance in the list is used by another process now (kdevelop, libreoffice, firefox…). Non-Open-CS PIDs would be removed. If a mod is the only process in a mod-section (so no other OpenMW-CS processes have that mod open) it should (after checking) discard the other entries in that section. The very first started OpenMW process (no mod is loaded in another process) could as well check if the list contains sections that are "abandoned" and remove those, so the list would be clean sooner or later.
It might be good to have an option to make all remaining instances in the PID-list automatically reload data in the background when the write-able instance exits. This would guarantee that all instances are up to date. Whatsoever, some people may want to have the old data for comparison in one and the new data in the other view, that's why having this as option would be nice. Having the possibility to manually refresh data in an OpenMW-CS process there could be provided by having an entry in the menu, like “menu” > “view” > “refresh data” or “menu” > “file” > “reload”.
(RM-2614 from redmine: created on 2015-06-04 by Who Knows, , closed on 2015-06-06 by nobody)