Re: The fourth embedding proposal from Abdel.
Bo Peng wrote: 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. That's your opinion :-) If two co-authors use different directory structure, I can not see how their bundled version can be the same. Then you still do not understand what I mean. I guess I was not clear enough... I understand that this is the way you want to go, but I am afraid that I am not convinced why the directory structure has to be changed. Embedding/bundling is a feature to help a user transfer his .lyx file from one machine to another, A proper directory structure and zip is enough for this. help users share the same .lyx file. That's a side advantage for me. The prime advantage is to define a portable LyX format. Bundling the pdf and/or ps, as suggested by Christian, even make sense to me. Simply by definition, the .lyx file itself should not be changed. Definition by who? This is not a sacro-saint goal IMO. If you are worried about privacy, security etc (give me a reason!), I don't. I just think my approach (combined with Edwin's) is simpler in terms of work flow and code complexity. Your approach needs an implementation at inset level and impose the directory structure of the first author to all co-author. My approached impose a standardized directory structure. an alias + session solution may be used, but that should be an additional feature, not part of embedding. OK, as I am not going to implement my proposal in any case and as I cannot of course ask you to implement it, that's the end of the story for me. I just wanted to offer my view of it but I am off with this subject now as I have other things to fix and I have basically zero part time. Cheers, Abdel.
Re: The fourth embedding proposal from Abdel.
Bo Peng [EMAIL PROTECTED] writes: I actually do not know how to handle so many proposals. Maybe I should wait until you guys reach an agreement? Just to add to the general puzzlement: I happened to play with apple's TextEdit (the default Mac OS X rtf editor) last friday. The files are .rtf file. Copy and paste an image. The file transparently gets a .rtfd extension, and it is actually a directory containing an rtf file and an image. Remove the image, and it is a plain rtf file again. No UI. Just works. JMarc
RE: The fourth embedding proposal from Abdel.
Bo Peng [EMAIL PROTECTED] writes: Maybe I should wait until you guys reach an agreement? i have the impression that us guys basically agree.
Re: The fourth embedding proposal from Abdel.
Bo Peng wrote: 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. That's your opinion :-) If two co-authors use different directory structure, I can not see how their bundled version can be the same. Then you still do not understand what I mean. I guess I was not clear enough... I understand that this is the way you want to go, but I am afraid that I am not convinced why the directory structure has to be changed. Embedding/bundling is a feature to help a user transfer his .lyx file from one machine to another, A proper directory structure and zip is enough for this. help users share the same .lyx file. That's a side advantage for me. The prime advantage is to define a "portable" LyX format. Bundling the pdf and/or ps, as suggested by Christian, even make sense to me. Simply by definition, the .lyx file itself should not be changed. Definition by who? This is not a sacro-saint goal IMO. If you are worried about privacy, security etc (give me a reason!), I don't. I just think my approach (combined with Edwin's) is simpler in terms of work flow and code complexity. Your approach needs an implementation at inset level and impose the directory structure of the first author to all co-author. My approached impose a standardized directory structure. an alias + session solution may be used, but that should be an additional feature, not part of embedding. OK, as I am not going to implement my proposal in any case and as I cannot of course ask you to implement it, that's the end of the story for me. I just wanted to offer my view of it but I am off with this subject now as I have other things to fix and I have basically zero part time. Cheers, Abdel.
Re: The fourth embedding proposal from Abdel.
"Bo Peng" <[EMAIL PROTECTED]> writes: > I actually do not know how to handle so many proposals. Maybe I should > wait until you guys reach an agreement? Just to add to the general puzzlement: I happened to play with apple's TextEdit (the default Mac OS X rtf editor) last friday. The files are .rtf file. Copy and paste an image. The file transparently gets a .rtfd extension, and it is actually a directory containing an rtf file and an image. Remove the image, and it is a plain rtf file again. No UI. Just works. JMarc
RE: The fourth embedding proposal from Abdel.
"Bo Peng" <[EMAIL PROTECTED]> writes: > Maybe I should wait until you guys reach an agreement? i have the impression that "us guys" basically agree.
Re: The fourth embedding proposal from Abdel.
Bo Peng wrote: 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. You are missing the point. My point is that once the document is organized for bundle, it will not change. and 2. backward compatibility, I don't understand that one. If you talk about losing the original filenames, yes that's a fact. And this is not a problem? This is not a problem for the external contributor, he is not interested on your file hierarchy, only you are. And this information is not lost for you of course, it is saved in the session info. This enables the two contributors to organize the file in any way they want in a contely different manner if they want. In a way, this is even more flexible than your solution. As I said, if the external contributor is interested in your file hierarchy, then you should discuss it and use a proper solution for that (using an SCM or simply zipping the directory). 3. change of user's input. Right, but as I said, IU view the bundling business only as a transportable LyX file. And if you look back at my original proposal, the user won't loose anything if the original embedded file paths are saved in the session. So this is again not a problem to you? Right. I mean, if a user craftes a beautiful directory structure, for example bib, figure_chap1, figure_chap2, pack it and send it to another machine. When he unpacks the file and sees changed insets and directory structure, will he be happy? Did you miss the merge back part of my proposal? I, as a user, prefer to first view the change before accepting them. So no problem here as well. On the other machine, the session file is not there. Even on the same machine, the session file can get lost. If it is lost because the user erased it then he is on his own. Basically, why do you want to separate the filename information to a session file? Alleluia! :-) I mean, why the KISS structure is the only rightful structure a user can have? There are millions of reasons a user wants his own structure. And they should be able to keep their structure. I am distinguishing on purpose the two things. This KISS structure is _only_ about the bundle not a general way to organize your document of course. Not an another machine, not on the same machine without merging. Exactly. I don't follow you, I was talking about limited editing _within_ LyX. LateX won't call LyX's lfuns AFAIK ;-) Of course the user will still be free to go the temp directory and edit the embedded files if he really wants to. That'd be an expert user. When lyx export to latex, the existing latex output may not work when the files are in the temporary directory. ??? We do that kind of things all the time with the converter cache... Abdel.
Re: The fourth embedding proposal from Abdel.
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 different directory structure, I can not see how their bundled version can be the same. I understand that this is the way you want to go, but I am afraid that I am not convinced why the directory structure has to be changed. Embedding/bundling is a feature to help a user transfer his .lyx file from one machine to another, help users share the same .lyx file. Simply by definition, the .lyx file itself should not be changed. If you are worried about privacy, security etc (give me a reason!), an alias + session solution may be used, but that should be an additional feature, not part of embedding. Cheers, Bo
Re: The fourth embedding proposal from Abdel.
Bo Peng wrote: 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. You are missing the point. My point is that once the document is organized for bundle, it will not change. and 2. backward compatibility, I don't understand that one. If you talk about losing the original filenames, yes that's a fact. And this is not a problem? This is not a problem for the external contributor, he is not interested on your file hierarchy, only you are. And this information is not lost for you of course, it is saved in the session info. This enables the two contributors to organize the file in any way they want in a contely different manner if they want. In a way, this is even more flexible than your solution. As I said, if the external contributor is interested in your file hierarchy, then you should discuss it and use a proper solution for that (using an SCM or simply zipping the directory). 3. change of user's input. Right, but as I said, IU view the bundling business only as a transportable LyX file. And if you look back at my original proposal, the user won't loose anything if the original embedded file paths are saved in the session. So this is again not a problem to you? Right. I mean, if a user craftes a beautiful directory structure, for example bib, figure_chap1, figure_chap2, pack it and send it to another machine. When he unpacks the file and sees changed insets and directory structure, will he be happy? Did you miss the "merge back" part of my proposal? I, as a user, prefer to first view the change before accepting them. So no problem here as well. On the other machine, the session file is not there. Even on the same machine, the session file can get lost. If it is lost because the user erased it then he is on his own. Basically, why do you want to separate the filename information to a session file? Alleluia! :-) I mean, why the KISS structure is the only rightful structure a user can have? There are millions of reasons a user wants his own structure. And they should be able to keep their structure. I am distinguishing on purpose the two things. This KISS structure is _only_ about the bundle not a general way to organize your document of course. Not an another machine, not on the same machine without merging. Exactly. I don't follow you, I was talking about limited editing _within_ LyX. LateX won't call LyX's lfuns AFAIK ;-) Of course the user will still be free to go the temp directory and edit the embedded files if he really wants to. That'd be an expert user. When lyx export to latex, the existing latex output may not work when the files are in the temporary directory. ??? We do that kind of things all the time with the converter cache... Abdel.
Re: The fourth embedding proposal from Abdel.
> 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 different directory structure, I can not see how their bundled version can be the same. I understand that this is the way you want to go, but I am afraid that I am not convinced why the directory structure has to be changed. Embedding/bundling is a feature to help a user transfer his .lyx file from one machine to another, help users share the same .lyx file. Simply by definition, the .lyx file itself should not be changed. If you are worried about privacy, security etc (give me a reason!), an alias + session solution may be used, but that should be an additional feature, not part of embedding. Cheers, Bo
Re: The fourth embedding proposal from Abdel.
Bo Peng wrote: I actually do not know how to handle so many proposals. Maybe I should wait until you guys reach an agreement? another one: 1. bundling creates a zip whereto all the files are copied (as in abdel's 2.) and files loose their original reference. 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 it replaces the one in the bundle (gets copied to the tmpdir). adding a graphics works the same 2. we add a save as... for embedded objects in bundled mode in case people want to extract individual components 3. we add a unpack in directory... for the whole package in case people like to do that and leave the file management to them in that case
Re: The fourth embedding proposal from Abdel.
On Fri, 11 Apr 2008, Bo Peng wrote: I actually do not know how to handle so many proposals. Maybe I should wait until you guys reach an agreement? Perhaps it would help to describe the basic problem(s)? (As a temporary break from discussing solutions) If it's clear what the problems are, it then ought to be quick to concisely describe them. If not, perhaps it helps discussing the problem and the basics of what you and others want to achieve? /Christian PS. Three thoughts regarding the proposal: * Perhaps it would be good to optionally include the output, e.g. PDFs. If the recipient of the bundle for some reason is unable to build, he can still see what it ought to look like. And make changes/comments. * Along that line, maybe there are cases where the recipient only cares about seeing the output, and being able to modify or comment. In this case, the bundle would just need to contain the primary .lyx-file(s) and some kind of output. * If the .lyx-file is named 'content.lyx', how will it work with a multi-part document? To complicate matter further, I did my thesis as a multi-part document where I also could compile the parts separately. Would this still be possible based on a bundle? -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: The fourth embedding proposal from Abdel.
Bo Peng wrote: 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 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 a self contained directory, the .lyx file will _not_ change. and 'merge' them when you get it back. Other than your obsession to put them in a folder, what are the real benefits? I am not talking about out of tree files, just some figure.png in the same directory as filename.lyx. The benefit is that the users sees that this file is referenced in the .lyx file. If the user wants to bundle manually, he can just do it easily. Besides, this is also about 'standardization' and KISS. I don't think it is a big drawback to force the image to go in this subdirectory. 3-a) He only want to touch at the text contents. This looks a lot like my bundle-editing mode, but how do you limit users to 'touch at the text contents'? We can disable the relevant LFUN if the file is globally set as bundled. There is exactly one boolean to take care of, similar to the read-only flag. Also, this will not happen without touching inset related code, which will certainly displease Richard. I don't think so. The inset code does not need to be touched, only the LFUN status needs to check for this boolean flag, that's all. I actually do not know how to handle so many proposals. Maybe I should wait until you guys reach an agreement? Eventually things will converge. I just outlined a possible scenario, I am of course not saying this is the only one way to go :-) Abdel.
Re: The fourth embedding proposal from Abdel.
Edwin Leuven wrote: Bo Peng wrote: I actually do not know how to handle so many proposals. Maybe I should wait until you guys reach an agreement? another one: 1. bundling creates a zip whereto all the files are copied (as in abdel's 2.) and files loose their original reference. 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 it replaces the one in the bundle (gets copied to the tmpdir). adding a graphics works the same 2. we add a save as... for embedded objects in bundled mode in case people want to extract individual components 3. we add a unpack in directory... for the whole package in case people like to do that and leave the file management to them in that case That could be simpler than my approach indeed. Abdel.
Re: The fourth embedding proposal from Abdel.
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 it replaces the one in the bundle (gets copied to the tmpdir). adding a graphics works the same 2. we add a save as... for embedded objects in bundled mode in case people want to extract individual components Are you aware of that this is indeed what I am doing? You are describing my bundle-editing mode, update from external file, and extract. Just that, in addition to Abdel's 'limit to text editing' mode, it is working in almost all conditions. 3. we add a unpack in directory... for the whole package in case people like to do that and leave the file management to them in that case This is my 'unbundle' method, exactly 'in case' when people would like to unbundle. Cheers, Bo
Re: The fourth embedding proposal from Abdel.
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 a self contained directory, the .lyx file will _not_ change. No. You extract [tmpdir]filenamedir.lyxdir/embed from the bundle to $DOC_DIR/filename.embed. (Or you had a typo?) and 'merge' them when you get it back. Other than your obsession to put them in a folder, what are the real benefits? I am not talking about out of tree files, just some figure.png in the same directory as filename.lyx. The benefit is that the users sees that this file is referenced in the .lyx file. If the user wants to bundle manually, he can just do it easily. Besides, this is also about 'standardization' and KISS. I don't think it is a big drawback to force the image to go in this subdirectory. You might have a point about 'standardization' (who ask you to?) but I would disagree that your method is simpler. To the users 1. You are forcing users to use a specific directory structure because *you* think it is best for them. 2. When a users inserted /path/to/a, you (at least Richard) force users to update it in /path/to/blah/blah/a. 3. You creates another .lyx format during bundling but only allow partial conversion between them. 4. You disallow sharing of external files between different .lyx document, because they do not need to? 5. You (Richard actually) give users three choices to open a .lyx file, filename.lyz, filename.lyxdir (a directory?), filename.lyxdir/content.lyx with subtle differences between them. I mean, during the two week discussion, I was criticized for 1. keeping filename in .lyx file 2. bundle and unbundle in place but nodody told me why exactly this is bad except that I am not using a KISS directory structure. When I told them 1, 2, 3, 4, 5 why their proposal is not practical, suddenly all the arguments about backward compatibility, user experience change failed. The answers I got were 'I (or users) do not care about these' and 'we are not talking about implementation details', 'you should think of a way to solve it', or simply 'you are being annoying'. I will stop complaining. I will just say that I *do not* see any benefit of moving files around, and I do see a lot of user confusion and code complexity there. 3-a) He only want to touch at the text contents. This looks a lot like my bundle-editing mode, but how do you limit users to 'touch at the text contents'? We can disable the relevant LFUN if the file is globally set as bundled. There is exactly one boolean to take care of, similar to the read-only flag. OK. At least it might work. Also, this will not happen without touching inset related code, which will certainly displease Richard. I don't think so. The inset code does not need to be touched, only the LFUN status needs to check for this boolean flag, that's all. No. The edit button will not work. Some latex output may be in danger because the external file does not exist. The file monitor code may break. If you study my code, a full bundle-editing implementation is actually easier than yours. Eventually things will converge. I just outlined a possible scenario, I am of course not saying this is the only one way to go :-) Hopefully. I do not see any sign of it. Bo
Re: The fourth embedding proposal from Abdel.
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 implementation will not be in the way at all. Remember, I had been told that 'I' should change my working habit to adapt to the KISS structure. As a matter if fact, the core value of the current implementation is that it assures backward compatibility to file format, existing files and existing user behaviors, and is not in the way of however users would like to organize their files. Cheers, Bo
Re: The fourth embedding proposal from Abdel.
Bo Peng wrote: 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 a self contained directory, the .lyx file will _not_ change. 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. You might have a point about 'standardization' (who ask you to?) but I would disagree that your method is simpler. To the users 1. You are forcing users to use a specific directory structure because *you* think it is best for them. 2. When a users inserted /path/to/a, you (at least Richard) force users to update it in /path/to/blah/blah/a. 3. You creates another .lyx format during bundling but only allow partial conversion between them. 4. You disallow sharing of external files between different .lyx document, because they do not need to? 5. You (Richard actually) give users three choices to open a .lyx file, Yes. filename.lyz, Yes. filename.lyxdir (a directory?), No. This one should be hidden in the temp directory. filename.lyxdir/content.lyx with subtle differences between them. No. Ditto. I mean, during the two week discussion, I was criticized for 1. keeping filename in .lyx file 2. bundle and unbundle in place but nodody told me why exactly this is bad except that I am not using a KISS directory structure. When I told them 1, 2, 3, 4, 5 why their proposal is not practical, suddenly all the arguments about backward compatibility, user experience change failed. The answers I got were 'I (or users) do not care about these' and 'we are not talking about implementation details', 'you should think of a way to solve it', or simply 'you are being annoying'. Well, you asked me questions and I tried to answer with my idea of would things work for me, nothing more. I will stop complaining. I will just say that I *do not* see any benefit of moving files around, Is there any drawbacks? Moving file is cheap on most systems and with my proposal the moving would only happen following a user action. By definition we are not limited by time constraints in this case. and I do see a lot of user confusion and code complexity there. Well, I've just given my opinion, that's all. Take it as such. Also, this will not happen without touching inset related code, which will certainly displease Richard. I don't think so. The inset code does not need to be touched, only the LFUN status needs to check for this boolean flag, that's all. No. The edit button will not work. Some latex output may be in danger because the external file does not exist. I don't understand, the files are guaranted to exist because we made sure to copy them at the first place. The file monitor code may break. If you study my code, a full bundle-editing implementation is actually easier than yours. I admit I didn't read much this code. Abdel.
Re: The fourth embedding proposal from Abdel.
Bo Peng wrote: Are you aware of that this is indeed what I am doing? so why the: 1. embed this file in the graphics dialog 2. the embedded files in the document dialog 3. the updating of embedded files when something changes outside? 4. the smart extracting of embedded files?
Re: The fourth embedding proposal from Abdel.
Bo Peng wrote: 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? Oh but I do. If you remember I said that the best practice for collaboration is to use a proper directory structure and an SCM. This bundling business is only interesting to me as a one-shot contribution, this is just about a portable LyX document. Collaboration isn't about everyone working as he wants, it's about agreing to a directory structure and stick to it IMHO. You can create a directory, put all figures inside it. The current implementation will not be in the way at all. Remember, I had been told that 'I' should change my working habit to adapt to the KISS structure. As a matter if fact, the core value of the current implementation is that it assures backward compatibility to file format, Mine too. Except for the 'bundle' flag. existing files and existing user behaviors, Mine too. and is not in the way of however users would like to organize their files. Those people don't (or should not) need this bundled format for collaboration. This is I think the core of the incomprehension: I don't see bundling as a way to facilitate continuous collaboration. I see bundling as a way to easily send a compilable document. Anything else is just sugar and not strictly necessary IMHO. Abdel.
Re: The fourth embedding proposal from Abdel.
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?), No. This one should be hidden in the temp directory. This is why I liked your proposal much better than Richard's. Well, you asked me questions and I tried to answer with my idea of would things work for me, nothing more. Sorry, some points did not fit your proposal. :-) Is there any drawbacks? Moving file is cheap on most systems and with my proposal the moving would only happen following a user action. By definition we are not limited by time constraints in this case. The drawbacks are 1. code complicity because the insets need to be changed, and 2. backward compatibility, 3. change of user's input. I mean, if a user craftes a beautiful directory structure, for example bib, figure_chap1, figure_chap2, pack it and send it to another machine. When he unpacks the file and sees changed insets and directory structure, will he be happy? I mean, why the KISS structure is the only rightful structure a user can have? There are millions of reasons a user wants his own structure. Well, I've just given my opinion, that's all. Take it as such. I appreciate that. No. The edit button will not work. Some latex output may be in danger because the external file does not exist. I don't understand, the files are guaranted to exist because we made sure to copy them at the first place. I am talking about your limited bundle-editing mode where you kept all files in the temporary directory, where the insets are unaware of this fact. break. If you study my code, a full bundle-editing implementation is actually easier than yours. I admit I didn't read much this code. The idea is that the insets know where the files are and tell others so, so the changes are limited to these insets. Cheers, Bo
Re: The fourth embedding proposal from Abdel.
Bo Peng wrote: 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? 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. Is there any drawbacks? Moving file is cheap on most systems and with my proposal the moving would only happen following a user action. By definition we are not limited by time constraints in this case. The drawbacks are 1. code complicity because the insets need to be changed, Not really as most of the copying file changing can be done externally with a python script. So the code complexity is basically zero. and 2. backward compatibility, I don't understand that one. If you talk about losing the original filenames, yes that's a fact. 3. change of user's input. Right, but as I said, IU view the bundling business only as a transportable LyX file. And if you look back at my original proposal, the user won't loose anything if the original embedded file paths are saved in the session. I mean, if a user craftes a beautiful directory structure, for example bib, figure_chap1, figure_chap2, pack it and send it to another machine. When he unpacks the file and sees changed insets and directory structure, will he be happy? Did you miss the merge back part of my proposal? I, as a user, prefer to first view the change before accepting them. So no problem here as well. I mean, why the KISS structure is the only rightful structure a user can have? There are millions of reasons a user wants his own structure. And they should be able to keep their structure. I am distinguishing on purpose the two things. This KISS structure is _only_ about the bundle not a general way to organize your document of course. No. The edit button will not work. Some latex output may be in danger because the external file does not exist. I don't understand, the files are guaranted to exist because we made sure to copy them at the first place. I am talking about your limited bundle-editing mode where you kept all files in the temporary directory, where the insets are unaware of this fact. I don't follow you, I was talking about limited editing _within_ LyX. LateX won't call LyX's lfuns AFAIK ;-) Of course the user will still be free to go the temp directory and edit the embedded files if he really wants to. That'd be an expert user. Abdel.
Re: The fourth embedding proposal from Abdel.
Bo Peng wrote: 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 be in the same directory). This bundle creation was done in two steps: a) create a [tmpdir]/filenamedir.lyxdir/ directory b) copy filename.lyx to [tmpdir]/filename.lyxdir/content.lyx c) copy layout (if not standard) and biblio to [tmpdir]/filenamedir.lyxdir/embed/ d) copy referenced files to [tmpdir]/filename.lyxdir/embed/ e) modify [tmpdir]/filenamedir.lyxdir/content.lyx so that file reference point to the corresponding files in [tmpdir]/filenamedir.lyxdir/embed/. The session info should keep a trace of the original referenced file paths. f) zip the directory filenamedir.lyxdir/ into filenamedir.lyz Just an additional precision here WRT code complexity. Actions a) to f) can be done via an external script. Abdel.
Re: The fourth embedding proposal from Abdel.
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. The drawbacks are 1. code complicity because the insets need to be changed, Not really as most of the copying file changing can be done externally with a python script. So the code complexity is basically zero. OK. and 2. backward compatibility, I don't understand that one. If you talk about losing the original filenames, yes that's a fact. And this is not a problem? 3. change of user's input. Right, but as I said, IU view the bundling business only as a transportable LyX file. And if you look back at my original proposal, the user won't loose anything if the original embedded file paths are saved in the session. So this is again not a problem to you? I mean, if a user craftes a beautiful directory structure, for example bib, figure_chap1, figure_chap2, pack it and send it to another machine. When he unpacks the file and sees changed insets and directory structure, will he be happy? Did you miss the merge back part of my proposal? I, as a user, prefer to first view the change before accepting them. So no problem here as well. On the other machine, the session file is not there. Even on the same machine, the session file can get lost. Basically, why do you want to separate the filename information to a session file? I mean, why the KISS structure is the only rightful structure a user can have? There are millions of reasons a user wants his own structure. And they should be able to keep their structure. I am distinguishing on purpose the two things. This KISS structure is _only_ about the bundle not a general way to organize your document of course. Not an another machine, not on the same machine without merging. I don't follow you, I was talking about limited editing _within_ LyX. LateX won't call LyX's lfuns AFAIK ;-) Of course the user will still be free to go the temp directory and edit the embedded files if he really wants to. That'd be an expert user. When lyx export to latex, the existing latex output may not work when the files are in the temporary directory. Bo
Re: The fourth embedding proposal from Abdel.
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 'is there any benefit', you answered is there any drawback, and you later on agreed on two drawbacks, which you do not really care. The problem is that I care about these problems. Your approach complicates the problem quite a bit, for example 1. You have to merge a file, with the help from a session file, on the same machine 2. The unbundled file is different on another machine, and on that machine, you can not merge them even if you have your bundled and unbundled files. Note that you may be working on different machines. 3. The session implementation may not be as easy as you imagine. For example, if the document is changed to filename_rev1.lyx, its session information can not be used any more. Basically speaking, I do not understand *why* you would like to change what users have, and *why* you would like to store some filename information that has always been saved with lyx. Cheers, Bo
Re: The fourth embedding proposal from Abdel.
and *why* you would like to store some filename information that has always been saved with lyx. store should be 'throw away'. Bo
Re: The fourth embedding proposal from Abdel.
Abdelrazak Younes wrote: That could be simpler than my approach indeed. yes, simple and sufficient
Re: The fourth embedding proposal from Abdel.
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
Re: The fourth embedding proposal from Abdel.
Bo Peng wrote: I actually do not know how to handle so many proposals. Maybe I should wait until you guys reach an agreement? another one: 1. bundling creates a zip whereto all the files are copied (as in abdel's 2.) and files loose their original reference. 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 it replaces the one in the bundle (gets copied to the tmpdir). adding a graphics works the same 2. we add a "save as..." for embedded objects in bundled mode in case people want to extract individual components 3. we add a "unpack in directory..." for the whole package in case people like to do that and leave the file management to them in that case
Re: The fourth embedding proposal from Abdel.
On Fri, 11 Apr 2008, Bo Peng wrote: I actually do not know how to handle so many proposals. Maybe I should wait until you guys reach an agreement? Perhaps it would help to describe the basic problem(s)? (As a temporary break from discussing solutions) If it's clear what the problems are, it then ought to be quick to concisely describe them. If not, perhaps it helps discussing the problem and the basics of what you and others want to achieve? /Christian PS. Three thoughts regarding the proposal: * Perhaps it would be good to optionally include the output, e.g. PDFs. If the recipient of the bundle for some reason is unable to build, he can still see what it ought to look like. And make changes/comments. * Along that line, maybe there are cases where the recipient only cares about seeing the output, and being able to modify or comment. In this case, the bundle would just need to contain the primary .lyx-file(s) and some kind of output. * If the .lyx-file is named 'content.lyx', how will it work with a multi-part document? To complicate matter further, I did my thesis as a multi-part document where I also could compile the parts separately. Would this still be possible based on a bundle? -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: The fourth embedding proposal from Abdel.
Bo Peng wrote: 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 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 a self contained directory, the .lyx file will _not_ change. and 'merge' them when you get it back. Other than your obsession to put them in a folder, what are the real benefits? I am not talking about out of tree files, just some figure.png in the same directory as filename.lyx. The benefit is that the users sees that this file is referenced in the .lyx file. If the user wants to bundle manually, he can just do it easily. Besides, this is also about 'standardization' and KISS. I don't think it is a big drawback to force the image to go in this subdirectory. 3-a) He only want to touch at the text contents. This looks a lot like my bundle-editing mode, but how do you limit users to 'touch at the text contents'? We can disable the relevant LFUN if the file is globally set as "bundled". There is exactly one boolean to take care of, similar to the read-only flag. Also, this will not happen without touching inset related code, which will certainly displease Richard. I don't think so. The inset code does not need to be touched, only the LFUN status needs to check for this boolean flag, that's all. I actually do not know how to handle so many proposals. Maybe I should wait until you guys reach an agreement? Eventually things will converge. I just outlined a possible scenario, I am of course not saying this is the only one way to go :-) Abdel.
Re: The fourth embedding proposal from Abdel.
Edwin Leuven wrote: Bo Peng wrote: I actually do not know how to handle so many proposals. Maybe I should wait until you guys reach an agreement? another one: 1. bundling creates a zip whereto all the files are copied (as in abdel's 2.) and files loose their original reference. 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 it replaces the one in the bundle (gets copied to the tmpdir). adding a graphics works the same 2. we add a "save as..." for embedded objects in bundled mode in case people want to extract individual components 3. we add a "unpack in directory..." for the whole package in case people like to do that and leave the file management to them in that case That could be simpler than my approach indeed. Abdel.
Re: The fourth embedding proposal from Abdel.
> 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 it replaces the one in the bundle (gets copied > to the tmpdir). adding a graphics works the same > > 2. we add a "save as..." for embedded objects in bundled mode in case > people want to extract individual components Are you aware of that this is indeed what I am doing? You are describing my bundle-editing mode, update from external file, and extract. Just that, in addition to Abdel's 'limit to text editing' mode, it is working in almost all conditions. > 3. we add a "unpack in directory..." for the whole package in case people > like to do that and leave the file management to them in that case This is my 'unbundle' method, exactly 'in case' when people would like to unbundle. Cheers, Bo
Re: The fourth embedding proposal from Abdel.
> > 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 a self contained directory, the .lyx file will > _not_ change. No. You extract [tmpdir]filenamedir.lyxdir/embed from the bundle to $DOC_DIR/filename.embed. (Or you had a typo?) > > and 'merge' them when > > you get it back. Other than your obsession to put them in a folder, > > what are the real benefits? I am not talking about out of tree files, > > just some figure.png in the same directory as filename.lyx. > > > > The benefit is that the users sees that this file is referenced in the .lyx > file. If the user wants to bundle manually, he can just do it easily. > Besides, this is also about 'standardization' and KISS. I don't think it is > a big drawback to force the image to go in this subdirectory. You might have a point about 'standardization' (who ask you to?) but I would disagree that your method is simpler. To the users 1. You are forcing users to use a specific directory structure because *you* think it is best for them. 2. When a users inserted /path/to/a, you (at least Richard) force users to update it in /path/to/blah/blah/a. 3. You creates another .lyx format during bundling but only allow partial conversion between them. 4. You disallow sharing of external files between different .lyx document, because they do not need to? 5. You (Richard actually) give users three choices to open a .lyx file, filename.lyz, filename.lyxdir (a directory?), filename.lyxdir/content.lyx with subtle differences between them. I mean, during the two week discussion, I was criticized for 1. keeping filename in .lyx file 2. bundle and unbundle in place but nodody told me why exactly this is bad except that I am not using a KISS directory structure. When I told them 1, 2, 3, 4, 5 why their proposal is not practical, suddenly all the arguments about backward compatibility, user experience change failed. The answers I got were 'I (or users) do not care about these' and 'we are not talking about implementation details', 'you should think of a way to solve it', or simply 'you are being annoying'. I will stop complaining. I will just say that I *do not* see any benefit of moving files around, and I do see a lot of user confusion and code complexity there. > > > 3-a) He only want to touch at the text contents. > > > > > > > This looks a lot like my bundle-editing mode, but how do you limit > > users to 'touch at the text contents'? > > We can disable the relevant LFUN if the file is globally set as "bundled". > There is exactly one boolean to take care of, similar to the read-only flag. OK. At least it might work. > > Also, this will not happen without touching inset related code, which > > will certainly displease Richard. > > I don't think so. The inset code does not need to be touched, only the LFUN > status needs to check for this boolean flag, that's all. No. The edit button will not work. Some latex output may be in danger because the external file does not exist. The file monitor code may break. If you study my code, a full bundle-editing implementation is actually easier than yours. > > Eventually things will converge. I just outlined a possible scenario, I am > of course not saying this is the only one way to go :-) Hopefully. I do not see any sign of it. Bo
Re: The fourth embedding proposal from Abdel.
> 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 implementation will not be in the way at all. Remember, I had been told that 'I' should change my working habit to adapt to the KISS structure. As a matter if fact, the core value of the current implementation is that it assures backward compatibility to file format, existing files and existing user behaviors, and is not in the way of however users would like to organize their files. Cheers, Bo
Re: The fourth embedding proposal from Abdel.
Bo Peng wrote: 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 a self contained directory, the .lyx file will _not_ change. 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. You might have a point about 'standardization' (who ask you to?) but I would disagree that your method is simpler. To the users 1. You are forcing users to use a specific directory structure because *you* think it is best for them. 2. When a users inserted /path/to/a, you (at least Richard) force users to update it in /path/to/blah/blah/a. 3. You creates another .lyx format during bundling but only allow partial conversion between them. 4. You disallow sharing of external files between different .lyx document, because they do not need to? 5. You (Richard actually) give users three choices to open a .lyx file, Yes. filename.lyz, Yes. filename.lyxdir (a directory?), No. This one should be hidden in the temp directory. filename.lyxdir/content.lyx with subtle differences between them. No. Ditto. I mean, during the two week discussion, I was criticized for 1. keeping filename in .lyx file 2. bundle and unbundle in place but nodody told me why exactly this is bad except that I am not using a KISS directory structure. When I told them 1, 2, 3, 4, 5 why their proposal is not practical, suddenly all the arguments about backward compatibility, user experience change failed. The answers I got were 'I (or users) do not care about these' and 'we are not talking about implementation details', 'you should think of a way to solve it', or simply 'you are being annoying'. Well, you asked me questions and I tried to answer with my idea of would things work for me, nothing more. I will stop complaining. I will just say that I *do not* see any benefit of moving files around, Is there any drawbacks? Moving file is cheap on most systems and with my proposal the moving would only happen following a user action. By definition we are not limited by time constraints in this case. and I do see a lot of user confusion and code complexity there. Well, I've just given my opinion, that's all. Take it as such. Also, this will not happen without touching inset related code, which will certainly displease Richard. I don't think so. The inset code does not need to be touched, only the LFUN status needs to check for this boolean flag, that's all. No. The edit button will not work. Some latex output may be in danger because the external file does not exist. I don't understand, the files are guaranted to exist because we made sure to copy them at the first place. The file monitor code may break. If you study my code, a full bundle-editing implementation is actually easier than yours. I admit I didn't read much this code. Abdel.
Re: The fourth embedding proposal from Abdel.
Bo Peng wrote: Are you aware of that this is indeed what I am doing? so why the: 1. embed this file in the graphics dialog 2. the embedded files in the document dialog 3. the updating of embedded files when something changes outside? 4. the smart extracting of embedded files?
Re: The fourth embedding proposal from Abdel.
Bo Peng wrote: 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? Oh but I do. If you remember I said that the best practice for collaboration is to use a proper directory structure and an SCM. This bundling business is only interesting to me as a one-shot contribution, this is just about a portable LyX document. Collaboration isn't about everyone working as he wants, it's about agreing to a directory structure and stick to it IMHO. You can create a directory, put all figures inside it. The current implementation will not be in the way at all. Remember, I had been told that 'I' should change my working habit to adapt to the KISS structure. As a matter if fact, the core value of the current implementation is that it assures backward compatibility to file format, Mine too. Except for the 'bundle' flag. existing files and existing user behaviors, Mine too. and is not in the way of however users would like to organize their files. Those people don't (or should not) need this bundled format for collaboration. This is I think the core of the incomprehension: I don't see bundling as a way to facilitate continuous collaboration. I see bundling as a way to easily send a compilable document. Anything else is just sugar and not strictly necessary IMHO. Abdel.
Re: The fourth embedding proposal from Abdel.
> > 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?), > > > No. This one should be hidden in the temp directory. This is why I liked your proposal much better than Richard's. > Well, you asked me questions and I tried to answer with my idea of would > things work for me, nothing more. Sorry, some points did not fit your proposal. :-) > Is there any drawbacks? Moving file is cheap on most systems and with my > proposal the moving would only happen following a user action. By definition > we are not limited by time constraints in this case. The drawbacks are 1. code complicity because the insets need to be changed, and 2. backward compatibility, 3. change of user's input. I mean, if a user craftes a beautiful directory structure, for example bib, figure_chap1, figure_chap2, pack it and send it to another machine. When he unpacks the file and sees changed insets and directory structure, will he be happy? I mean, why the KISS structure is the only rightful structure a user can have? There are millions of reasons a user wants his own structure. > Well, I've just given my opinion, that's all. Take it as such. I appreciate that. > > No. The edit button will not work. Some latex output may be in danger > > because the external file does not exist. > > > > I don't understand, the files are guaranted to exist because we made sure > to copy them at the first place. I am talking about your limited bundle-editing mode where you kept all files in the temporary directory, where the insets are unaware of this fact. > > break. If you study my code, a full bundle-editing implementation is > > actually easier than yours. > > > > > I admit I didn't read much this code. The idea is that the insets know where the files are and tell others so, so the changes are limited to these insets. Cheers, Bo
Re: The fourth embedding proposal from Abdel.
Bo Peng wrote: 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? 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. Is there any drawbacks? Moving file is cheap on most systems and with my proposal the moving would only happen following a user action. By definition we are not limited by time constraints in this case. The drawbacks are 1. code complicity because the insets need to be changed, Not really as most of the copying file changing can be done externally with a python script. So the code complexity is basically zero. and 2. backward compatibility, I don't understand that one. If you talk about losing the original filenames, yes that's a fact. 3. change of user's input. Right, but as I said, IU view the bundling business only as a transportable LyX file. And if you look back at my original proposal, the user won't loose anything if the original embedded file paths are saved in the session. I mean, if a user craftes a beautiful directory structure, for example bib, figure_chap1, figure_chap2, pack it and send it to another machine. When he unpacks the file and sees changed insets and directory structure, will he be happy? Did you miss the "merge back" part of my proposal? I, as a user, prefer to first view the change before accepting them. So no problem here as well. I mean, why the KISS structure is the only rightful structure a user can have? There are millions of reasons a user wants his own structure. And they should be able to keep their structure. I am distinguishing on purpose the two things. This KISS structure is _only_ about the bundle not a general way to organize your document of course. No. The edit button will not work. Some latex output may be in danger because the external file does not exist. I don't understand, the files are guaranted to exist because we made sure to copy them at the first place. I am talking about your limited bundle-editing mode where you kept all files in the temporary directory, where the insets are unaware of this fact. I don't follow you, I was talking about limited editing _within_ LyX. LateX won't call LyX's lfuns AFAIK ;-) Of course the user will still be free to go the temp directory and edit the embedded files if he really wants to. That'd be an expert user. Abdel.
Re: The fourth embedding proposal from Abdel.
Bo Peng wrote: 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 be in the same directory). This bundle creation was done in two steps: a) create a [tmpdir]/filenamedir.lyxdir/ directory b) copy filename.lyx to [tmpdir]/filename.lyxdir/content.lyx c) copy layout (if not standard) and biblio to [tmpdir]/filenamedir.lyxdir/embed/ d) copy referenced files to [tmpdir]/filename.lyxdir/embed/ e) modify [tmpdir]/filenamedir.lyxdir/content.lyx so that file reference point to the corresponding files in [tmpdir]/filenamedir.lyxdir/embed/. The session info should keep a trace of the original referenced file paths. f) zip the directory filenamedir.lyxdir/ into filenamedir.lyz Just an additional precision here WRT code complexity. Actions a) to f) can be done via an external script. Abdel.
Re: The fourth embedding proposal from Abdel.
> > 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. > > The drawbacks are 1. code complicity because the insets need to be > > changed, > > > Not really as most of the copying file changing can be done externally with > a python script. So the code complexity is basically zero. OK. > > and 2. backward compatibility, > > > I don't understand that one. If you talk about losing the original > filenames, yes that's a fact. And this is not a problem? > > 3. change of user's input. > > > Right, but as I said, IU view the bundling business only as a transportable > LyX file. And if you look back at my original proposal, the user won't loose > anything if the original embedded file paths are saved in the session. So this is again not a problem to you? > > I > > mean, if a user craftes a beautiful directory structure, for example > > bib, figure_chap1, figure_chap2, pack it and send it to another > > machine. When he unpacks the file and sees changed insets and > > directory structure, will he be happy? > > > Did you miss the "merge back" part of my proposal? I, as a user, prefer to > first view the change before accepting them. So no problem here as well. On the other machine, the session file is not there. Even on the same machine, the session file can get lost. Basically, why do you want to separate the filename information to a session file? > > I mean, why the KISS structure is the only rightful structure a user > > can have? There are millions of reasons a user wants his own > > structure. > > > And they should be able to keep their structure. I am distinguishing on > purpose the two things. This KISS structure is _only_ about the bundle not a > general way to organize your document of course. Not an another machine, not on the same machine without merging. > I don't follow you, I was talking about limited editing _within_ LyX. LateX > won't call LyX's lfuns AFAIK ;-) > Of course the user will still be free to go the temp directory and edit > the embedded files if he really wants to. That'd be an expert user. When lyx export to latex, the existing latex output may not work when the files are in the temporary directory. Bo
Re: The fourth embedding proposal from Abdel.
> 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 'is there any benefit', you answered "is there any drawback", and you later on agreed on two drawbacks, which you do not really care. The problem is that I care about these problems. Your approach complicates the problem quite a bit, for example 1. You have to merge a file, with the help from a session file, on the same machine 2. The unbundled file is different on another machine, and on that machine, you can not merge them even if you have your bundled and unbundled files. Note that you may be working on different machines. 3. The session implementation may not be as easy as you imagine. For example, if the document is changed to filename_rev1.lyx, its session information can not be used any more. Basically speaking, I do not understand *why* you would like to change what users have, and *why* you would like to store some filename information that has always been saved with lyx. Cheers, Bo
Re: The fourth embedding proposal from Abdel.
> and *why* you would like to store some filename > information that has always been saved with lyx. store should be 'throw away'. Bo
Re: The fourth embedding proposal from Abdel.
Abdelrazak Younes wrote: That could be simpler than my approach indeed. yes, simple and sufficient
Re: The fourth embedding proposal from Abdel.
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
Re: The fourth embedding proposal from Abdel.
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 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, and 'merge' them when you get it back. Other than your obsession to put them in a folder, what are the real benefits? I am not talking about out of tree files, just some figure.png in the same directory as filename.lyx. 3-a) He only want to touch at the text contents. This looks a lot like my bundle-editing mode, but how do you limit users to 'touch at the text contents'? Also, this will not happen without touching inset related code, which will certainly displease Richard. I actually do not know how to handle so many proposals. Maybe I should wait until you guys reach an agreement? Cheers, Bo
Re: The fourth embedding proposal from Abdel.
> 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 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, and 'merge' them when you get it back. Other than your obsession to put them in a folder, what are the real benefits? I am not talking about out of tree files, just some figure.png in the same directory as filename.lyx. > 3-a) He only want to touch at the text contents. This looks a lot like my bundle-editing mode, but how do you limit users to 'touch at the text contents'? Also, this will not happen without touching inset related code, which will certainly displease Richard. I actually do not know how to handle so many proposals. Maybe I should wait until you guys reach an agreement? Cheers, Bo
