Jean-Marc Lasgouttes wrote:
[I am sorry if I reply to points that have been settled already...]
Bo wrote:
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.
For me, the bundling thing is something I only want in certain cases,
namely, when I'm working with someone else. In that case, for example, I
normally produce a "special" BibTeX database, since I actually want them
to be able to modify my standing database---and I don't want them
reading my sometimes caustic notes! But most of the time, I don't want
to work that way, so I'd work unbundled, being able to link from
different places to a single file. So, well, speaking from my own point
of view, I would use both formats.
Now, when you check out this directory from a repository, how do you
open it? You know, you can not really open a directory.
This is a problematic point right now, but only because of native
filedialogs shortcomings. If we were to avoid native filedialogs
altogether, I am confident that we could hook into qfiledialog and
make it work. It would readily work on osx.
Of course, a remaining problem will be with native file managers. This
probably mean that we will not be able to use only this form until we
are running on OS that implement ideas from after 1990 ;)
Therefore we can keep the idea but unpack the directory from a zip
archive transparently. The unpacked directory would be in the document
directory when it makes sense, and in some temp dir when we have to.
I think the unpacked version should be removed after quitting LyX,
when one is working on a zipped version. If there is a leftover after
a crash, we should treat it like we handle emergency files.
I'd remove it normally, but allow the user to over-ride this if she so
chooses. That means you don't have to choose between the next two once
and for all.
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.
- 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.
Generally, this all sounds good to me, though there are plenty of
questions of detail still to work out.
The `directory in a zip' idea is really very close to what Bo
implemented, with one exception, namely, the ability to "bundle" out of
tree files. But what that's really become now is the ability to keep
some kind of link to the out of tree file so that, in particular,
changes to that file can be propogated into LyX. As Jose suggested, we
could implement this via session files, and this is something it would
be very nice to have. WordPerfect used to work that way: If you included
a picture and then changed the original file on disk, it would change
the picture. But OOo does not seem to work that way, and it is a major
pain that it doesn't.
Now, if you're working in the plain directory mode, then of course you
can modify the file easily enough. But the worry Bo had was that you
might now have ten copies of the same image, you want to modify them
all, and there isn't any easy way to do that...unless we implement some
form of Jose's idea. But the more I think about Jose's idea, the more I
like it: The session file is exactly where we should store this
information, and, in the best of all worlds, we could even allow the
user to edit that information somehow. (Of course, there's always
editing the session file directly.)
Richard
