Dear all,
Richard and I have argued about this embedding feature for a long
time. It bored both of us, actually all developers. Now that Richard
has signed off (http://wiki.lyx.org/Devel/BundleSuggestions#toc2), I
can finally free myself from this torturous experience.
The most recent snapshot
Dear all,
The encryption approach solves the privacy problem perfectly but can
be a little bit complicated for users, also for developers. I have
updated my proposal with detailed inset and buffer level features.
This approach uses a 'Make embedded files anonymous' feature to
address the privacy
On Mon, May 19, 2008 at 12:54 PM, Pavel Sanda <[EMAIL PROTECTED]> wrote:
>> If you guys feel that neither proposal should be
>> implemented for 1.6.0, I will not complain.
>
> thats exactly my feeling now.
I have seen Jurgen and Abdel's emails so I guess I do not have to wait
for a week. Jurgen
> Speaking from a former life: In almost all cases I would have liked to
> have fully embedded (i.e. "copied") graphics, drawings, code snippets
> even if I used them in multiple .lyx files. A noteworthy exception would
> have been the .bib files that continued to receive minor updates (mostly
>
> Sorry Bo but I have to say that you've been being unfair to Richard in
> general. He had the pugnacity (or should I say stoicity?) to continue the
> discussion regardless of your repeated critiscisms and I think you should
> respect that.
If his proposal is as good as he claimed, how could I
> by quick denial of any problem I pointed out with a proper explanation.
Of course I meant 'without'.
Bo
> So a possible solution of that dilemma would be to leave the issue
> to some third person to solve in a way he likes and live with the
> result or improve on that result,.
This was exactly what I was proposing, but people did not want to step
in, I guess for social reasons because the technical
> no. i steped in just as complete outsider seduced by the 'summary' keyword
> in subject to know whats the better solution and what i would vote in case
> it will be some poll. my fail probably that i put down questions out of
> misunderstanding of the proposals - but anyway - on my question i
I have seen an email from Richard titled 'Profanity, rudeness' or
whatever. I did not read the email but I guess he would be accusing me
as being rude. If anyone is going to follow him, I would politely ask
you to read the wiki and point out exactly which sentences are rude. I
would also like to
> I'm afraid I have to join this discussion again. I must say that I agree
> with Abdel here, and Bo's reply just reinforces Abdel's point.
Bennett,
I have pointed out quite a few times that I would agree with Richard's
proposal as long as it can be implemented in a non-intrusive way. That
is to
* A wrapped bundle is a compressed archive of an unwrapped bundle, e.g.
zip-archive of an unwrapped bundle.
Not sure it's the best, but I think having something like this in the
beginning of the description would help.
Your understanding is correct. Because it is really bad to introduce a
> * A wrapped bundle is a compressed archive of an unwrapped bundle, e.g.
> zip-archive of an unwrapped bundle.
>
> Not sure it's the best, but I think having something like this in the
> beginning of the description would help.
Your understanding is correct. Because it is really bad to
If it's even difficult to understand for developers, I'm afraid it is too
complicated for most users. Would it not be sufficient to have a single
bundling mode?
I agree. I wrote a long email comparing the designs of two approaches
(in the thread 'A solid implementation'). My design may be more
So, if a user turns off 'compression', will $TEMP_DIR/filename.lyxdir
be moved to $DOC_DIR/filename.lyxdir?
Unless such a directory exists, in which case it'll be moved to a new empty
directory, just as on your proposal. But of course, if you think something
else should happen, it could.
> If it's even difficult to understand for developers, I'm afraid it is too
> complicated for most users. Would it not be sufficient to have a single
> bundling mode?
I agree. I wrote a long email comparing the designs of two approaches
(in the thread 'A solid implementation'). My design may be
>> So, if a user turns off 'compression', will $TEMP_DIR/filename.lyxdir
>> be moved to $DOC_DIR/filename.lyxdir?
>
> Unless such a directory exists, in which case it'll be moved to a new empty
> directory, just as on your proposal. But of course, if you think something
> else should happen, it
I've only skimmed these threads (actually, I've been trying to avoid
them...).
If you do, especially if you have read my last email on that thread
which quotes lots of correspondences, you would have found that my
proposal has been clearly stated and Richard has been illusive. It was
actually
Scons versions installs the stuff
just fine, but it does not copy the binaries other than lyx and
texlyx.
Scons, as a build system, build lyx and install all lyx related stuff
like lyx2lyx. A developer is supposed to give lyx a working
environment by e.g. setting $PATH to the QT library
Enrico's python script is a step in this direction.
Yes. But my goal is a bit more. In short, it allows you to send a .lyx
file to your advisor, he can simply open, view, edit and print it. The
instituion-specific class and layout files, and your figures are
embedded.
Bo
...you too have two copies of the file.
That is: If, on your approach, a graphic is embedded and the user hits Edit
file, which file do they edit? The embedded one, of course, since there may
be no external file. But what if there is an external file and they edit
that? No effect on the
Users can edit the bundled copy directly IF the file isn't wrapped.
But your approach has nothing to do with wrap, Right? :-)
You do not really know what you are talking about here. Wrapped or
not, when a lyx file is edited, filename.lyxdir is there and users are
allowed to edit the bundled
On my approach, bundled files are invisible if the file is also wrapped.
Users do not have to add anything to a subversion repository in this case,
either. If there's a worry about the file's being binary, then I can base64
encode it instead. Whatever.
Please choose a file format for your
And it would be a trivial exercise to modify Enrico's script so that all
your advisor had to do was unzip and then open the LyX file that
appeared---the associated files now being in a subdirectory, and the LyX
file itself having been changed so that insets now point to those files. And
if
This debate would have been a lot easier if you had made a lot fewer
comments of this type. And for what it's worth, the word is elusive.
I do not want to embarrass you again by citing what you have said
during the discussion. You have indeed being elusive by using a zip
format before, and deny
On Thu, May 15, 2008 at 9:06 AM, José Matos [EMAIL PROTECTED] wrote:
On Thursday 15 May 2008 14:36:46 Bo Peng wrote:
He claimed that there is no difference between our approaches. Is it true?
To it seems that differences are just implementation details, and intrepid
user will recover easily
When was the last time that you have changed an embedded file inside a OO
(Open Office) document?
Never.
The OO documents are zip files with a structure that looks similar to your
initial proposal.
Yes.
Although I sometimes work with OO (due mainly to word :-( ) I have never
changed any
Not true. Being in the temp folder doesn't mean they are invisible.
No. This 'invisibility' is at the design level. I hide the file but
users can of course dig it out. Richard's approach is different in
that it shows the file and *expect* users to modify them.
General remark on base64 versus
Take the current lyx file as an example, we discourage the manual change of
lyx files but we don't disallow it.
You completely missed the point. Of course users can manually edit
.lyx file, edit filename.lyxdir/figures/figure.png, even dig out my
hidden E23479789.png and edit, but if a feature
On Thu, May 15, 2008 at 10:35 AM, [EMAIL PROTECTED] wrote:
I've just gotten my compiled LyX in Ubuntu to work by installing lots of
extra packages. Then I modified TEXINPUTS to find a locally/manually
installed package.
In either of the bundling suggestions, will local .cls-file and
I saw Richard referring to the session solution to this case.
No. These are two completely different issues. This thread is about
visibility and edition of embedded/bundled files, and the session
solution is about once your turn on the bundled mode, how to turn it
off.
Bo
I'm probably dense[*], but what's wrong with keeping a bunch of files in
filename.lyxdir and modify them there?
I guess people simply jump to the last email of a thread?? (No need to
regret though).
The problem is that there are two visible copies of the same file, the
external one and the
Automatic inclusion will be unlikely for any of the proposals because
it is hard to tell which classes are standard latex packages that do
not need to be included, and which ones are customized. Also, it is
hard to include all needed .sty and other sort of dependent files.
Some of these
So you mean that is not possible to edit the bundled files with Richards
approach?
It is possible to edit the bundled files with Richard's approach, this
has nothing to do with session.
In Richard's approach, there is this external file
chapter2/figure.png, and a corresponding
Maybe you don't know for sure which case you are dealing with?
Maybe it's very nice to be able to view the PDF of a bundle several years
down the road, when you don't have the time to make LyX build it properly.
There is nothing wrong to include a pdf file just in case the
recipient can not
and i would add: no individual embedding (like in odf i guess)
(which would probably boil down to something very similar like this:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg138780.html)
Edwin,
I have seen this link a few times, are you sure you want to propose
your idea? We
Are you proposing to add a file browser to lyx?
Because we need the mime-type association for the different file types to
edit.
Would you be happy with a file browser launched on a temporary directory to
inspect and change the file content of the embedded files?
Would this solve your
With the details worked out, I think this is pretty similar to what I've
got.
That is great. Then we do not have a new proposal to worry about (if
Edwin agrees).
Bo
Probably I fail to see the problem, my fault.
AFAIU if a user wants to replace a file in the bundle there is no one
preventing it from happen. Under any of the different contender proposals.
Not really. My proposal disallows external editing of embedded files.
Being able to edit a bundled
You do not really know what you are talking about here. Wrapped or
not, when a lyx file is edited, filename.lyxdir is there and users are
allowed to edit the bundled copy directly. For example, if you have a
bundled file in zip or base64 format, when you open it, because the
insets refers to
If the file is wrapped, then it would be unpacked in the temporary
directory: wrapping is essentially just an extension of compression. If it's
not wrapped, then of course it doesn't need to be unpacked.
Now, here comes another surprise.
Currently, when we have a compressed file, we open it
Trust me. I'm not the one you're embarrassing.
Then read your own mails. You said that you would use zip format and
later denied it. All mails are achieved.
Bo
Not really. My proposal disallows external editing of embedded files.
So I embed my bibfile and now I can't edit it? If so, this is a very big
flaw.
I meant that you are discouraged from editing it directly, like unzip
a OOo document, edit and zip it back. You have to do it in lyx, by
I think most people will not be able to be consistent over such a prolonged
discussion...
Consistency would be easy to achieve if people know what they are
doing and have a clear mind during the discussions. Shifting back and
forth makes the discussions difficult and wastes other's time. If you
Note that extracting files to the document directory can cause
problems with permissions. If a user only has the permissions to edit a
single file, there will be no problem when embedded files are temporarily
extracted to the temp directory. However, creating files and new folders in
the
I want quickly to summarize where I think this discussion is now.
I would just like to point out that
1. Without a bundled mode, there is no change for existing documents
in my approach.
2. Individual embedding allows continuous use of external files.
Individual embedding is not chosen only
You uncompress to LyX's temporary directory. So you now have:
/tmp/lyx_randomstuff/filename.lyx
/tmp/lyx_randomstuff/filename.lyxdir/
Then LyX opens the former.
Isn't this exactly how compressed files work now?
Sorry, this is still unclear to me.
In your approach, when you turn on the
It depends upon whether the file is bundled or also wrapped. If the file is
just bundled, then there's just $DOC_DIR/filename.lyxdir.
So, if a user turns off 'compression', will $TEMP_DIR/filename.lyxdir
be moved to $DOC_DIR/filename.lyxdir?
Now, when I turn on 'compression', what will happen
I'm trying to concentrate on very general questions
about how these two proposals work. The question, Do you use zip or tar or
base64? is just not worth discussing at this point. ...
Richard,
We are both tired of this discussion. My proposal is solid. I can
provide every bit of detail if you
Well, let us start from the beginning. Hopefully at a level of design. :-)
But I first would like to point out that designs dictate
implementations. If I do not introduce a bundled mode, I can not use a
zip format. I can not switch a file to binary format just because I
insert an embedded inset.
> I've only skimmed these threads (actually, I've been trying to avoid
> them...).
If you do, especially if you have read my last email on that thread
which quotes lots of correspondences, you would have found that my
proposal has been clearly stated and Richard has been illusive. It was
actually
>> Scons versions installs the stuff
>>
>> just fine, but it does not copy the binaries other than lyx and
>> texlyx.
Scons, as a build system, build lyx and install all lyx related stuff
like lyx2lyx. A developer is supposed to give lyx a working
environment by e.g. setting $PATH to the QT
> Enrico's python script is a step in this direction.
Yes. But my goal is a bit more. In short, it allows you to send a .lyx
file to your advisor, he can simply open, view, edit and print it. The
instituion-specific class and layout files, and your figures are
embedded.
Bo
>> ...you too have two copies of the file.
>>
> That is: If, on your approach, a graphic is embedded and the user hits "Edit
> file", which file do they edit? The embedded one, of course, since there may
> be no external file. But what if there is an external file and they edit
> that? No effect
> Users can edit the bundled copy directly IF the file isn't wrapped.
But your approach has nothing to do with wrap, Right? :-)
You do not really know what you are talking about here. Wrapped or
not, when a lyx file is edited, filename.lyxdir is there and users are
allowed to edit the bundled
> On my approach, bundled files are invisible if the file is also "wrapped".
> Users do not have to add anything to a subversion repository in this case,
> either. If there's a worry about the file's being binary, then I can base64
> encode it instead. Whatever.
Please choose a file format for
> And it would be a trivial exercise to modify Enrico's script so that all
> your advisor had to do was unzip and then open the LyX file that
> appeared---the associated files now being in a subdirectory, and the LyX
> file itself having been changed so that insets now point to those files. And
>
> This debate would have been a lot easier if you had made a lot fewer
> comments of this type. And for what it's worth, the word is "elusive".
I do not want to embarrass you again by citing what you have said
during the discussion. You have indeed being elusive by using a zip
format before, and
On Thu, May 15, 2008 at 9:06 AM, José Matos <[EMAIL PROTECTED]> wrote:
> On Thursday 15 May 2008 14:36:46 Bo Peng wrote:
>> He claimed that there is no difference between our approaches. Is it true?
>
> To it seems that differences are just implementation details, and intrepi
> When was the last time that you have changed an embedded file inside a OO
> (Open Office) document?
Never.
> The OO documents are zip files with a structure that looks similar to your
> initial proposal.
Yes.
> Although I sometimes work with OO (due mainly to word :-( ) I have never
>
> Not true. Being in the temp folder doesn't mean they are invisible.
No. This 'invisibility' is at the design level. I hide the file but
users can of course dig it out. Richard's approach is different in
that it shows the file and *expect* users to modify them.
> General remark on base64 versus
> Take the current lyx file as an example, we discourage the manual change of
> lyx files but we don't disallow it.
You completely missed the point. Of course users can manually edit
.lyx file, edit filename.lyxdir/figures/figure.png, even dig out my
hidden E23479789.png and edit, but if a
On Thu, May 15, 2008 at 10:35 AM, <[EMAIL PROTECTED]> wrote:
> I've just gotten my compiled LyX in Ubuntu to work by installing lots of
> extra packages. Then I modified TEXINPUTS to find a locally/manually
> installed package.
>
> In either of the bundling suggestions, will "local" .cls-file and
> I saw Richard referring to the session solution to this case.
No. These are two completely different issues. This thread is about
visibility and edition of embedded/bundled files, and the session
solution is about once your turn on the bundled mode, how to turn it
off.
Bo
> I'm probably dense[*], but what's wrong with keeping a bunch of files in
> filename.lyxdir and modify them there?
I guess people simply jump to the last email of a thread?? (No need to
regret though).
The problem is that there are two visible copies of the same file, the
external one and the
>> Automatic inclusion will be unlikely for any of the proposals because
>> it is hard to tell which classes are standard latex packages that do
>> not need to be included, and which ones are customized. Also, it is
>> hard to include all needed .sty and other sort of dependent files.
>> Some of
> So you mean that is not possible to edit the bundled files with Richards
> approach?
It is possible to edit the bundled files with Richard's approach, this
has nothing to do with session.
In Richard's approach, there is this external file
chapter2/figure.png, and a corresponding
> Maybe you don't know for sure which case you are dealing with?
>
> Maybe it's very nice to be able to view the PDF of a bundle several years
> down the road, when you don't have the time to make LyX build it properly.
There is nothing wrong to include a pdf file just in case the
recipient can
> and i would add: no individual embedding (like in odf i guess)
>
> (which would probably boil down to something very similar like this:
> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg138780.html)
Edwin,
I have seen this link a few times, are you sure you want to propose
your idea? We
> Are you proposing to add a file browser to lyx?
> Because we need the mime-type association for the different file types to
> edit.
>
> Would you be happy with a file browser launched on a temporary directory to
> inspect and change the file content of the embedded files?
>
> Would this
> With the details worked out, I think this is pretty similar to what I've
> got.
That is great. Then we do not have a new proposal to worry about (if
Edwin agrees).
Bo
> Probably I fail to see the problem, my fault.
>
> AFAIU if a user wants to replace a file in the bundle there is no one
> preventing it from happen. Under any of the different contender proposals.
Not really. My proposal disallows external editing of embedded files.
Being able to edit a
>> You do not really know what you are talking about here. Wrapped or
>> not, when a lyx file is edited, filename.lyxdir is there and users are
>> allowed to edit the bundled copy directly. For example, if you have a
>> bundled file in zip or base64 format, when you open it, because the
>> insets
> If the file is wrapped, then it would be unpacked in the temporary
> directory: wrapping is essentially just an extension of compression. If it's
> not wrapped, then of course it doesn't need to be unpacked.
Now, here comes another surprise.
Currently, when we have a compressed file, we open
> Trust me. I'm not the one you're embarrassing.
Then read your own mails. You said that you would use zip format and
later denied it. All mails are achieved.
Bo
>> Not really. My proposal disallows external editing of embedded files.
>
> So I embed my bibfile and now I can't edit it? If so, this is a very big
> flaw.
I meant that you are discouraged from editing it directly, like unzip
a OOo document, edit and zip it back. You have to do it in lyx, by
> I think most people will not be able to be consistent over such a prolonged
> discussion...
Consistency would be easy to achieve if people know what they are
doing and have a clear mind during the discussions. Shifting back and
forth makes the discussions difficult and wastes other's time. If
> Note that extracting files to the document directory can cause
> problems with permissions. If a user only has the permissions to edit a
> single file, there will be no problem when embedded files are temporarily
> extracted to the temp directory. However, creating files and new folders in
> the
> I want quickly to summarize where I think this discussion is now.
I would just like to point out that
1. Without a bundled mode, there is no change for existing documents
in my approach.
2. Individual embedding allows continuous use of external files.
Individual embedding is not chosen only
> You uncompress to LyX's temporary directory. So you now have:
> /tmp/lyx_randomstuff/filename.lyx
> /tmp/lyx_randomstuff/filename.lyxdir/
> Then LyX opens the former.
>
> Isn't this exactly how compressed files work now?
Sorry, this is still unclear to me.
In your approach, when you turn
> It depends upon whether the file is bundled or also wrapped. If the file is
> just bundled, then there's just $DOC_DIR/filename.lyxdir.
So, if a user turns off 'compression', will $TEMP_DIR/filename.lyxdir
be moved to $DOC_DIR/filename.lyxdir?
Now, when I turn on 'compression', what will
> I'm trying to concentrate on very general questions
> about how these two proposals work. The question, "Do you use zip or tar or
> base64?" is just not worth discussing at this point. ...
Richard,
We are both tired of this discussion. My proposal is solid. I can
provide every bit of detail if
Well, let us start from the beginning. Hopefully at a level of design. :-)
But I first would like to point out that designs dictate
implementations. If I do not introduce a bundled mode, I can not use a
zip format. I can not switch a file to binary format just because I
insert an embedded inset.
Dear all,
Two approaches to embed or bundle external files have been presented
in the 'alternative to individual embedding?' thread. If you are
interested, but did not have time to follow the heated discussions,
here is a summary.
Approach one: individual embedding.
1) Each and every external
the first thing is whether you both agree on this summary :)
maybe Richard would like to change some points :)
They are basically 'facts' extracted from the debate. Of course
Richard can correct me if I were wrong.
- i don't like the 'extract all embed' feature in concept1. if some chaotic
This has been debated. Using the second approach, because lyx has to
work on the unbundled .lyx file, it is difficult to restore relative
locations of extracted files. This is why Richard chose not to
unbundle files to their original locations. Unbundling will be an
export feature that
nono, i mean the extension of the resulting embeded (or bundled) file.
currently the name will filename.lyx (right?) which i'm opposed and will later
flame on, no matter which proposal is going to be used :)
The filename in my approach is .lyx because there is no bundled mode,
even after you
3) The code needed for this approach is much more complex than the code
needed for the other approach.
I do not take this one. Have you ever read my patch? The changes to
InsetGraphics are only a few lines.
It gets wrapped to filename.lyz, and the tool used to wrap it is an
implementation
There's no difference between the approaches on this point. On my treatment,
the files are already unbundled in filename.lyxdir/, and you can do with
them as you like.
I need to go but,
I have asked you before whether or not you expect users to manipulate
files inside filename.lyxdir
On Wed, May 14, 2008 at 6:01 PM, Pavel Sanda [EMAIL PROTECTED] wrote:
Please, there is no 'free write back to tree' stuff ...
then i haven't been able to get reasonable image of proposals from
your summary.
Well, you have not told me where you got this 'free write back to
tree' feeling. I
Dear all,
Two approaches to embed or bundle external files have been presented
in the 'alternative to individual embedding?' thread. If you are
interested, but did not have time to follow the heated discussions,
here is a summary.
Approach one: individual embedding.
1) Each and every external
> the first thing is whether you both agree on this summary :)
> maybe Richard would like to change some points :)
They are basically 'facts' extracted from the debate. Of course
Richard can correct me if I were wrong.
> - i don't like the 'extract all embed' feature in concept1. if some
> This has been debated. Using the second approach, because lyx has to
> work on the unbundled .lyx file, it is difficult to restore relative
> locations of extracted files. This is why Richard chose not to
> unbundle files to their original locations. Unbundling will be an
> export feature
> nono, i mean the extension of the resulting embeded (or bundled) file.
> currently the name will filename.lyx (right?) which i'm opposed and will later
> flame on, no matter which proposal is going to be used :)
The filename in my approach is .lyx because there is no bundled mode,
even after
> 3) The code needed for this approach is much more complex than the code
> needed for the other approach.
I do not take this one. Have you ever read my patch? The changes to
InsetGraphics are only a few lines.
> It gets wrapped to filename.lyz, and the tool used to wrap it is an
>
>
> There's no difference between the approaches on this point. On my treatment,
> the files are already "unbundled" in filename.lyxdir/, and you can do with
> them as you like.
I need to go but,
I have asked you before whether or not you expect users to manipulate
files inside filename.lyxdir
On Wed, May 14, 2008 at 6:01 PM, Pavel Sanda <[EMAIL PROTECTED]> wrote:
>> Please, there is no 'free write back to tree' stuff ...
>
> then i haven't been able to get reasonable image of proposals from
> your summary.
Well, you have not told me where you got this 'free write back to
tree'
Many users already maintain their own directory underneath the document
directory. They can of course continue to do so.
They cannot. Once the document is turned to the 'bundled mode', users
have to depend on 'update from external' to make their changes to
these files available to lyx. What
Yes, a file that can be read/handled without LyX is more powerful. We
could try to use MIME format for LyX files, but it may become
unpleasant to handle.
Sure, 'may become unpleasant' when you try to handle .lyx file without
lyx, but the problems I have mentioned may make everyday lyx usage
I like Richard's solution better. Having a zip based solution means that you
can 'unbundle' from the command line even without LyX, the base64 solution
is more complex.
On the other hand, the file format in my proposal is still plain text.
For many other operations such as search and
If I think of openoffice zip file versus ms office
filesystem-in-a-file, I know which one is easier to tinker with.
Base64 may seem nice because it is text, but if child documents end up
being in base64, all the interested of svn is lost, for example.
We should choose a file format that
401 - 500 of 8038 matches
Mail list logo
