On Mon, Mar 31, 2008 at 3:54 PM, Richard Heck <[EMAIL PROTECTED]> wrote: > Bo Peng wrote:
You skipped that read-only problem your approach has. :-) > This is not how it is in my work. ... 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. You avoid the problems of absolute-path files by disallowing embedding of such files. I can easily do this as well, say, by such an option in Tools->preference. As a matter of fact, I was going to totally disable this when I realized the problems. The feature is now provided because Abdel provided some good methods to store them under temp path, and I was able to adjust inzipname to handle these cases. I think the embedding of such files are useful because one may need to embed shared system files such as /path/to/lyx/images, as our users guide etc do. The current approach also allows multiple files to embed the same copy of a file so that changing one file is enough to update a bunch of .lyx files. At least for me, I use the same bib file for all my papers, some of them share a customized .layout file. Even if these files can be problematic, we have many options to educate our users on this matter. We can, for example, optionally disable embedding of absolute-path files; raise an warning whenever such a file is embedded ; or raise an warning when a .lyx file is saved with such files are embedded. A warning such as "File blah blah is embedded in this file. They may not be extracted properly because this path may not exist under another operating system. It is advised that you copy this file to the document directory and embed". > 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. ;-) I think the benefits of embedding files with absolute-path is well worth the trouble, and we will not get many complains if we implement it properly. You see, users was not able to easily share files, and now they are, only with a few precautions. > > 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. That reduces, but no eliminates the problem. Just as the case of your solution to cleanup. > 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? Under windows, a default editor will be used. On other systems, users can set an editor. If these do not work, unbundle the whole file, or extract this single file, edit it, and update from external file should work. I am not saying this is simple, but this is the way things should be. Remember, you do not have many options to edit embedded objects in word or ooffice files, and many times you need to cut/paste the object to other applications and re-insert these objects. LyX is much nicer in this regard, and I do not see any reason for complaints. > 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. I could not understand your points. You insist on the latex way of working, and you are allowed to do so by working in unbundled mode, even all the time. However, other people may find the word/ooffice way more natural. They are not minorities, as I can imagine, because >90% of computer users are exposed to the word/ooffice way of embedding objects. Why should I discard the embedding mode just because you do not want to manually bundle/unbundle a file? > 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. Again, if your 'better' means not embedding those files, I can easily achieve the same. > > 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. Then we need to educate such users the problem, and solutions. > > 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? I have answered this, because embedding arbitrary files is useful, and the current situation does not rectify a complete rewrite of the feature. Bo
