Andre Poenitz wrote:
On Thu, Mar 27, 2008 at 09:33:20AM -0500, Bo Peng wrote:
In the case of InsetBibtex, I think maybe an approach more like the one
in InsetInclude might work, where there aren't any "local" EmbeddedFile
objects but only the ones in the Buffer-level EmbeddedFileList.
InsetBibtex could have a vector of EmbeddedFile* instead, where these
are returned by registerFile(). So far as I can now see, the
EmbeddedFile objects aren't actually doing anything in InsetBibtex but
are, again, acting more as intermediaries. Removing them from
InsetBibtex would mean a few changes elsewhere, too, but not many, and
it would restore the "purity" of the inset.
But you do need something to store the bibfiles, and I, by instinct,
dislike parsing params['blah'] again and again...
I have proposed in another email to save relative path in
EmbeddedFile, which will no longer derive from DocFileName, but will
return external or embedded FileName is needed. I think this would
solve the problems.
This sounds good to me.
I'm skeptical that this will solve the problems. The issue doesn't
really have anything to do with relative versus absolute paths. If I
choose "biblio" as my BibTeX file, that is NOT a pathname. It's not
relative and it's not absolute and it doesn't even have an extension,
and it must not be stored as anything other than "biblio". Moreover, I
think storing the InsetCommandParams in some format other than the one
used by the read and write routines is asking for trouble, because then
you have to keep them sync'd, and that was one of the things that was
causing the problems. (If we want to make some special allowance for
lists in the parameters, we can do that, but we should do it in
InsetCommandParams.) But that's not the only problem, because the
existing code broke kpsewhich support for reasons that are unrelated to
the use of EmbeddedFile (as well as for reasons related to it), which
made trunk unusable for me. Which is why I started messing with this in
the first place.
And there are more problems I'm just discovering. This:
void GuiBibtex::applyView()
{
docstring dbs;
docstring emb;
...
QString filename = databaseLW->item(i)->text();
dbs += qstring_to_ucs4(filename);
try {
EmbeddedFile file(fromqstr(changeExtension(filename, "bib")),
buf.filePath());
file.setEmbed(databaseLW->item(i)->checkState() == Qt::Checked);
// move file around if needed, an exception may be raised.
file.enable(buf.embedded(), &buf, true);
// if things are OK...,
if (file.embedded())
emb += from_utf8(file.inzipName());
} catch (ExceptionMessage const & message) {
Alert::error(message.title_, message.details_);
// failed to embed
}
}
is also wrong, because it's (again) treating "biblio" and "IEEEexample"
as if they are pathnames, which (again) they are not. So embedding
fails, because it's looking for buffer_path/IEEEexample.bib. Doing this
with a new EmbeddedFile object that stores relative pathnames helps not
a bit.
And surely this should not be done here. The parameters should be sent
to InsetBibtex, and then it should take care of this. Or, probably
better, it should actually be done in Buffer::updateBibfilesCache(),
since that should be called whenever the bibfiles change, and this check
will then always need doing. But then we still have a problem, because
we need to calculate the inzipName, and we need a path to do that. But
we don't have one. I guess we'll have to go get one.
My general concern about this is that the EmbeddedFiles stuff is just
all over the place.
rh
