On Mon, 13 Apr 2009, Richard Heck wrote:
Yes, that's a major drawback ! But the .zlyx could be used as an
"export" file format to share with others, then one could just merge
back the .lyx embedded into the .zlyx : I see this as a way one can
use this feature, but some may want to use it otherwise (as everyone
does when using OOo for example, reinsert the figure)
This is where things get messy. If you just want an export format, then that
actually exists already, kind of. There's a script, lyxpak.py, in the
development tree that will "pack" a LyX file and all its dependencies,
wherever they may be, into a tar, I think. Then it can be shipped off,
unpacked, etc. The difficulty is then in "updating". Obviously, you can
unpack the tar yourself and do with it as you will. But, for security
reasons, you do not really want LyX to be able automatically to unpack and
write to arbitrary locations in your filesystem.
Aren't there options to 'tar' that can help with this, e.g. only allowing
things to be written to somewhere inside a subdirectory.
As for the "updating", I don't think 'tar' will be enough... you could
expand the .tar-file into a separate directory and then compare the
directories and manually move the files that have changed _and_ that you
want to use to replace your version of those files. Then I thought a bit
more for a solution, but what I came up with really just ended up
amounting to a version control system where you were emailing changes.
So why not go for a distributed version control system that supports
sending changes (or all of it) as e-mail. This way you can get by without
a server.
/Christian
--
Christian Ridderström Mobile: +46-70 687 39 44