> > I can see that figure.png is copied to [tmpdir]/filename.lyxdir/embed, > > to filename.embed/figure.png and so on during bundling and unbundling. > > You also need to change .lyx file several times, > > > > Only when bundling/unbundling actually. But you may note that, if > everything is already inside a self contained directory, the .lyx file will > _not_ change.
No. You extract [tmpdir]filenamedir.lyxdir/embed from the bundle to $DOC_DIR/filename.embed. (Or you had a typo?) > > and 'merge' them when > > you get it back. Other than your obsession to put them in a folder, > > what are the real benefits? I am not talking about out of tree files, > > just some figure.png in the same directory as filename.lyx. > > > > The benefit is that the users sees that this file is referenced in the .lyx > file. If the user wants to bundle manually, he can just do it easily. > Besides, this is also about 'standardization' and KISS. I don't think it is > a big drawback to force the image to go in this subdirectory. You might have a point about 'standardization' (who ask you to?) but I would disagree that your method is simpler. To the users 1. You are forcing users to use a specific directory structure because *you* think it is best for them. 2. When a users inserted /path/to/a, you (at least Richard) force users to update it in /path/to/blah/blah/a. 3. You creates another .lyx format during bundling but only allow partial conversion between them. 4. You disallow sharing of external files between different .lyx document, because they do not need to? 5. You (Richard actually) give users three choices to open a .lyx file, filename.lyz, filename.lyxdir (a directory?), filename.lyxdir/content.lyx with subtle differences between them. I mean, during the two week discussion, I was criticized for 1. keeping filename in .lyx file 2. bundle and unbundle in place but nodody told me why exactly this is bad except that I am not using a KISS directory structure. When I told them 1, 2, 3, 4, 5 why their proposal is not practical, suddenly all the arguments about backward compatibility, user experience change failed. The answers I got were 'I (or users) do not care about these' and 'we are not talking about implementation details', 'you should think of a way to solve it', or simply 'you are being annoying'. I will stop complaining. I will just say that I *do not* see any benefit of moving files around, and I do see a lot of user confusion and code complexity there. > > > 3-a) He only want to touch at the text contents. > > > > > > > This looks a lot like my bundle-editing mode, but how do you limit > > users to 'touch at the text contents'? > > We can disable the relevant LFUN if the file is globally set as "bundled". > There is exactly one boolean to take care of, similar to the read-only flag. OK. At least it might work. > > Also, this will not happen without touching inset related code, which > > will certainly displease Richard. > > I don't think so. The inset code does not need to be touched, only the LFUN > status needs to check for this boolean flag, that's all. No. The edit button will not work. Some latex output may be in danger because the external file does not exist. The file monitor code may break. If you study my code, a full bundle-editing implementation is actually easier than yours. > > Eventually things will converge. I just outlined a possible scenario, I am > of course not saying this is the only one way to go :-) Hopefully. I do not see any sign of it. Bo
