Bo Peng wrote:
And let's remember that extraction is likely to happen a lot. As Bo said
before, the normal way of working will be to receive a file, extract it,
and then work unbundled, so that e.g. you can edit biblio.bib without
having to hunt down
/tmp/lyx_tmpdir81735JCJRk/lyx_tmpbuf2/LyX.Embed.Dir.Abs/home/user//bibtex/biblio.bib.
While I will not take my words back, I would like to point out that
usually, only the main author needs to edit auxillary files, and use
version control system to back up the text version of the lyx file.
When you send your embedded version to your mentor, co-authors,
reviewers, they only need to view it, or do minor editing, so they do
not have to unpack your file.
This is not how it is in my work. There are no "main authors" in the
collaborative work I do. If I'm writing a book with someone, we're going
to be exchanging stuff back and forth all the time, and we're both going
to be editing it freely. If it's not easy to do this, then the current
implementation is not one I can use. It's that simple. Actually, that's
not quite true. *I* could use it, because *I* know to make sure all our
shared files are in a subdirectory; and I'd know to unbundle before I
set to work, and then rebundle when I'm done. But then I'm essentially
implementing the transparent bundling idea with gray matter. I can do
that because I understand the ins and outs of how this works. But I'm
not your average user, and that's definitely a workaround, even if it is
one we could mention in the docs.
Let me be clear. I'm not trying to be harsh. I like the ideas behind
this feature very much, and I'd love to be able to use it. If we can
make it work in a natural way, then it will make LyX a VERY powerful
tool for collaborative writing. But if this feature catches on, as I'm
sure you hope it does, then everything that I've been saying is
something that will eventually be said over on the user list if it
doesn't first get fixed here. And they won't be as nice as I am. ;-)
As a matter of fact, it would be really
irritating, if someone gets your .lyx file, double click it, and find
that his desktop is all messed up with image files.
Good point. So we put them in a subdirectory. Maybe there's an issue
with class and style files---though I'm pretty sure we can even adjust
for that by setting an appropriate environment variable. We could just
do that by default for the embedded case. It won't hurt anything if
nothing relevant is in that directory.
I do not find any need to 'hunt down' /tmp/lyx.../bibio.bib, and even
if a user knows that this can be done, this should be seriously
discouraged. Do you go to windows temporary directory to edit a
graphic file, and do you expect word to automatically update from your
edited file?
I was imagining that my co-author wants to add a reference to our .bib
file. At present, the only way to do so without unbundling would be to
hunt around in the temporary directory. The problem isn't that it won't
work. It will. The problem is that Average LyXUser will not like having
to work that way.
If we provide an edit button, a user should use it. If we
donot, a user should learn to use extract and update from external
file.
So yes, we could provide an edit button for that. Maybe we should
anyway. We'd have to decide what programs to check for. It is not
obvious to me what programs those should be. JabRef, presumably. Emacs?
Kile? But of course that could be figured out. Still, why should I HAVE
to find the bibliography inset first just so I can open the .bib file?
(For that matter, why should I HAVE to open the LyX file to edit that
file?*) That might not be so bad, since the inset is usually at the end.
But what if I want to edit an image? Why should I HAVE to hunt around
for the inset first? It's much more natural to at least be able to open
a normal file in whatever way I would normally open it. And why should I
HAVE to use whatever program configure.py thinks I should use? (Yes, *I*
know I can change it.) Why should I be constrained to use any single
program? Maybe I want to edit this .png with the Gimp and that one on
the command line with ImageMagick. (Please don't tell me about how Word
works!) And what if I want to fiddle with ourpaper.sty? The answer to
all of this, of course, is: Extract. So we're back to extraction. But
then we have the same problems.
The idea that we should tell users, "You have to do it this way", and
then answer the question "Why?" with: "Because we couldn't figure out
how to make it better", that doesn't sit well with me. We should figure
out how to make it better.
> What should we do if extraction files? As Bo said in an earlier
> discussion, we should at the very least allow the user to extract the
> file somewhere else. But now the LyX file is broken. We should help out:
> We should automatically adjust the paths after extraction, so the newly
> unbundled LyX file will still work. But then when the user sends the
> file back to her co-author, he faces the same problem. Every time the
> file is exchanged, we end up moving files around and, what's worse, each
> such time the user will need to choose where to extract the file.
You are talking about the worst scenario
No, this is the normal scenario, at least on any system other than
Windows: Absolute paths to files in my user tree will not be writable on
(almost) any other system. And writing the file somewhere else breaks
the LyX file.
and this problem can not be
easily resolved because absolute files are named differently on
different systems. Note that your solution makes the problem much
worse by *forcing* the extraction, whereas the problem does not exist
when one of the players choose to work with the embedded version.
But I suggested a solution: Write it to a (conventionally named)
subdirectory of the document directory, and then update the relevant
inset. This works in either case. (As I've been trying to say, the case
are parallel.) I think we should implement something like it whatever
else we do. I wouldn't even bother asking the user what to do: If the
user wants to extract, we should extract, and we can tell the user what
we have done afterwards:
The following files could not be written to their previously stored
locations:
biblio.bib
picture.png
They have been written to /path/to/lyx/file/filename.lyx.bundle/. [[
OK ]]
Why doesn't that work?
Richard
====
*When the LyX file opens, we'd have to pop a dialog: "The file
biblio.bib has changed on disk since this file was last saved. Do you
want to use the file stored at the last save or the newer one?
[[Embedded File]] [[Newer File]]"
