Richard Heck wrote:
Isn't EmbeddedFile all about representing an "Embedded file"? If there
are problems, they need to be fixed there. But I can't imagine a
solution
getting easier by requiring it to _additionally_ fit into a
map<string, string>.
As has been repeatedly said, "biblio", as returned by the bibliography
dialog, isn't a filename. It's just an identifier that TeX can use to
FIND the file it really wants. You can adapt EmbeddedFile so that it
holds this piece of data as "meta info", which is what Bo proposes to
do. But surely this is a hack. It has nothing to do with what an
EmbeddedFile represents.
So the EmbeddedFile machinery is NOT present in the inset because the
inset's parameters represent EmbeddedFiles. As I've just said, the
parameters are not filenames. Exercise: Look at the old code and
compare how Bo uses an EmbeddedFileList with how FileNameList used to
be used. AT MOST, the former ought just to replace the latter, it
seems to me. But it does a lot more.
Answering myself, what MIGHT be true here is that (in the current
implementation) the embed parameter represents an embedded file. IF that
is so, then the "natural" structure for the parameters would be a vector
of pairs of string identifiers (like "biblio") and the EmbeddedFile
objects to which they correspond---plus some other stuff for the other
parameters. Note again that this can't be a map: Order matters.
And it'd be great if instead of writing this:
bibfiles biblio,mybib,yourbib
embed ./really/long/pathname/biblio.bib,,./other/long/path/yourbib.bib
to the LyX file, we could write something like:
bibfile biblio[./really/long/pathname/biblio.bib]
bibfile mybib[]
bibfile yourbib[./other/long/path/yourbib.bib]
where the empty bit, in both cases, means: not embedded. (Think about
which makes sense from an XML perspective.) To do this, of course, we
would need either to extend InsetCommandParams so it understands this
kind of list (we use such lists elsewhere), or do the more radical
thing, strip ICP to the bare minimum, and subclass it.
FYI, Andre, if we go the inset-specific route, subclassing this way
seems sensible, as opposed to having a lot of helper methods. There are
SOME insets whose parameters would be almost trivial subclasses. In
fact, lots, if I'm not mistaken.
Richard
