> > 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. > > > > > Because it loses data, I'd suppose. My co-author sends me a file with > changes to a graphic, but LyX uses the old version on my disk. The > current version has a similar problem: Extraction won't over-write a > file, so it too loses my co-author's changes. There at least needs to be > an option to over-write, and maybe we should check timestamps and > checksums. But I'm not sure I like that very much either.
The current implementation may not work well, but file checksum are compared during file extraction. A file will not be copied if two files are identical. Otherwise, users will be promoted for overwrite. > Speaking of which, the timestamps in the zip file seem to be wrong: > [EMAIL PROTECTED] tmp]$ unzip -l bundle.lyx > Archive: bundle.lyx > Length Date Time Name > -------- ---- ---- ---- > 1328 12-31-49 19:00 content.lyx > 63778 12-31-49 19:00 ./test/corsiar.png > -------- ------- > 65106 2 files > That is probably easily fixable. This may be a zipunzip.cpp problem. I copied the code from zlib/contrib/ and this sample code may not set time stamp. > > 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. > > > > > But it's not obvious that it's possible to work in bundled mode right > now. Editing a bundled graphic attempts to edit the file on disk, which > may not even exist. That can be fixed. But it's harder to see how to > work with embedded .bib files let alone arbitrary embedded files. Of > course, you can dig into the temporary directory, but that's not very > happy as a solution. Again, this should be a bug if external file is used for editing. Editing a bundled graphics should edit temppath()/inzipname. Why do you say 'digging into the temporary directory' is not good? You edit an bundled file which will be saved and used, right? > So I keep thinking that the solution to this is that whenever you open a > bundled file, it immediately unbundles itself and uses the unbundled > files, just like a normal LyX file would. In that case, bundling has > only to do with how the file is opened and saved and nothing to do with > how LyX works with it. Doesn't that seem like the simplest and most > intuitive way of operating? Do you mean you want to extract all bundled files to 'user' directory? But do you, and how do you clean up them after editing is done? > Now, you open a graphics inset, and it says > "images/file.png", but you try to edit that (without using LyX's edit > function) and nothing happens, or maybe the file isn't even there; on > the model I just mentioned, it is, and it's the right file, too. This must be a bug. EmbeddedFile::availableFile() should be editted, which in this case is the embedded version. > Note > how much this would simplify the implementation: No more copying to and > from the temporary directory; no more updating from external files; > InsetBibtex::latex() wouldn't have to know about bundled files, so > export works normally with no hassles; and the same goes for other insets. I have to admit I am tempted. :-) > Note that there is a sense in which this is equivalent to what you > suggested above: "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." My proposal just saves the user from having to > bundle and unbundle: LyX does it for you every time. I agreed, but your approach impose a particular way of working with embedded files, and my approach allows both. > Now I can see issues with this. Cross-platform issues, path issues, > issues about over-writing files, etc. But those all seem like technical > issues that we can solve, and they exist for unbundling whenever it is > done, so they have to be solved either way. If you are going to extract to user directories, the problem can be serious. It would be really strange to extract to somewhere outside of the document directory, not mentioning system path. Right now, these problems have been solved because we have control on filenames etc under the temp directory, where '../blah' is translated to 'updir/blah'. > > Anyway, I'm just throwing this out there. I certainly welcome such discussions, which was lacking during my development of this feature. The design of this feature has changed dramatically at least twice and most of the code has been rewritten several times. The current implementation is finally the way I think how this feature should be. Cheers, Bo
