"Bo Peng" <[EMAIL PROTECTED]> writes: >> Let me repeat that I think that a bundled LyX file should be actually >> a directory with files inside, something like > > Whereas I dislike the 'should' word, I am happy that you are the first > one who provide your proposal in a reasonable detail.
Please consider that 'should' is preceded by 'I think' and that my command of the subtleties of english are not what it should. These things are just my opinion. >> file.lyxbundle/ >> Info.plist >> Contents/ >> file.lyx >> file.png > > Your proposed file structure may lead to inconvenience when unbundling > a file. For example, I have file.lyx, file.png in my paper directory, > which is controlled by svn. Now, the paper is sent back from my > co-author and I would like to overwrite my local files with the new > version (so that I can svn diff or svn ci). I will have to unbundle > the bundled .lyx file to another directory and copy them to this > directory. No, your local files are in the directory structure and you add this whole structure to the svn repository. > > The problem I describe is not a big one, you may say, but > by doing this, you need to have *all* files included in this bundle, > and you virtually *cannot* access out of tree files. Yes, and this is a feature in my view. You've got to try to install an application and compare it to the same operation on, say, windows. Having all of you files contained in some sandbox means much less hair pulling. > Sure, you say, I can add '../../image/blah.png' as long as I do not > bundle the file. But then your file can not be compiled on another > system. Again you say, this is what it should happen. Then, when you > try to make your document compile on your *own* machine, you have to > move files around so that the relative path is just right. I am not sure what are the kind of files that 1/ are not part of the document (really external files) but 2/ have to be modified when modifying the document. I tend to thinl that need can be taken care of with special tools. > I know I am being annoying here, but my implementation allows blah.lyx > to unbundle in place. That is to say, when I get by blah.lyx back and > put to its original place, I can unbundle it and I am done with > unbundling. Yes, but I think the is a dangerous feature. >> Bundling a file is only useful to move it around simply. > > This is your judgement. Yes, I can not really disagree with that :) What I mean is that the reason why bundling is thought as useful is that it allows to represent several files as one opaque entity that LyX can operate on. > My implementation also allows bundle-editing mode so that users can > work on a single .lyx document, without all the external file > messes. For example, not all users are happy to see K8F77X.png under > his document path when a figure is pasted to his .lyx document. Not > all users need or want to unbundle a lyx file if the lyx file can be > viewed, printed or edited directly. Bundling or unbundling files is not the business of users. This is done by LyX internally. > I agree that compression does not have to come with the bundling, but > there is no solution to separate them now. Sure. As I said later we shall use them together now, but we should not mix the two issues in our mind. >> Let's assume that a LyX file can be either a plain text file or a >> directory with a special structure. What does this buy us? > > There are devils in the details. How would you like to extract your > bundled .lyx file to a directory? I am happy that you also need to > address Richard's question of .lyx/blah/executable that may be excuted > by lyx. (I can not really remember the details). I am not sure at this point that I want to unbundle my file. What if all LyX files were directories with some text file inside them? The text files are still there for people who like to use their text editor, but they do not need to be exposed. >> * when opening a lyx file, it is unpacked in its own directory, where >> the user can find, examine and modify it. > > Please address the readonly directory problem , and the clean up problem here. The directory could be in a temp dir, I do no think there is a big problem with that. I am not sure what the cleanup problem is. >> * under mac/os x (and GNUstep FWIW), due to the magical Info.plist >> file and the Contents/ subdirectory, it will be recognized as a >> bundle and treated almost like a real file. This is great (trust me, >> it just works). > > What it the benefit here? You should use a mac and see by yourself. It feels like The Right Thing :) >> * if I add this directory to my a svn tree, each file in the directory >> tree is handled separately by svn and has proper version control. > > You are adding some extra files and directories to your svn tree, and > you are forcing users to use the same structure if they would like to > use the embedding feature. Even if users are convinced to do this for > their new documents, it would be a big problem for exsiting > documents. The big idea is that this directory should be seen as a special file that contains other files (like resource files, but using the file system structure). And anyway there is not alternate proposal that I saw to put files in svn in a meaningful way. JMarc
