> >> This is the so-called reversibility of my proposal, which works > >> nicely with existing files. > > To be honest I am ambivalent about reversibility. I am not sure we > need two different formats for a LyX document (bundled and unbundled). > Openoffice, AFAIK uses some bundle mode by default. Word does too, > since the document format is actually a file system.
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. 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. > This is a problematic point right now, but only because of native > filedialogs shortcomings. If we were to avoid native filedialogs 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. > This would give two modes of operations: > > - 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. > - 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. Bo
