> OK. I can see this then, and can adjust for it. That said, however, > speaking as a potential user of this feature, I find this very > counterintuitive. I select a bibliography file, choose "Embed" (let's > say the document is already in embedded status), and now the edits I > make the file have no effect. If my co-author sends me a file, I have to > uncheck Document>Save in Bundled Format (not very intuitive!) to extract > the files, and then remember to recheck it when I save.
I am aware of these problems, In the very first version of my embedding design, I have something called AUTO embedding mode. That is to say, an embedded file in this mode will automatically use an external version when it exists. That proposal was disliked by all other developers. The situation is not that bad when you get use to the unique (?) bundle/unbundle feature of lyx. Normally, you work unbundled and make use of external files as usual. Only when you need to send your file to others do you bundle the lyx file. Note that some people may prefer the word/ooffice way of embedding, i.e., working in bundled mode. As of updating from external file, I plan to add two LFUNs to our context menus, namely extract-embedded-file, update-embedded-file. It would then be easy to update from an external file when a file is embedded. > Check the attached. It's more or less an inverse of what you had before. > In place of updateParams(), we have updateBibFiles(). There are still > some rough edges, though. But this will work, I think, without > undermining the InsetCommand structures. Your patch is huge and many of them seem unnecessary. If you agree that params can not be separated from EmbeddedFileList, why cannot we start from my simple meta_ patch? Your Data structure makes the problem worse by adding yet another representation of the same data. Cheers, Bo