> If you're agreed, I can change the patch this way. The only task is to > write the update() method, really---we could just take over the old > createBibFiles, but that seems like overkill---and for me to undo some > other bits, like registerEmbeddedFile(). OK? > > I knew we'd figure this out eventually.
I am still not convinced that, even after I can read and restore params correctly, the need to separate params and EmbeddedFileList. IMHO, having a single representation is easier to maintain. As far as I can tell, params are changed only during inset creation, copying, and modification, and they are already handled correctly now. (And params are updated after EmbeddedFileList changes.) The only problem is the restoration of original user input for latex output purposes, and my short patch fixes that easily. If I understand you correctly, you would like to update params in the traditional way, and output EmbeddedFileList when necessary. However, because file movement needs to happen *during* inset creation, copying and modification, you have to create an embedded file in those events, enable them to move files around, and disable embedding if file movement fails. If, in some case as you mentioned, some developer change params without checking EmbeddedFile, lyx may crash due to inconsistent embedded file. THAT IS TO SAY, you can NOT change params independently, so what is the point of separating them? In programming terms, you first need to determine if you want to use enable(...., true) in your getEmbeddedFileList function. The answer is obviously no (use enable(.... false)), because you do not want to update an embedded file from external file each time it is used. Then, if you use enable(...., false), you will have to make sure your params are CORRECT, meaning that if a file is embedded, the embedded file indeed exists. To ensure this correctness, you have to check params each time it is changed, and this is why I say params and embedded files can not be separated. I hope I have made myself clear. Cheers, Bo
