Bo Peng wrote:
> 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.
The current implementation may not work well, but file checksum are
compared during file extraction. A file will not be copied if two
files are identical. Otherwise, users will be promoted for overwrite.
I'll check this.
> 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.
Again, this should be a bug if external file is used for editing.
Editing a bundled graphics should edit temppath()/inzipname. Why do
you say 'digging into the temporary directory' is not good? You edit
an bundled file which will be saved and used, right?
Yes, but surely the user shouldn't need to go hunting for
/tmp/lyx_tmpdir89087/.../biblio.bib.
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?
Do you mean you want to extract all bundled files to 'user' directory?
But do you, and how do you clean up them after editing is done?
A reasonable question.
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.
This must be a bug. EmbeddedFile::availableFile() should be editted,
which in this case is the embedded version.
Same bug as before.
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.
I have to admit I am tempted. :-)
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.
I agreed, but your approach impose a particular way of working with
embedded files, and my approach allows both.
But not for all embedded files. In particular, not for .bib files, so
far as I can see, unless (at least) we implement an edit feature for them.
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.
If you are going to extract to user directories, the problem can be
serious. It would be really strange to extract to somewhere outside of
the document directory, not mentioning system path. Right now, these
problems have been solved because we have control on filenames etc
under the temp directory, where '../blah' is translated to
'updir/blah'.
But the problem still exists for extraction.
Anyway, I'm just throwing this out there.
I certainly welcome such discussions, which was lacking during my
development of this feature. The design of this feature has changed
dramatically at least twice and most of the code has been rewritten
several times. The current implementation is finally the way I think
how this feature should be.
OK.
rh
