Bo Peng wrote:
Richard Heck wrote:
I'm going to move this part of the discussion to a separate thread. It
has to do with how embedding works from the user's perspective, not from
an implementation perspective. And I should say that I'm not trying to
be critical here in a bad way. This feature will be very useful to
people who are collaborating with others, and that potentially includes
me. But I'm not sure that we have the right design for this, from the
perspective of the user. And right now you are the only one who knows
exactly how this thing works, so I'm telling you about my problems.
Speaking as a potential user of this feature, I find this very
counterintuitive. I select a bibliography file, choose "Embed" (let's
say the document is already in embedded status), and now the edits I
make the file have no effect. If my co-author sends me a file, I have to
uncheck Document>Save in Bundled Format (not very intuitive!) to extract
the files, and then remember to recheck it when I save.
I am aware of these problems.
In the very first version of my embedding design, I have something
called AUTO embedding mode. That is to say, an embedded file in this
mode will automatically use an external version when it exists. That
proposal was disliked by all other developers.
Because it loses data, I'd suppose. My co-author sends me a file with
changes to a graphic, but LyX uses the old version on my disk. The
current version has a similar problem: Extraction won't over-write a
file, so it too loses my co-author's changes. There at least needs to be
an option to over-write, and maybe we should check timestamps and
checksums. But I'm not sure I like that very much either.
Speaking of which, the timestamps in the zip file seem to be wrong:
[EMAIL PROTECTED] tmp]$ unzip -l bundle.lyx
Archive: bundle.lyx
Length Date Time Name
-------- ---- ---- ----
1328 12-31-49 19:00 content.lyx
63778 12-31-49 19:00 ./test/corsiar.png
-------- -------
65106 2 files
That is probably easily fixable.
The situation is not that bad when you get use to the unique (?)
bundle/unbundle feature of lyx. Normally, you work unbundled and make
use of external files as usual. Only when you need to send your file
to others do you bundle the lyx file. Note that some people may prefer
the word/ooffice way of embedding, i.e., working in bundled mode.
But it's not obvious that it's possible to work in bundled mode right
now. Editing a bundled graphic attempts to edit the file on disk, which
may not even exist. That can be fixed. But it's harder to see how to
work with embedded .bib files let alone arbitrary embedded files. Of
course, you can dig into the temporary directory, but that's not very
happy as a solution.
So I keep thinking that the solution to this is that whenever you open a
bundled file, it immediately unbundles itself and uses the unbundled
files, just like a normal LyX file would. In that case, bundling has
only to do with how the file is opened and saved and nothing to do with
how LyX works with it. Doesn't that seem like the simplest and most
intuitive way of operating? Now, you open a graphics inset, and it says
"images/file.png", but you try to edit that (without using LyX's edit
function) and nothing happens, or maybe the file isn't even there; on
the model I just mentioned, it is, and it's the right file, too. Note
how much this would simplify the implementation: No more copying to and
from the temporary directory; no more updating from external files;
InsetBibtex::latex() wouldn't have to know about bundled files, so
export works normally with no hassles; and the same goes for other insets.
Note that there is a sense in which this is equivalent to what you
suggested above: "Normally, you work unbundled and make use of external
files as usual. Only when you need to send your file to others do you
bundle the lyx file." My proposal just saves the user from having to
bundle and unbundle: LyX does it for you every time.
Now I can see issues with this. Cross-platform issues, path issues,
issues about over-writing files, etc. But those all seem like technical
issues that we can solve, and they exist for unbundling whenever it is
done, so they have to be solved either way.
Anyway, I'm just throwing this out there.
Richard
