> In a way, but there's no EmbeddedFile object stored there at all. Just > the old parameter info. We build EmbeddedFile objects when necessary > mostly so they will tell us about the inzip path and, of course, so we > can use the copyTo() function. If there were a static > EmbeddedFile::getInzipName() function we could call, and if > EmbeddedFileList::registerFile could be called as: > registerFile(pathToFile, inzipName, embeddingStatus, enable); > then we would hardly need to construct them at all. I'll see about that.
Because these files are retrieved quite often, I tend not to create them on-the-fly each time. > This is actually similar to what you have in InsetInclude: I also dislike this part, for the same reason. I do not want to create EmbeddedFile each time. The problem is tolerable over there because there is only one included file. > Much the same idea, and I don't think there's such an issue about > recreating this object. It can't be that expensive. There is still the > problem about filename information being over-written in > updateEmbeddedFile(), though. I will address this problem. > By the way, InsetBibtex::setBuffer() never gets called in the existing > code. Inset::setBuffer() gets called instead. My patch fixes that, so > whatever happens, we need that part. Please commit that part. > > How about making EmbeddedFile a standard-alone class that does not > > derive from DocFileName? We simply save whatever path, relative or > > absolute a user provide, and get a real FileName when needed. Because > > two different absolute paths (external and embedded) are possible, > > this does make some sense. This would save us from all the relative > > path trouble. > > > > > You could do something like that, but I think it's worth disentangling > InsetBibtex from the EmbeddedFiles architecture as much as possible. > Most of my patch just restores the older way of doing things, modified > and cleaned up a bit. I dislike the old way. :-) > On a slightly different note, I've noticed that when e.g. > LFUN_INSET_MODIFY is called after you, say, change the embedding status > of a .bib file, nothing seems to happen vis a vis the Buffer-level > EmbeddedFileList. The same is true of addDatabase() and delDatabase(). > That has to be a bug, though maybe it doesn't matter, since everything > will get revalidated when it needs to be. (If so, though, maybe we don't > need to do it on load.) But if it should be done, then solution might be > to add something like: > embeddedFiles.validate(); > at the end of Buffer::updateBibfilesCache(); another and more general > solution might be to have a Buffer::validateEmbeddedFiles() routine we > can call from various places. I'm guessing there's a similar issue with > InsetInclude::setParams(): Presumably the Buffer needs to know about it > if the embedding status has changed. EmbeddedFiles was the center of the embedding feature, but not now. Every inset takes care of its own embedded files, and conflict etc are only handled when necessary. This will make the code much faster, and easier to maintain. EmbeddedFiles::validate() is called only after the .lyx file is opened because inzipname is not unique across OS. When a file is opened, embedded files need to be moved to the right places so that later operations such extraction and update would proceed correctly. I have tried to keep the old inzipname, but that was proved infeasible. Cheers, Bo
