> 1. If /usr/share/lyx/doc/UserGuide.lyx were bundled and you wanted to > extract it, you would be stuck, because you can't write to > /usr/share/lyx/doc/.
We always extract to the writable temp directory. Unbundle a readonly file is disabled, because unbundling will change the file status. Using the current approach, a readonly file can be opened and compiled. > 2. Suppose I bundle /home/rgheck/graphics/pic.png. Then automatic > extraction on my co-author's machine will almost certainly fail. (What > happens if I send it to someone who has the sad misfortune to be on > Windows? Does it end up at c:\home\rgheck\graphics\pic.png?) But then > normal extraction will equally fail. First of all, if the embedded file is edited as it is, not extraction is needed, and the embedded files can be used. The import point here is that you *do not have to* extract. Then, if a user chooses to extract, extraction of an absolute file will be problematic. It may ends up in c:\home\rgheck\graphics\pic.png, or a user may be prompted to choose a different directory. > 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. 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. 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? 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 extraction problems are big problems, and they have to be solved. But > if they are solved, then the more intuitive way of working will also > work. In fact, the only way I can see to make extraction work smoothly > takes us 95% of the way to an implementation of "transparent (un)bundling". I disagree. See above. > 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 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. > There's a better way. The user probably doesn't really care terribly > much where we put the file. She just wants the LyX file to work. So we > can simply extract the file ourselves to a new location, silently adjust > the LyX file, and perhaps inform the user of what we've done. But where > should we put the new files? The only non-temporary directory we know is > writable is the working directory, though presumably we can create a new > subdirectory ourselves, if we want to do so. But this all but is > transparent unbundling. Note that .cls and .layout etc have to be under the same directory as the main document. Also, you are excluding ../paths. > If you think of this from that perspective, what we're doing is > requiring that all bundled files be either in the same directory as the > LyX file or in a subdirectory of it. That's a restriction, yes, and > people who want to exchange bundled files will have to live with it, Why so if the current implementation can bundle all files? > but, if we try to solve the extraction problem the way I mentioned > above, then you'll effectively be in this situation as soon as you start > exchanging files, since extraction will force the bundled files into > precisely these directories. And we can and should help out in the ways > suggested above: When the user hits Document>Save in Bundled Format, we > can check all the insets, and if one of them references a file that is > not where it should be, we pop a message and offer to copy it where it > needs to be---offering to change the name, if there's a conflict, > etc---at which point we also can adjust the filename as it appears in > the inset. If someone is working with a bundled file and she inserts a > graphic and asks to embed it, we should again offer to copy it. And have > a button that says, "Don't ask me this again", in which case just just > pop up a reminder: "pic.png copied to > /home/user/work/filename.lyx.bundled/pic.png". > > This seems quite painless to me and will be nearly transparent to the > user. And this would massively simplify the code. > > The other issue I remember being raised had to do with "clean up". I.e.: > what do we do with the bundled files when we close? My suggestion would > be: Nothing. Leave them, just as if the user had extracted. Of course, > we'll need to check them when we re-open and, if they're changed, then > we may need to pop a warning about that, too, and ask the user what to > do. But this issue, again, exists for extraction, too, and there's no > difference between the cases. I will not comment on this. > rh Cheers, Bo
