> In a way, this is even more flexible than
> your solution. As I said, if the external contributor is interested in your
> file hierarchy, ...
Abdel,
This is the only 'advantage' I see from your messages and I do not see
how your proposal could be more flexible. If two co-authors use
differen
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
> and *why* you would like to store some filename
> information that has always been saved with lyx.
store should be 'throw away'.
Bo
> 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
> > 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
> > 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 direct
> 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 i
> > 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 alrea
> 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
> > 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
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/242
> 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 co
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
> > 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 t
> > 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
u
> > 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
>
> 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 bundl
> > 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 s
> 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 a
> 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,
>
> 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 complex
> > 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 quest
> > 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
> 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 obv
> 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
> 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* w
> 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
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
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
> 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 revise
> 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
> 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
>
> > 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
> 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&m=120721668632621&w=2
http://marc.info/?l=lyx-devel&m=120733743320967&w=2
Cheers,
Bo
> > 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
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 option
> 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 cont
> 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 autom
> 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 te
> 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
> 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 referenc
> 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 extrac
> 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
> 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 InsetGr
> 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
> t
> >> 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 def
> 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
> 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 o
Hi,
Open the attached file, put http://www.lyx.org/~bpeng/geno.jpg to the
same directory, clicking the only graphics inset, or view pdf
will crash lyx under linux. Can anyone confirm? The problem seems to
be with the graphics file, which can not be properly viewed, but this
should not crash lyx.
> Done. The console output of configure.py is also captured and shown in the
> details list of the installer.
Could you please also update the branch?
Bo
> > But the lyx file will not recognize them, right? What if the author
> > unpack the file again? He will need to copy /c/file to c:/file
> > manually.
>
> Note that this same problem is present with your proposal when you
> want to unbundle on a different platform.
My proposal has a bundle-
> > Hi, Richard,
Having seen your message, I decide not to answer it because your 'this
is not a problem' attitude is hard to beat. Yet, I do not see a
practical implementation for this and will not be able to adapt my
implementation to it. If JMarc and you feel strongly that this should
be the wa
> Done. The console output of configure.py is also captured and shown in the
> details list of the installer.
Thanks. You just solved the only problem I have when I use your installer.
Bo
> > 1. Not all files have a common base dir (e.g. c:\file, d:\file), right?
>
> Right. But those could be treated as if they were /c/file /d/file (this
> is what is exactly done on cygwin, for example).
But the lyx file will not recognize them, right? What if the author
unpack the file again? H
Let us focus on one problem at a time.
> No, the lyx file is left unchanged. The script determines the common
> prefix of all files to embed and use that as the base dir.
1. Not all files have a common base dir (e.g. c:\file, d:\file), right?
2. How would you extract c:\file under linux?
3. H
> >
> > It is easy to see that
> >
> > 1. you can not embed out of tree files.
>
> This is not true. Have you tried the script?
I have not. Sorry. But how do you extract these files? Do you change
lyx file so that they can be embedded?
> > 2. you can not embed layout and class files
>
> If
> I can of course run the configure script during installation to let MiKTeX
> download it's packages. The only side effect would be that the user
> installing LyX also get the configuration data, while this may be a system
> administrator who only wants to install LyX. But that's probably not a b
> > This is very important. I think the easiest partial solution is to
> > run lyxc.exe instead of lyx.exe for the first time (when users select
> > 'run lyx' after the installation finishes).
> >
>
> Configuration is done for each user account, so that won't really work.
> It's not shared by all
> 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
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 exam
Hi, Richard,
Let us suppose that you have a bunch of existing .lyx files. To avoid
problems with out of tree files, let us assume that they all refer to
only files in or under the document directory. Using the current
implementation, when you 'save in bundled format' (shortcut for select
'save in
> I thought you wanted to allow things to unbundle to arbitrary locations? Or
> are you now just allowing them to update from such locations? I can't follow
> everything that's happened.
If you want the latest progress on this issue:
Still the same:
1. I allow arbitrary files to be embedded,
2.
On Fri, Apr 4, 2008 at 2:50 PM, José Matos <[EMAIL PROTECTED]> wrote:
> On Friday 04 April 2008 20:37:20 Bo Peng wrote:
> > I can compile the .lyx file on machine A but not on machine B which
> > has that file, but not the session file.
>
> You know that this is no
> I am proposing that this information should be made local to the machine
> where
> the file was created.
>
> Just to illustrate my point I propose that instead of this:
>
> What is the problem with this approach?
I can compile the .lyx file on machine A but not on machine B which
has that f
On Fri, Apr 4, 2008 at 1:37 PM, José Matos <[EMAIL PROTECTED]> wrote:
> On Friday 04 April 2008 15:18:58 Bo Peng wrote:
> > Open *any* version of lyx, insert anything like graphics, child
> > document, external, browse to /var/log/blah, save you lyx file. You
> > wil
> > This is my proposal, which can embed any file. The files will be in
> > the bundle, and if they are extracted, they can only be extracted to
> > the document directory.
>
> I am OK with that, if 'document directory' means 'a special directory
> that only belongs to this document'.
Great.
> No, your local files are in the directory structure and you add this
> whole structure to the svn repository.
This is exactly where I have problems. Basically, when you create a
.lyx file, and if you prepare to use the bundled feature, how do you
proceed? Do you create the extra file and direc
On Fri, Apr 4, 2008 at 10:40 AM, Jean-Marc Lasgouttes
<[EMAIL PROTECTED]> wrote:
> "Bo Peng" <[EMAIL PROTECTED]> writes:
>
> > Also about your uneasiness of embedding arbitrary files through
> > document->settings. Whatever embedding solution you c
> > But if lyx forbids, or make it very difficult, to make a file that can
> > be compiled anywhere, it is lyx' problem.
>
> You can put the files you want inside the bundle.
This is my proposal, which can embed any file. The files will be in
the bundle, and if they are extracted, they can only
> > I have agreed we should extract only to the document directory.
>
> Let me repeat that I think that a bundled LyX file should be actually
> a directory with files inside, something like
Whereas I dislike the 'should' word, I am happy that you are the first
one who provide your proposal in a
On Fri, Apr 4, 2008 at 9:28 AM, Bo Peng <[EMAIL PROTECTED]> wrote:
> > > Open *any* version of lyx, insert anything like graphics, child
> > > document, external, browse to /var/log/blah, save you lyx file. You
> > > will see /var/log/blah in your .lyx file.
> > Open *any* version of lyx, insert anything like graphics, child
> > document, external, browse to /var/log/blah, save you lyx file. You
> > will see /var/log/blah in your .lyx file.
>
> And? What kind of evil can we do from there?
Ask Jose. He insisted that I should not save absolute path
> You mean like when microsoft thought it would be nice to let people
> send exe files by e-mail and execute them by double clicking? The kind
> of feature that should not be a problem for anyone...
The key point is that 'you do not have to', because the current
implementation handles that bett
> I do not know such case. Could you, please, give me an example in lyx 1.5
> where this occurs?
Open *any* version of lyx, insert anything like graphics, child
document, external, browse to /var/log/blah, save you lyx file. You
will see /var/log/blah in your .lyx file.
Bo
> It does make sense to use the "user guide" as an example because we do not
> distribute only the user guide but all the directories, including those where
> the images are. There are no external links in the lyx documentation or else
> our users would not be able to use it.
The examples I g
> Since to me it does not make sense to compromise on the security issue the
> original file location is a bad idea.
I am repeating myself the fourth time. We have had these paths in our
.lyx file since lyx 1.5 (I have learned something from the
discussions) and nobody has ever said anything. I
> For me an embedded file is a file where the dependencies can be found
> inside. The zip file behaves as directory where all files are inside, with a
> tree structure of directories, if necessary.
>
> Once a file is inside it looses any reference to an external origin.
Please elaborate on h
> the problems I mentioned in the first message, a good solution to
> allow me to share different files from the same .lyx document.
Of course, this is 'share the same files from different .lyx document'
Bo
> Yes in the sense that sharing can be done without the reference to the
> initial file path. You are insisting on this feature although there are no
> known examples of this behaviour.
I have given several examples in this thread why access to out of tree
files are needed, and I have shown wh
> > As I have said, this information is relevant on more than one machines.
>
> In the use case that you gave this information is only relevant to you.
You have gone from not fixing the problem to denying the problem. At
least lyx user's guide refers to ../images/blah.png on every machine
it i
> > I want to share the same files across different lyx
> > documents, so I do not want to keep local copies. The link solution
> > was suggested but it does not really work.
>
> As I said it is extremely easy to create a file text like this:
>
> embbeded1 /path/to/embbeded1
> embbeded
> > However,
> >
> > 1. They can be there, maybe in gray color, to tell users where the
> > files are embedded.
>
> To be useful under your conditions this file needs to be changed. You can
> decide to use another source or during a reorganization its location may
> change.
In the current
> > If I accept that much, I still have to copy files around and modify
> > each and every copies if it needs to be modified. This is exactly the
> > thing I would like to avoid.
>
> This goal is independent of the next sentence.
Not exactly. I want to share the same files across different ly
> If you go that way, yes. But then it's unclear why you really need to know
> the original path, as Jose has been saying. The only possible reason would
> be to update from an external file, and there are other ways to do that,
> outside of LyX. Moreover, note that if all paths are downward from
With the 'write only to the document directory' policy, the embedding
of arbitrary file will at least do no harm. Whether or not we want
this feature is still subject to debate.
It appears to me that most developers want to have an at-home feeling
with external files, so I am proposing an 'Automat
On Thu, Apr 3, 2008 at 11:36 AM, José Matos <[EMAIL PROTECTED]> wrote:
> On Thursday 03 April 2008 16:57:36 Bo Peng wrote:
> > To unbundle, you have to know the original path, right?
>
> Only if it is not external, right? Because you said that we should not
> unbundle
> I don't disagree with this I am referring about your update external
> feature, that is the reason for you to retain the original file path, and
> that is what me and other don't want to.
> All the disagreement for my part comes from your proposal to keep the
> original file path.
To unbu
> The new problems embedding causes are security problems when these files
> are unbundled, as Andre has pointed out. And see my private message for an
> even worse scenario than his. As Andre said, here there be dragons, and even
> if we could solve these problems, would we be sure we'd solved th
> With all the due respect Bo, I know that you are competent python
> programmer. What you are proposing can be done in python without ever using
> the lyx gui.
Please, what I am proposing includes bundle-mode ending, which can NOT
be done without a GUI. Even for the easiest case that Richard
> > Note that novice users do not have to know these. They just click ok
> > without knowing what they are doing, and the mentioned problem will be
> > resolved.
> >
> >
> >
> As JMarc said, this is very dangerous. Much too dangerous.
What is *so dangerous* here? The result is that such files wil
> > I forgot to mention one important trick: if the files are there so
> > there is no need to overwrite, unbundling would succeed and they do
> > not have to be unbundled to the document directory. This is because we
> > compare file checksum before we extract.
> >
> So if the files are there and
> I guess I don't see this, quite. Sure, you can specify the the distant file
> when you choose it, but once it is embedded, the distant file has nothing to
> do with it. It can only be extracted to a subdirectory (if you're still
> doing a general unbundling, as opposed to selective unbundling, a
> I am not sure what happens on windows but on linux if you compress a file
> with an absolute path the archive program will drop the first / and extract
> the resulting files with a relative path. I think that this is sane and this
> what I would like lyx to do. Does that makes sense to you?
> Surely we can know better by parsing the latex output or else we are giving a
> free ride to all kind of files. That will be difficult to get rid later
> because of previous usage.
It is not that easy because you will have to run latex to get the log
file, which is not always the case. Also,
> > d1) never allow explicit embedding of anything above the bundle file.
> > There be dragons.
> >
> This is precisely the suggestion I made a while ago. And IF you do this,
> then every other problem Bo mentioned with the "transparent embedding"
> solution can be solved. I won't detail the solut
> I'd simply drop that feature. There is no proper solution possible.
>
> Actually, when I think about it...
> Suppose I bundle a file with relative path
>
> "../../../../../../../../../etc/passwd"
>
> and open that file with root permissions in LyX.
If you sys admin does this, you should im
On Wed, Apr 2, 2008 at 5:23 PM, José Matos <[EMAIL PROTECTED]> wrote:
> On Wednesday 02 April 2008 22:43:57 Bo Peng wrote:
> > Actually, I know only one limitation (assuming others are bugs), and
> > this limitation exists from lyx 0.1. I mean, you simply cannot use a
&g
> >
> > _This_ surely won't ever work outside controlled enviroments.
> >
> >
> >
> Yes, I think that's precisely what he's trying to do. He wants to be able
> to have a single (say) image file that is embedded in multiple LyX files,
> referenced by absolute path, and have it be packed and unpacke
> First I note that the first alpha should not wait for this to be finished or
> the goals more or less set. I agree with you if the target is the first beta.
By alpha, we mean the major features are almost done, and we will turn
to bug-fixing mode. Totally rewrite embedding after alpha one doe
301 - 400 of 4033 matches
Mail list logo
