"Bo Peng" <[EMAIL PROTECTED]> writes: > IMHO, changing to a new file format is fine, but changing the way > users work is risky. Your solution disallow the use of out of tree > files, which is unacceptable to me because it disallow sharing files > across documents.
I just say that we can refer to external files, but not bundle them. I understand this is a major disagreement. > By putting all external files to a semi-transparent folder (not > transparent at all on some OS), you may also disallow editing > external files directly. This is even more troublesome. I do not sure it is really relevant. The extra '..' can be handled transparently IMO. But there are other difficulties, like "how do I take the child document of bundle A and copy it to bundle B". Of course, this should be done without unbundling first :) > This is where I disagree with your solution. Your whole idea is based > on some sort of file/directory transparency mechanism only macOS > supports well. It would be extremely difficult to make this > cross-platform. At least to me, opening a directory for edit is an > crazy idea. There have been many discussion about this in linux-kernel, and I remember that Linux Torvalds was favourable to it. I think reiser4 implements that. It is not an outlandish feature. >> - directory-in-a-zip: the most transparent for users. Whether we >> actually unpack everytime or unpack on-demand from the zip is an >> implementation detail. > > This is more or less my idea. Yes. >> - plain directory. LyX could be made to understand this from the >> command line and, depending on OS capabilities, we might be able to >> implement 'open with lyx' from the file dialogs (I am not sure of >> the answer here). This form of document would be the best adapted to >> users who know what they are doing and want to be able to tweak the >> file by hand. > > If you give users a directory, the first response would be opening > content.lyx under it. This may not be too bad as long as you have no > '..' directory in your .lyx file. As I have said, there are > conceptually two 'current' directory in this approach. The idea would be that the zip is the default format, from which it is possible to export to the directory format by an explicit action. And I do not really get the problem with the two current directories. The file browser dialog takes care of relative paths by itself (or at least it used to). JMarc
