On Sun, Apr 13, 2008 at 11:44 AM, <[EMAIL PROTECTED]> wrote:
> /Christian
sourceforge.net should seriously be considered.
Bo
> To be honest, this does not look overly attractive to me right now.
I can say "if blah blah, and blah can trust sourceforge for their
development, so can lyx". The list of blahs is easy to get so I even
did not try to make one.
> Of course there are also a few technical details: Like could
I may have done something similar before.
obviously not (but you should have).
I was about to, two weeks ago, but then I was seriously distracted.
Frankly, I am not in a mode to produce any patch now.
Bo
1. bundling creates a zip whereto all the files are copied (as in abdel's
2.) and files loose their original reference.
OK (not that I am accepting this idea).
editing a bundle is like
editing a regular lyx file, it get extracted to tmpdir etc. to update say a
graphics you browse to it and
I can see that figure.png is copied to [tmpdir]/filename.lyxdir/embed,
to filename.embed/figure.png and so on during bundling and unbundling.
You also need to change .lyx file several times,
Only when bundling/unbundling actually. But you may note that, if
everything is already inside
1. You are forcing users to use a specific directory structure because
*you* think it is best for them.
Also, what I do not understand is that, if the KISS structure is such
a good thing, why don't you practice it yourself? You can create a
directory, put all figures inside it. The current
No. You extract [tmpdir]filenamedir.lyxdir/embed from the bundle to
$DOC_DIR/filename.embed. (Or you had a typo?)
No, I mean that the file _contents_ will not change. Changing names is not
very important.
But the inset presentation will change, right?
filename.lyxdir (a directory?),
But the inset presentation will change, right?
Only when the document is organized for bundling. And please note that this
can be done externally by a python script such as the one proposed by
Enrico.
But the document is changed. Viewed from another machine, the insets
are different.
Just an additional precision here WRT code complexity. Actions a) to f) can
be done via an external script.
Maybe your proposed can be done in a script, but I still do not
understand *why* you want to rename these files, and *why* you want to
put filenames in a session file. When I asked you
and *why* you would like to store some filename
information that has always been saved with lyx.
store should be 'throw away'.
Bo
On Sat, Apr 12, 2008 at 9:16 AM, Edwin Leuven [EMAIL PROTECTED] wrote:
Bo Peng wrote:
Are you aware of that this is indeed what I am doing?
so why the:
I was talking about that specific feature. Not in general.
Bo
> > I may have done something similar before.
>
> obviously not (but you should have).
I was about to, two weeks ago, but then I was seriously distracted.
Frankly, I am not in a mode to produce any patch now.
Bo
> 1. bundling creates a zip whereto all the files are copied (as in abdel's
> 2.) and files loose their original reference.
OK (not that I am accepting this idea).
> editing a bundle is like
> editing a regular lyx file, it get extracted to tmpdir etc. to update say a
> graphics you browse to
> > I can see that figure.png is copied to [tmpdir]/filename.lyxdir/embed,
> > to filename.embed/figure.png and so on during bundling and unbundling.
> > You also need to change .lyx file several times,
> >
>
> Only when bundling/unbundling actually. But you may note that, if
> everything is
> 1. You are forcing users to use a specific directory structure because
> *you* think it is best for them.
Also, what I do not understand is that, if the KISS structure is such
a good thing, why don't you practice it yourself? You can create a
directory, put all figures inside it. The current
> > No. You extract [tmpdir]filenamedir.lyxdir/embed from the bundle to
> > $DOC_DIR/filename.embed. (Or you had a typo?)
>
> No, I mean that the file _contents_ will not change. Changing names is not
> very important.
But the inset presentation will change, right?
> > filename.lyxdir (a
> > But the inset presentation will change, right?
> >
> Only when the document is organized for bundling. And please note that this
> can be done externally by a python script such as the one proposed by
> Enrico.
But the document is changed. Viewed from another machine, the insets
are
> Just an additional precision here WRT code complexity. Actions a) to f) can
> be done via an external script.
Maybe your proposed can be done in a script, but I still do not
understand *why* you want to rename these files, and *why* you want to
put filenames in a session file. When I asked you
> and *why* you would like to store some filename
> information that has always been saved with lyx.
store should be 'throw away'.
Bo
On Sat, Apr 12, 2008 at 9:16 AM, Edwin Leuven <[EMAIL PROTECTED]> wrote:
> Bo Peng wrote:
>
> > Are you aware of that this is indeed what I am doing?
> so why the:
I was talking about that specific feature. Not in general.
Bo
Enrico's solution can be combined with JMarc's directory structure AFAIU.
Richard (JMarc), will you accept a 'open by winzip' solution as Enrico proposed?
No, we are not forced to do this. I can well imagine two push buttons
corresponding to two use cases: organise document for bundling
Then our last disagreement would be on your session proposal. I know
you would not like me to abuse our user's guide again, but if a user
send us a revised user's guide in bundled format, none of us can
unbundle it cleanly to our tree because only he has the session file
on his
Richard (JMarc), will you accept a 'open by winzip' solution as Enrico
proposed?
Note that we could as well use the internal zip for opening such files, no
need to do that externally.
There are some issues here.
1. When a user opens filename.lyz, Richard's proposal, as far as I
This change should have been a file format change and the embed parameter
should have been removed on reversion.
This patch saves what can be saved and mends the reversion. However, the file
format corruption (that concerns rev. 22442 to 22470) cannot be undone :-(
I invite you to join
The way _I_ would like things to work for me (the use case 2 I was
talking about) is as follow:
1) I write a document in tradional, unbundled, fashion: 'filename.lyx'
2) When I am done, I click save in bundled format. This will
generate a 'filename.lyz' file wherever I said to generate it (could
2.d) copy referenced files to [tmpdir]/filename.lyxdir/embed/
2.e) modify [tmpdir]/filenamedir.lyxdir/content.lyx
3-b) The reviewer ... This will create 'filename.lyx' directly extracted from
'content.lyx' in the archive as well as the 'filename.embed'
I can see that figure.png is
I think it is enough to remove all \embed from the insets and I may
have done something similar before.
Cheers,
Bo
On Fri, Apr 11, 2008 at 12:21 PM, [EMAIL PROTECTED] wrote:
Author: spitz
Date: Fri Apr 11 19:20:59 2008
New Revision: 24239
URL: http://www.lyx.org/trac/changeset/24239
>
> Enrico's solution can be combined with JMarc's directory structure AFAIU.
Richard (JMarc), will you accept a 'open by winzip' solution as Enrico proposed?
>
> No, we are not forced to do this. I can well imagine two push buttons
> corresponding to two use cases: "organise document for
> > Then our last disagreement would be on your session proposal. I know
> > you would not like me to abuse our user's guide again, but if a user
> > send us a revised user's guide in bundled format, none of us can
> > unbundle it cleanly to our tree because only he has the session file
> >
> > Richard (JMarc), will you accept a 'open by winzip' solution as Enrico
> proposed?
> >
>
> Note that we could as well use the internal zip for opening such files, no
> need to do that externally.
There are some issues here.
1. When a user opens filename.lyz, Richard's proposal, as far as I
> > This change should have been a file format change and the embed parameter
> > should have been removed on reversion.
>
> This patch saves what can be saved and mends the reversion. However, the file
> format corruption (that concerns rev. 22442 to 22470) cannot be undone :-(
I invite you
The way _I_ would like things to work for me (the use case 2 I was
talking about) is as follow:
1) I write a document in tradional, unbundled, fashion: 'filename.lyx'
2) When I am done, I click "save in bundled format". This will
generate a 'filename.lyz' file wherever I said to generate it
> 2.d) copy referenced files to [tmpdir]/filename.lyxdir/embed/
> 2.e) modify [tmpdir]/filenamedir.lyxdir/content.lyx
> 3-b) The reviewer ... This will create 'filename.lyx' directly extracted from
> 'content.lyx' in the archive as well as the 'filename.embed'
I can see that figure.png is
I think it is enough to remove all \embed from the insets and I may
have done something similar before.
Cheers,
Bo
On Fri, Apr 11, 2008 at 12:21 PM, <[EMAIL PROTECTED]> wrote:
> Author: spitz
> Date: Fri Apr 11 19:20:59 2008
> New Revision: 24239
>
> URL:
I do not think this personal information problem is relevant. Where
was is brought forward?
All Jose's messages in the thread of 'Will this discussion continue? Re: blah'.
http://marc.info/?l=lyx-develm=120721668632621w=2
http://marc.info/?l=lyx-develm=120733743320967w=2
Cheers,
Bo
2. If you simply can not accept such a filename in .lyx file, you
should disable it for all insets.
Care to explain the difference between in .lyx file and for all insets?
I meant that we should not allow absolute paths in .lyx file for all
insets such as InsetGraphics, not only those
1/ file included by any mean (InsetInclude, InsetGraphics,
InsetExternal, InsetListings) are equivalent and should be treated the
same
Good.
2/ I do not care if there is a reference to an absolute path that is
not bundled with the LyX file. This would be too restrictive and has
I was not proposing to name files based on their md5 key. I was just giving
this as an example how we can compare files not using the file path.
The latter was used extensively in lyx and in EmbeddedFiles during
unbundling, so I did not consider it as a new proposal...
Bo
I will not insist on this as I think that I made my point clear, too much
information leaked can become a security problem later.
Great.
Then our last disagreement would be on your session proposal. I know
you would not like me to abuse our user's guide again, but if a user
send us a revised
On Thu, Apr 10, 2008 at 12:59 PM, Jean-Marc Lasgouttes
[EMAIL PROTECTED] wrote:
Bo Peng [EMAIL PROTECTED] writes:
1. You 9 consecutive folders is not a good argument because even on a
system with that file, you need to open 8 folders.
Err, I usually start from my home directory, which
On Thu, Apr 10, 2008 at 2:15 PM, Edwin Leuven [EMAIL PROTECTED] wrote:
Bo Peng wrote:
What is the problem here?
your fundamental unwillingess to arrive at a reasonable compromise i
suppose...
Because no *reasonable* proposal was given. I spent a lot of time to
design, re-design
i was hoping you would prove me wrong, but alas...
A fundamental problem with JMarc's approach is that he insists on a
directory structure and requires all related files to be copied to
this directory, yet it does not allow you to work in that directory
directly. If you are unlucky to use an OS
Several people have now explained how it can be implemented. Perhaps the
problem isn't with us.
Then, please answer *directly* the following questions:
1. In bundled mode, do you create filename.lyz or
filename.lyxdir/content.lyx when you create a new file and save?
2. What is your *file*
it is still the case or its better now?
do i also understand correctly that the changes pervade to larger areas of
code which is rather far away from bundling? (sorry for such novice
questions,
i havent followed the threads closely, nor i read the code)
The related code is mostly in
i didn't have the impression that the discussion was about
implementation details once everything is under the same directory, but
rather about how to treat out of tree files...
JMarc disallows all out of tree files and yet his proposal does not
work. I have not heard that he agreed with my
Precisely. The discussion was supposed to be about very abstract questions
about how bundling might and should work. And Bo keeps raising questions of
the form, Well, exactly how do you propose to implement this bit? The most
ridiculous thing is that the answers are very often pretty obvious,
Then, please answer *directly* the following questions:
PLEASE, answer these questions directly!
1. In bundled mode, do you create filename.lyz or
filename.lyxdir/content.lyx when you create a new file and save?
2. What is your *file* when a user chooses 'unbundle'? Contineue to be
Please, please, answer my questions. The problem is exactly I can not
think of a way to IMPLEMENT your proposal, even if I accept your
restrictions.
The problem seems very much to be that you don't WANT to think of a way to
implement the proposal.
How can I raise so many questions if I
To give an example: removed the fact that the file
copying that needs to happen to make the embedding stuff work happens in
places like GuiGraphics makes me nervous.
Excuse me? We are talking about your proposal, right? My proposal was
attacked long enough and I have long admitted the code
Reading your insistance on people to answer your question about
bundling/unbundling, I guess that they don't understand why one would need
to work in bundled mode, simply because there is no such bundled mode if
you keep everything in one directory. They just want a packed, portable,
my concern is - in case user will not use bundling feature at all, on
what places can bubble up bugs caused by embeding code. only InsetBibtex
usage? what kind of bugs?
The bugs are related to latex output, which only show up in
InsetBibtex right now. As I have said, the bugs themselves are
1. In bundled mode, do you create filename.lyz or
filename.lyxdir/content.lyx when you create a new file and save?
My proposal, following JMarc, was that bundled mode is separate from
compressed mode. So it depends upon whether we're creating a compressed
bundle or not. If it's supposed
> I do not think this personal information problem is relevant. Where
> was is brought forward?
All Jose's messages in the thread of 'Will this discussion continue? Re: blah'.
http://marc.info/?l=lyx-devel=120721668632621=2
http://marc.info/?l=lyx-devel=120733743320967=2
Cheers,
Bo
> > 2. If you simply can not accept such a filename in .lyx file, you
> > should disable it for all insets.
>
> Care to explain the difference between "in .lyx file" and "for all insets"?
I meant that we should not allow absolute paths in .lyx file for all
insets such as InsetGraphics, not
> 1/ file included by any mean (InsetInclude, InsetGraphics,
> InsetExternal, InsetListings) are equivalent and should be treated the
> same
Good.
> 2/ I do not care if there is a reference to an absolute path that is
> not bundled with the LyX file. This would be too restrictive and has
>
> I was not proposing to name files based on their md5 key. I was just giving
> this as an example how we can compare files not using the file path.
The latter was used extensively in lyx and in EmbeddedFiles during
unbundling, so I did not consider it as a new proposal...
Bo
> I will not insist on this as I think that I made my point clear, too much
> information leaked can become a security problem later.
Great.
Then our last disagreement would be on your session proposal. I know
you would not like me to abuse our user's guide again, but if a user
send us a
On Thu, Apr 10, 2008 at 12:59 PM, Jean-Marc Lasgouttes
<[EMAIL PROTECTED]> wrote:
> "Bo Peng" <[EMAIL PROTECTED]> writes:
>
> > 1. You 9 consecutive folders is not a good argument because even on a
> > system with that file, you need to open 8 folders
On Thu, Apr 10, 2008 at 2:15 PM, Edwin Leuven <[EMAIL PROTECTED]> wrote:
> Bo Peng wrote:
>
> > What is the problem here?
>
> your fundamental unwillingess to arrive at a reasonable compromise i
> suppose...
Because no *reasonable* proposal was given. I spent a lot o
> i was hoping you would prove me wrong, but alas...
A fundamental problem with JMarc's approach is that he insists on a
directory structure and requires all related files to be copied to
this directory, yet it does not allow you to work in that directory
directly. If you are unlucky to use an
> Several people have now explained how it can be implemented. Perhaps the
> problem isn't with us.
Then, please answer *directly* the following questions:
1. In bundled mode, do you create filename.lyz or
filename.lyxdir/content.lyx when you create a new file and save?
2. What is your *file*
> it is still the case or its better now?
>
> do i also understand correctly that the changes pervade to larger areas of
> code which is rather far away from bundling? (sorry for such novice
> questions,
> i havent followed the threads closely, nor i read the code)
The related code is mostly
> i didn't have the impression that the discussion was about
> implementation details once everything is under the same directory, but
> rather about how to treat out of tree files...
JMarc disallows all out of tree files and yet his proposal does not
work. I have not heard that he agreed with
> Precisely. The discussion was supposed to be about very abstract questions
> about how bundling might and should work. And Bo keeps raising questions of
> the form, "Well, exactly how do you propose to implement this bit?" The most
> ridiculous thing is that the answers are very often pretty
> > Then, please answer *directly* the following questions:
PLEASE, answer these questions directly!
> > 1. In bundled mode, do you create filename.lyz or
> > filename.lyxdir/content.lyx when you create a new file and save?
> >
> > 2. What is your *file* when a user chooses 'unbundle'?
> > Please, please, answer my questions. The problem is exactly I can not
> > think of a way to IMPLEMENT your proposal, even if I accept your
> > restrictions.
> >
> The problem seems very much to be that you don't WANT to think of a way to
> implement the proposal.
How can I raise so many
> To give an example: the fact that the file
> copying that needs to happen to make the embedding stuff work happens in
> places like GuiGraphics makes me nervous.
Excuse me? We are talking about your proposal, right? My proposal was
attacked long enough and I have long admitted the code
> Reading your insistance on people to answer your question about
> bundling/unbundling, I guess that they don't understand why one would need
> to work in "bundled" mode, simply because there is no such bundled mode if
> you keep everything in one directory. They just want a "packed", portable,
> my concern is - in case user will not use bundling feature at all, on
> what places can bubble up bugs caused by embeding code. only InsetBibtex
> usage? what kind of bugs?
The bugs are related to latex output, which only show up in
InsetBibtex right now. As I have said, the bugs themselves
> > 1. In bundled mode, do you create filename.lyz or
> > filename.lyxdir/content.lyx when you create a new file and save?
> >
> My proposal, following JMarc, was that bundled mode is separate from
> compressed mode. So it depends upon whether we're creating a compressed
> bundle or not. If it's
Now the third possibility, that is in your opinion not less safe than
the first one, is to allow LyX (after a dialog box that you think
users will not read) to put a copy of the bundled file at the place
where the initial file was. This is much more like a variable passed
by reference,
OK then. To be frank, I did not manage to read all the threads as
carefully as may be necessary.
Now, at least we are talking about the same problem, but just to
clarify, do you also care about information leak from relative paths
../../girlfriends/sally/image.png, or even in tree files such
And it should also be said that, IF we do as Jose suggested, then this
allows the code to be dramatically simplified. But I'll not try to explain
why here. I've done that elsewhere.
I do not agree with this. Most of the code complexity comes from the
bundle-editing mode. If the file is
sha1 or md5 will do the same with the added advantage that they will work
even
if the paths are different. :-)
You call it advantage? You insert image1 and image2 to lyx, later on
you changed image2 and image1 is also changed?? As I have said, path
names contain useful information in a tex
Yes, I call it advantage for storage. If you insert a new file that is
different we could ask if we want to change all instances or just that case.
What is the problem here?
I do not have a solid scenario to say your solution is wrong, but it
sounds like you are naming files by their
OK. While I do not understand at all why keeping paths in .lyx file,
as we have always done, suddenly becomes such a huge concern, I do
understand that such information is not needed when reversibility is
*not* desired. Therefore, I propose that, either through a RC entry, a
menu item, or an
I do not agree with this. Most of the code complexity comes from the
bundle-editing mode. If the file is automatically unbundled, at least
there is no need for EmbeddedFiles in InsetBibtex.
Well, that's what I had in mind: No need for that machinery in the insets.
On the other hand,
> Now the third possibility, that is in your opinion not less safe than
> the first one, is to allow LyX (after a dialog box that you think
> users will not read) to put a copy of the bundled file at the place
> where the initial file was. This is much more like a variable passed
> by
> OK then. To be frank, I did not manage to read all the threads as
> carefully as may be necessary.
Now, at least we are talking about the same problem, but just to
clarify, do you also care about information leak from relative paths
../../girlfriends/sally/image.png, or even in tree files
> And it should also be said that, IF we do as Jose suggested, then this
> allows the code to be dramatically simplified. But I'll not try to explain
> why here. I've done that elsewhere.
I do not agree with this. Most of the code complexity comes from the
bundle-editing mode. If the file is
> sha1 or md5 will do the same with the added advantage that they will work
> even
> if the paths are different. :-)
You call it advantage? You insert image1 and image2 to lyx, later on
you changed image2 and image1 is also changed?? As I have said, path
names contain useful information in a
> Yes, I call it advantage for storage. If you insert a new file that is
> different we could ask if we want to change all instances or just that case.
> What is the problem here?
I do not have a solid scenario to say your solution is wrong, but it
sounds like you are naming files by their
OK. While I do not understand at all why keeping paths in .lyx file,
as we have always done, suddenly becomes such a huge concern, I do
understand that such information is not needed when reversibility is
*not* desired. Therefore, I propose that, either through a RC entry, a
menu item, or an
> > I do not agree with this. Most of the code complexity comes from the
> > bundle-editing mode. If the file is automatically unbundled, at least
> > there is no need for EmbeddedFiles in InsetBibtex.
> >
> >
> >
> Well, that's what I had in mind: No need for that machinery in the insets.
On
The attached patch (against branch) fixes the problem for me and strikes me
sensible anyway.
It is sensible but the problem persists. Here, loading of the figure
fails (not a problem), clicking on the inset works (improvement), but
view pdflatex gives me
*** glibc detected *** double free or
I did not see Richard's messages as particularly closed to discussion.
cite
I guess it is not fun to compress the directory to filename.lyz and open
Sounds fun to me!
/cite
This is where I stop my attempt to respond. If this is fun, any
implementation would be acceptable.
Bo
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.
I guess what I don't see is why this is really very different from
what you did: You zip everything on save, unzip it on open, etc. The
difference has to do with what's in the bundle, where it is, and what kind
of information (if any) is kept about the original location of the things in
the
And I do not really get the problem with the two current directories.
The file browser dialog takes care of relative paths by itself (or at
least it used to).
You said that we can refer to external files, but not bundle them.
This means you can have '../../images/file.png' in an
The only real question is
I am happy to hear this.
where to store the
information about the original location of the file, so you can do the
update from external file thing. Whether there is just a copy in the
bundle isn't the issue. Your version has a copy in the bundle, too. But you
keep
Lastly, if we extract to a special folder
$DOC_PATH/Lyx.Embed.Abs/abs/path, we do not really need to change the
inset.
Let me clarify this. Say we have /usr/var/blah.log in the bundle,
saved using inzipName Lyx.Embed.Abs/usr/var/blah.log. During
unbundling, focusing on the cases of
> The attached patch (against branch) fixes the problem for me and strikes me
> sensible anyway.
It is sensible but the problem persists. Here, loading of the figure
fails (not a problem), clicking on the inset works (improvement), but
view pdflatex gives me
*** glibc detected *** double free
> I did not see Richard's messages as particularly closed to discussion.
>I guess it is not fun to compress the directory to filename.lyz and open
Sounds fun to me!
This is where I stop my attempt to respond. If this is fun, any
implementation would be acceptable.
Bo
> >> 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
> I guess what I don't see is why this is really very different from
> what you did: You zip everything on save, unzip it on open, etc. The
> difference has to do with what's in the bundle, where it is, and what kind
> of information (if any) is kept about the original location of the things in
>
> And I do not really get the problem with the two current directories.
> The file browser dialog takes care of relative paths by itself (or at
> least it used to).
You said that "we can refer to external files, but not bundle them".
This means you can have '../../images/file.png' in an
> The only real question is
I am happy to hear this.
> where to store the
> information about the original location of the file, so you can do the
> "update from external file" thing. Whether there is just a copy in the
> bundle isn't the issue. Your version has a copy in the bundle, too. But
> Lastly, if we extract to a special folder
> $DOC_PATH/Lyx.Embed.Abs/abs/path, we do not really need to change the
> inset.
Let me clarify this. Say we have /usr/var/blah.log in the bundle,
saved using inzipName Lyx.Embed.Abs/usr/var/blah.log. During
unbundling, focusing on the cases of
On Sun, Apr 6, 2008 at 11:53 PM, Enrico Forestieri [EMAIL PROTECTED] wrote:
As yet an another alternative proposal, what would be wrong with using
a python script for creating an archive containing the LyX file and
all needed files?
The script could be improved in many ways, for example in
Currently the LyX splash screen is shown after LyX has started. I think it
would be better to also show it during startup. Especially when LyX runs for
the first time and is being configured (which can take quite some time), it
would be really useful to show the screen with an informative
601 - 700 of 8038 matches
Mail list logo
