> 1/ file included by any mean (InsetInclude, InsetGraphics, > InsetExternal, InsetListings) are equivalent and should be treated the > same
Good. > 2/ I do not care if there is a reference to an absolute path that is > not bundled with the LyX file. This would be too restrictive and has > always been like that in the past. Good. > 3/ when a file is bundled, it is _in_ the bundle. Thus I believe it is > not wise/necessary to remember in the .lyx file where the file was > (especially if it is outside of the bundle). However, we can record > this information in the session file of the file producer to ease > reversibility. I will show you. > > 4. On another machine, unbundle and bundle should NOT change file content. > > Which of these points would not work if the file location is recorded > in your session file instead of the file? Why do you feel that you > _have_ to create files with ugly names on the users' HD in order to > achieve your aim? Do you really think it would be nice of me to create > a file in a path like > LyX.Embed.Abs/afs/inria.fr/rocq/home/imara/lasgoutt/src/lyx/foo.jpg > (yes, it is like that over here), so that, if you want to modify the file, > you've got to open 9 consecutive folders? Point 4. Allow me to explain: 1. You 9 consecutive folders is not a good argument because even on a system with that file, you need to open 8 folders. 2. The $DOC_PATH/LyX.Embed.Abs directory is created only when needed. 2.1 On a system where the out of tree file is available and identical to the embedded version, this file is not extracted. This is the key feature to share out of tree files between different lyx files. 2.2 If the out of tree file is there but is different, the user has the option to 'update from external file', and then unbundle if he wants to use the updated version. 2.3 If the user would like to use the embedded version, he has to unbundle to LyX.Embed.Abs, and update the system file manually if he wants to. For security reasons, lyx will not write outside of the document directory. 3. Point 2 also apply to relative paths such as ../../images/image.png which is more common. 4. Using the session approach, LyX.Embed.Abs has to be used for all such files on another machine, even if the external files exist. That is to say, the 'share the same file across different lyx documents' link will be broken on that machine. Now, the major difference between us is that you assume the author only work on one machine (where the session file is available), but I, for example, work on several machines with full svn tree checked out. Paths like ../../blah are frequently used so the session solution is not a good one for me. More importantly, there is no reason *not* to put the path information in .lyx file and the session implementation is likely to be complicated. > > 5. Users do not have to unbundle a file to view and print a .lyx document. > > 6. Users can work in bundled mode with word/ooffice style of embedding. > > Why do these other users have to unbundle if it is not necessary to > edit? That is exactly the point. It is unnecessary to unbundle, up to a point where working in unbundled mode is easier. For example, when you routinely update a figure and you do not want to use 'update from external file' from within lyx. Or when you would like to edit a .bib file where lyx does not provide an edit button. On the other hand, for viewing, minor editing, pasting figures from clipboard etc, bundled mode is easier to handle. My implementation gives users two choices. > > Note that it is tricky to have 4 because an out of tree file has to be > > unbundled to the document directory for security reasons. My proposal > > is to unbunble such a file as $DOC_DIR/LyX.Embed.Abs/blah, and when > > such a file is saved in bundled mode, it is translated back to blah. > > If it is supposed to be in session file, then it can be unbundled at > any place and when sending it back to you everything will be correct. I have exaplained this. > Part of the problem is also IMHO that you want to be able to work both > with the bundled/zipped file and with unbundled version, but assume > that it is OK when unbundling to forget any metainfo that was related > to the bundle. No. It is not OK to forget any metainfo... that is why I need the original path information. > I think having these two modes of operation is too > complicated (also in terms of UI for the user). We can release the bundle-editing mode as an experiemental feature and can always disable it if nobody likes it. There is no format change here. Also, there can be an 'auto-unbundling' RC option to always unbundle. Bo
