Re: Summary to the individual embedding debate.

Bo Peng wrote: Well I think I do now but you're right, let's postpone this discussion until you get some more temper :-) Sorry for resuming (again!) the discussion. I was in a pretty good mode until you accused me of not listening to Richard carefully, which reminded me my frustrations in

Re: Summary to the individual embedding debate.

>> No. If this is the case, Richard should have put it to the wiki. > > I didn't read all the messages but I am pretty sure Richard said exactly > what I am saying, JMarc AFAIR. You may be right, but Richard did not put it in any of his summaries, nor did he put it in the wiki. If he had this idea

Re: Summary to the individual embedding debate.

Bo Peng wrote: Your agument is amazingly similar to Richard's "A world's simplest script can solve this". I will not argue here but I would remind you that LyX is used by many users, many of whom do not know how to write a script, or know such an advanced feature of svn. The KISS idea should be a

Re: Summary to the individual embedding debate.

>> Your agument is amazingly similar to Richard's "A world's simplest >> script can solve this". I will not argue here but I would remind you >> that LyX is used by many users, many of whom do not know how to write >> a script, or know such an advanced feature of svn. The KISS idea >> should be app

Re: Summary to the individual embedding debate.

Bo Peng wrote: Second, even if you (or someone else) insist on this issue, we are talking about diff friendly here, not svn. Svn doesn't really care if the file is text or binary. FYI you can configure svn to use any helper application besides diff. We could for example create a python script tha

Re: Summary to the individual embedding debate.

>> of my approach is >> that there is no bundled mode, and there is no unbundle. The file is >> continued to be svn friendly, and nobody would svn a compressed >> bundle. > > OK, replace 'bundled' with 'embedded' and you get the same result: there is > no need to be svn friendly, I mean at all. I

Re: Summary to the individual embedding debate.

Bo Peng wrote: I really don't understand why you insist on putting a bundled .lyx file into an SCM (svn). Either you use an scm or you use a bundled file, not both. If you use an SCM and receive a bundled file, unbundle it and put it in an SCM, as simple as that. There is absolutely no need to be

Re: Summary to the individual embedding debate.

On Wed, May 21, 2008 at 11:54 PM, Bo Peng <[EMAIL PROTECTED]> wrote: >> It seems as if we could probably even merge the diff if different sub >> files were changes. Still seems unsatisfying, as most likely in both >> zip/ar files the base .lyx file would have been changed. > > Never tried this. Thi

Re: Summary to the individual embedding debate.

> I really don't understand why you insist on putting a bundled .lyx file into > an SCM (svn). Either you use an scm or you use a bundled file, not both. If > you use an SCM and receive a bundled file, unbundle it and put it in an SCM, > as simple as that. There is absolutely no need to be SCM frie

Re: Summary to the individual embedding debate.

> Well diff -a somewhat informative, although very messy. I can clean > the diff of two zip -0 files as follows: No one will actually use zip -0. When compression is used, it is used to reduce file sizes. > $ diff -a shfiles{,2}.zip | strings | grep '^[<>]' > < top -n 1 | grep Cpu.s | grep

Re: Summary to the individual embedding debate.

John McCabe-Dansted wrote: On Wed, May 21, 2008 at 11:05 PM, Bo Peng <[EMAIL PROTECTED]> wrote: According to this, http://svn.haxx.se/users/archive-2008-03/0376.shtml svn handles binary diffs efficiently. I suspect that it would likewise handle zip -0 even more sensibly. Merging diffs may s

Re: Summary to the individual embedding debate.

On Wed, May 21, 2008 at 11:05 PM, Bo Peng <[EMAIL PROTECTED]> wrote: >> According to this, >> http://svn.haxx.se/users/archive-2008-03/0376.shtml >> svn handles binary diffs efficiently. I suspect that it would likewise >> handle zip -0 even more sensibly. Merging diffs may still be a problem. >

Re: Summary to the individual embedding debate.

> According to this, > http://svn.haxx.se/users/archive-2008-03/0376.shtml > svn handles binary diffs efficiently. I suspect that it would likewise > handle zip -0 even more sensibly. Merging diffs may still be a problem. I think the issue here is not only about efficiency, but also about usabil

Re: Summary to the individual embedding debate.

On Wed, May 14, 2008 at 11:57 PM, Bo Peng <[EMAIL PROTECTED]> wrote: > 2) The plain text file is more svn friendly, easier to work with for > tasks other than extracting external files. I do not really care about > index-generation applications. I also pointed out that this format is > more natura

Re: Summary to the individual embedding debate.

> It is nor a shell extension, just using a zip library to extract only > one file from the list. Practically, I do not see any advantage of doing that. OK. We can extract only filename.lyx to $TEMP_DIR to open it, but to open it, we 'need' an embedded layout file. Then graphic loaders 'need' a f

Re: Summary to the individual embedding debate.

"Bo Peng" <[EMAIL PROTECTED]> writes: > Thanks. I see the point now. By using some sort of shell extension, > LyX does not have to extract all files to open some of them. I guess > this is what you were trying to achieve with your directory-in-a-file > idea. It is nor a shell extension, just usin

Re: Summary to the individual embedding debate.

On Tue, May 20, 2008 at 5:01 PM, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote: > "Bo Peng" <[EMAIL PROTECTED]> writes: > >> I do not quite get it. Are we talking about base64 vs. zip? When you >> open both types of files, you need to extract embedded files first. >> After that, all the operations

Re: Summary to the individual embedding debate.

"Bo Peng" <[EMAIL PROTECTED]> writes: > I do not quite get it. Are we talking about base64 vs. zip? When you > open both types of files, you need to extract embedded files first. > After that, all the operations are the same. If you are comparing > between the base64 bundle, and the filename + dir

Re: Summary to the individual embedding debate.

> Sure but I think you miss two points: > - LyX does not read these files most of the time thanks to the converter > cache; and if it does it reads then asynchronously after the .lyx file is > loaded on screen. In effect this means that the user sees a much faster > loading time. > - most of the ti

Re: Summary to the individual embedding debate.

Andre Poenitz wrote: On Tue, May 20, 2008 at 10:00:56AM +0200, Abdelrazak Younes wrote: But Base64 blobs have the disctinct inconvenient that LyX will have to read all embedded files itself. This will kill the file loading time if we abuse such method. OK, we could organize the .lyx file so

Re: Summary to the individual embedding debate.

On Tue, May 20, 2008 at 10:06:25AM +0200, Abdelrazak Younes wrote: > Andre Poenitz wrote: >> Base64 blobs have the distict advantage of retaining the possibility to >> edit the .lyx file in a text editor - which I used to do quite often... >> > By the way, I know you are a shell guy but modern d

Re: Summary to the individual embedding debate.

On Tue, May 20, 2008 at 10:00:56AM +0200, Abdelrazak Younes wrote: > But Base64 blobs have the disctinct inconvenient that LyX will have to read > all embedded files itself. This will kill the file loading time if we abuse > such method. OK, we could organize the .lyx file so that all blobs are a

Re: Summary to the individual embedding debate.

Abdelrazak Younes wrote: Andre Poenitz wrote: Base64 blobs have the distict advantage of retaining the possibility to edit the .lyx file in a text editor - which I used to do quite often... But Base64 blobs have the disctinct inconvenient that LyX will have to read all embedded files itself.

Re: Summary to the individual embedding debate.

Andre Poenitz wrote: Base64 blobs have the distict advantage of retaining the possibility to edit the .lyx file in a text editor - which I used to do quite often... By the way, I know you are a shell guy but modern desktops allow in-zip file editing. This leverage a bit the cited advantage. O

Re: Summary to the individual embedding debate.

Andre Poenitz wrote: On Wed, May 14, 2008 at 06:11:17PM -0400, Richard Heck wrote: (ii) Bo packs everything into the LyX file using base64 encoding; I put the files in a subdirectory and then wrap the whole bundle into a zip file. But that's just a confusion, and there's no real difference

Re: Summary to the individual embedding debate.

> Speaking from a former life: In almost all cases I would have liked to > have fully embedded (i.e. "copied") graphics, drawings, code snippets > even if I used them in multiple .lyx files. A noteworthy exception would > have been the .bib files that continued to receive minor updates (mostly > sp

Re: Summary to the individual embedding debate.

On Mon, May 19, 2008 at 08:55:00AM -0400, rgheck wrote: > Of course. But the question is whether having the feature is worth the > clutter, especially if no-one will actually use the flexibility involved > with individual embedding. I still don't see the use case that requires > this. Speaking

Re: Summary to the individual embedding debate.

On Wed, May 14, 2008 at 06:11:17PM -0400, Richard Heck wrote: > (ii) Bo packs everything into the LyX file using base64 encoding; I put the > files in a subdirectory and then wrap the whole bundle into a zip file. > > But that's just a confusion, and there's no real difference here. First: I > OP

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

Bo Peng wrote: So, if a user turns off 'compression', will $TEMP_DIR/filename.lyxdir be moved to $DOC_DIR/filename.lyxdir? Unless such a directory exists, in which case it'll be moved to a new empty directory, just as on your proposal. But of course, if you think something else should hap

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

Joost Verburg wrote: rgheck wrote: All of this makes perfect sense if you understand the difference between bundling and wrapping. If you don't, then I'm sure it's very puzzling indeed. If it's even difficult to understand for developers, I'm afraid it is too complicated for most users. Woul

Re: A solid proposal, please! (Was: Summary to the individual embedding debate)

Bo Peng wrote: Well, let us start from the beginning. Hopefully at a level of design. :-) But I first would like to point out that designs dictate implementations. If I do not introduce a bundled mode, I can not use a zip format. I can not switch a file to binary format just because I insert an

Re: Summary to the individual embedding debate.

Andre Poenitz wrote: So there's really only one thing to discuss. That said, I'll try to clear up some confusions below. Approach one: individual embedding. 1) Each and every external file can be embedded individually, using an embed checkbox in related inset dialogs. 2) The embedded file

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

> * A wrapped bundle is a compressed archive of an unwrapped bundle, e.g. > zip-archive of an unwrapped bundle. > > Not sure it's the best, but I think having something like this in the > beginning of the description would help. Your understanding is correct. Because it is really bad to introduce

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

On Thu, 15 May 2008, rgheck wrote: Unless such a directory exists, in which case it'll be moved to a new empty directory, just as on your proposal. But of course, if you think something else should happen, it could. Now, when I turn on 'compression', what will happen to $DOC_DIR/filename.l

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

>> So, if a user turns off 'compression', will $TEMP_DIR/filename.lyxdir >> be moved to $DOC_DIR/filename.lyxdir? > > Unless such a directory exists, in which case it'll be moved to a new empty > directory, just as on your proposal. But of course, if you think something > else should happen, it cou

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

> If it's even difficult to understand for developers, I'm afraid it is too > complicated for most users. Would it not be sufficient to have a single > bundling mode? I agree. I wrote a long email comparing the designs of two approaches (in the thread 'A solid implementation'). My design may be mo

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

rgheck wrote: All of this makes perfect sense if you understand the difference between bundling and wrapping. If you don't, then I'm sure it's very puzzling indeed. If it's even difficult to understand for developers, I'm afraid it is too complicated for most users. Would it not be sufficient

Re: A solid proposal, please! (Was: Summary to the individual embedding debate)

Well, let us start from the beginning. Hopefully at a level of design. :-) But I first would like to point out that designs dictate implementations. If I do not introduce a bundled mode, I can not use a zip format. I can not switch a file to binary format just because I insert an embedded inset. A

Re: A solid proposal, please! (Was: Summary to the individual embedding debate)

Bo Peng wrote: I'm trying to concentrate on very general questions about how these two proposals work. The question, "Do you use zip or tar or base64?" is just not worth discussing at this point. ... Richard, We are both tired of this discussion. My proposal is solid. I can provide every

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

Bo Peng wrote: It depends upon whether the file is bundled or also wrapped. If the file is just bundled, then there's just $DOC_DIR/filename.lyxdir. So, if a user turns off 'compression', will $TEMP_DIR/filename.lyxdir be moved to $DOC_DIR/filename.lyxdir? Unless such a directory exist

A solid proposal, please! (Was: Summary to the individual embedding debate)

> I'm trying to concentrate on very general questions > about how these two proposals work. The question, "Do you use zip or tar or > base64?" is just not worth discussing at this point. ... Richard, We are both tired of this discussion. My proposal is solid. I can provide every bit of detail if

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

> It depends upon whether the file is bundled or also wrapped. If the file is > just bundled, then there's just $DOC_DIR/filename.lyxdir. So, if a user turns off 'compression', will $TEMP_DIR/filename.lyxdir be moved to $DOC_DIR/filename.lyxdir? Now, when I turn on 'compression', what will happen

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

Bo Peng wrote: You uncompress to LyX's temporary directory. So you now have: /tmp/lyx_randomstuff/filename.lyx /tmp/lyx_randomstuff/filename.lyxdir/ Then LyX opens the former. Isn't this exactly how compressed files work now? Sorry, this is still unclear to me. In your approach, when

Re: Purpose of debate? (Was: Summary to the individual embedding debate)

Bennett Helm wrote: On Thu, May 15, 2008 at 1:10 PM, Bo Peng <[EMAIL PROTECTED] > wrote: > I think most people will not be able to be consistent over such a prolonged > discussion... Consistency would be easy to achieve if people know what they are

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

> You uncompress to LyX's temporary directory. So you now have: > /tmp/lyx_randomstuff/filename.lyx > /tmp/lyx_randomstuff/filename.lyxdir/ > Then LyX opens the former. > > Isn't this exactly how compressed files work now? Sorry, this is still unclear to me. In your approach, when you turn on

Re: Purpose of debate? (Was: Summary to the individual embedding debate)

Bo Peng wrote: I think most people will not be able to be consistent over such a prolonged discussion... Consistency would be easy to achieve if people know what they are doing and have a clear mind during the discussions. Shifting back and forth makes the discussions difficult and wastes

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

Bo Peng wrote: Note that extracting files to the document directory can cause problems with permissions. If a user only has the permissions to edit a single file, there will be no problem when embedded files are temporarily extracted to the temp directory. However, creating files and new folders

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

[EMAIL PROTECTED] wrote: On Thu, 15 May 2008, Richard Heck wrote: Bo Peng wrote: > If the file is wrapped, then it would be unpacked in the temporary > directory: wrapping is essentially just an extension of compression. If > it's > not wrapped, then of course it doesn't need to be unpac

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

Joost Verburg wrote: Bo Peng wrote: Not really. My proposal disallows external editing of embedded files. So I embed my bibfile and now I can't edit it? If so, this is a very big flaw. I meant that you are discouraged from editing it directly, like unzip a OOo document, edit and zip it back.

Re: Purpose of debate? (Was: Summary to the individual embedding debate)

On Thu, May 15, 2008 at 1:10 PM, Bo Peng <[EMAIL PROTECTED]> wrote: > > I think most people will not be able to be consistent over such a > prolonged > > discussion... > > Consistency would be easy to achieve if people know what they are > doing and have a clear mind during the discussions. Shifti

Re: Purpose of debate? (Was: Summary to the individual embedding debate)

On Thu, 15 May 2008, Bo Peng wrote: I think most people will not be able to be consistent over such a prolonged discussion... Consistency would be easy to achieve if people know what they are doing and have a clear mind during the discussions. Shifting back and forth makes the discussions di

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

> Note that extracting files to the document directory can cause > problems with permissions. If a user only has the permissions to edit a > single file, there will be no problem when embedded files are temporarily > extracted to the temp directory. However, creating files and new folders in > the

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

On Thu, 15 May 2008, Richard Heck wrote: Bo Peng wrote: > If the file is wrapped, then it would be unpacked in the temporary > directory: wrapping is essentially just an extension of compression. If > it's > not wrapped, then of course it doesn't need to be unpacked. > Now, here comes

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

Bo Peng wrote: Not really. My proposal disallows external editing of embedded files. So I embed my bibfile and now I can't edit it? If so, this is a very big flaw. I meant that you are discouraged from editing it directly, like unzip a OOo document, edit and zip it back. You have to do it in l

Re: Purpose of debate? (Was: Summary to the individual embedding debate)

> I think most people will not be able to be consistent over such a prolonged > discussion... Consistency would be easy to achieve if people know what they are doing and have a clear mind during the discussions. Shifting back and forth makes the discussions difficult and wastes other's time. If yo

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

On Thu, 15 May 2008, Richard Heck wrote: There are tons of cool things that could be done here. As I mentioned in a different thread, if we had the network support, you could even bundle http://myserver.com/bibfiles/mybib.bib, and then update it when and as necessary. How cool is that? I vag

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

>> Not really. My proposal disallows external editing of embedded files. > > So I embed my bibfile and now I can't edit it? If so, this is a very big > flaw. I meant that you are discouraged from editing it directly, like unzip a OOo document, edit and zip it back. You have to do it in lyx, by wha

Re: Purpose of debate? (Was: Summary to the individual embedding debate)

On Thu, 15 May 2008, Bo Peng wrote: You said I think most people will not be able to be consistent over such a prolonged discussion... All mails are achieved. Well, given the size, it's effectively below the noise threshold. Are you guys having fun? I happen to think LyX developme

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

[EMAIL PROTECTED] wrote: On Thu, 15 May 2008, Richard Heck wrote: You could even have (say, on the context menu) an "Edit external file..." menu entry that would open the external file, let you edit it, and then update the internal file all in one step. The enable() routine could check if the

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

Bo Peng wrote: If the file is wrapped, then it would be unpacked in the temporary directory: wrapping is essentially just an extension of compression. If it's not wrapped, then of course it doesn't need to be unpacked. Now, here comes another surprise. Currently, when we have a compressed

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

Bo Peng wrote: Probably I fail to see the problem, my fault. AFAIU if a user wants to replace a file in the bundle there is no one preventing it from happen. Under any of the different contender proposals. Not really. My proposal disallows external editing of embedded files. So I em

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

On Thu, 15 May 2008, Richard Heck wrote: You could even have (say, on the context menu) an "Edit external file..." menu entry that would open the external file, let you edit it, and then update the internal file all in one step. The enable() routine could check if the file is there first, of c

Re: Purpose of debate? (Was: Summary to the individual embedding debate)

> Trust me. I'm not the one you're embarrassing. Then read your own mails. You said that you would use zip format and later denied it. All mails are achieved. Bo

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

> If the file is wrapped, then it would be unpacked in the temporary > directory: wrapping is essentially just an extension of compression. If it's > not wrapped, then of course it doesn't need to be unpacked. Now, here comes another surprise. Currently, when we have a compressed file, we open it

Re: Purpose of debate? (Was: Summary to the individual embedding debate)

Bo Peng wrote: This debate would have been a lot easier if you had made a lot fewer comments of this type. And for what it's worth, the word is "elusive". I do not want to embarrass you again by citing what you have said during the discussion. Trust me. I'm not the one you're embarra

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

Leuven, E. wrote: Abdelrazak Younes wrote: I personally think supporting base64 embedding is interesting but should not be used for bundling purpose. And I do think we should make our format slowly evolve towards ODF in the 1.7 devel. That being said, I am not convinced the lyxdir folder

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

Abdelrazak Younes wrote: Bo Peng wrote: Users can edit the bundled copy directly IF the file isn't wrapped. But your approach has nothing to do with wrap, Right? :-) You do not really know what you are talking about here. Wrapped or not, when a lyx file is edited, filename.lyxdir is ther

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

Bo Peng wrote: Not true. Being in the temp folder doesn't mean they are invisible. No. This 'invisibility' is at the design level. I hide the file but users can of course dig it out. Richard's approach is different in that it shows the file and *expect* users to modify them. No, that i

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

>> You do not really know what you are talking about here. Wrapped or >> not, when a lyx file is edited, filename.lyxdir is there and users are >> allowed to edit the bundled copy directly. For example, if you have a >> bundled file in zip or base64 format, when you open it, because the >> insets r

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

Bo Peng wrote: Users can edit the bundled copy directly IF the file isn't wrapped. But your approach has nothing to do with wrap, Right? :-) You do not really know what you are talking about here. Wrapped or not, when a lyx file is edited, filename.lyxdir is there and users are allowed to

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

> Probably I fail to see the problem, my fault. > > AFAIU if a user wants to replace a file in the bundle there is no one > preventing it from happen. Under any of the different contender proposals. Not really. My proposal disallows external editing of embedded files. Being able to edit a bundle

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

[EMAIL PROTECTED] wrote: On Thu, 15 May 2008, Bo Peng wrote: So the problem here is that because there is no external file in Richard's bundled mode, users tend to hack filename.lyxdir so that they can update some files directly. I'm probably dense[*], but what's wrong with keeping a bunch o

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

On Thursday 15 May 2008 17:19:53 Bo Peng wrote: > Ohhm, I really do not know what you are talking about. We are talking > about Richard's problem, not mine. In my proposal, if a user would > like to directly update a file, he goes the old and faithful external > file way. The trouble is only with R

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

Bo Peng wrote: Are you proposing to add a file browser to lyx? Because we need the mime-type association for the different file types to edit. Would you be happy with a file browser launched on a temporary directory to inspect and change the file content of the embedded files? Would this so

Re: New proposal? Sorry. (Was: Summary to the individual embedding debate.)

> With the details worked out, I think this is pretty similar to what I've > got. That is great. Then we do not have a new proposal to worry about (if Edwin agrees). Bo

Re: New proposal? Sorry. (Was: Summary to the individual embedding debate.)

Bo Peng wrote: and i would add: no individual embedding (like in odf i guess) (which would probably boil down to something very similar like this: http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg138780.html) With the details worked out, I think this is pretty similar to what I've go

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

> Are you proposing to add a file browser to lyx? > Because we need the mime-type association for the different file types to > edit. > > Would you be happy with a file browser launched on a temporary directory to > inspect and change the file content of the embedded files? > > Would this solve

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

On Thursday 15 May 2008 17:03:51 Bo Peng wrote: > > Sorry for my laziness. Are you proposing to add a file browser to lyx? Because we need the mime-type association for the different file types to edit. Would you be happy with a file browser launched on a temporary directory to inspect an

New proposal? Sorry. (Was: Summary to the individual embedding debate.)

> and i would add: no individual embedding (like in odf i guess) > > (which would probably boil down to something very similar like this: > http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg138780.html) Edwin, I have seen this link a few times, are you sure you want to propose your idea? We

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

> So you mean that is not possible to edit the bundled files with Richards > approach? It is possible to edit the bundled files with Richard's approach, this has nothing to do with session. In Richard's approach, there is this external file chapter2/figure.png, and a corresponding filename.lyxdir

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

On Thursday 15 May 2008 16:44:02 Bo Peng wrote: > No. These are two completely different issues. This thread is about > visibility and edition of embedded/bundled files, and the session > solution is about once your turn on the bundled mode, how to turn it > off. So you mean that is not possible t

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

> I'm probably dense[*], but what's wrong with keeping a bunch of files in > filename.lyxdir and modify them there? I guess people simply jump to the last email of a thread?? (No need to regret though). The problem is that there are two visible copies of the same file, the external one and the bu

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

> I saw Richard referring to the session solution to this case. No. These are two completely different issues. This thread is about visibility and edition of embedded/bundled files, and the session solution is about once your turn on the bundled mode, how to turn it off. Bo

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

On Thu, 15 May 2008, Bo Peng wrote: So the problem here is that because there is no external file in Richard's bundled mode, users tend to hack filename.lyxdir so that they can update some files directly. I'm probably dense[*], but what's wrong with keeping a bunch of files in filename.lyxdi

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

On Thursday 15 May 2008 16:24:34 Bo Peng wrote: > So the problem here is that because there is no external file in > Richard's bundled mode, users tend to hack filename.lyxdir so that > they can update some files directly. I saw Richard referring to the session solution to this case. Citing Richa

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

> Take the current lyx file as an example, we discourage the manual change of > lyx files but we don't disallow it. You completely missed the point. Of course users can manually edit .lyx file, edit filename.lyxdir/figures/figure.png, even dig out my hidden E23479789.png and edit, but if a featur

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

On Thursday 15 May 2008 15:33:33 Bo Peng wrote: > Me neither and my design disallows it. Richard is allowing direct > modifying of his bundled files. This is exactly what this thread is > about. In my opinion, these files should be hidden. Allowing yes, encouraging no. Take the current lyx fi

RE: Change bundled file directly? (Was: Summary to the individual embedding debate.)

Abdelrazak Younes wrote: > I personally think supporting base64 > embedding is interesting but should not be used for bundling purpose. > > And I do think we should make our format slowly evolve towards > ODF in the 1.7 devel. That being said, I am not convinced the lyxdir > folder should be a

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

> When was the last time that you have changed an embedded file inside a OO > (Open Office) document? Never. > The OO documents are zip files with a structure that looks similar to your > initial proposal. Yes. > Although I sometimes work with OO (due mainly to word :-( ) I have never > changed

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

> Not true. Being in the temp folder doesn't mean they are invisible. No. This 'invisibility' is at the design level. I hide the file but users can of course dig it out. Richard's approach is different in that it shows the file and *expect* users to modify them. > General remark on base64 versus

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

On Thursday 15 May 2008 15:15:09 Bo Peng wrote: > So your understanding is that as long as users can locate these files > easily, it is good to do so? > > No, this is not implementation details. My approach disallows, and > Richard's approach allows, direct edition of embedded/bundled files. > This

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

Bo Peng wrote: Users can edit the bundled copy directly IF the file isn't wrapped. But your approach has nothing to do with wrap, Right? :-) You do not really know what you are talking about here. Wrapped or not, when a lyx file is edited, filename.lyxdir is there and users are allowed to

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

On Thu, May 15, 2008 at 9:06 AM, José Matos <[EMAIL PROTECTED]> wrote: > On Thursday 15 May 2008 14:36:46 Bo Peng wrote: >> He claimed that there is no difference between our approaches. Is it true? > > To it seems that differences are just implementation details, and intrepid > user will recover e

Re: Purpose of debate? (Was: Summary to the individual embedding debate)

> This debate would have been a lot easier if you had made a lot fewer > comments of this type. And for what it's worth, the word is "elusive". I do not want to embarrass you again by citing what you have said during the discussion. You have indeed being elusive by using a zip format before, and d

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

On Thursday 15 May 2008 14:36:46 Bo Peng wrote: > He claimed that there is no difference between our approaches. Is it true? To it seems that differences are just implementation details, and intrepid user will recover easily the files with any of the proposed approaches. -- José Abílio

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

> Users can edit the bundled copy directly IF the file isn't wrapped. But your approach has nothing to do with wrap, Right? :-) You do not really know what you are talking about here. Wrapped or not, when a lyx file is edited, filename.lyxdir is there and users are allowed to edit the bundled cop

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

> On my approach, bundled files are invisible if the file is also "wrapped". > Users do not have to add anything to a subversion repository in this case, > either. If there's a worry about the file's being binary, then I can base64 > encode it instead. Whatever. Please choose a file format for you

Re: Change bundled file directly? (Was: Summary to the individual embedding debate.)

Bo Peng wrote: He claimed that there is no difference between our approaches. Is it true? In my approach, embedded files are invisible to users. Users do not need to add them to a subversion repository. They do not have to locate some file under filename.lyxdir/figures to edit them because they

Change bundled file directly? (Was: Summary to the individual embedding debate.)

>> ...you too have two copies of the file. >> > That is: If, on your approach, a graphic is embedded and the user hits "Edit > file", which file do they edit? The embedded one, of course, since there may > be no external file. But what if there is an external file and they edit > that? No effect on

Re: Purpose of debate? (Was: Summary to the individual embedding debate)

[EMAIL PROTECTED] wrote: On Thu, 15 May 2008, rgheck wrote: Has anyone else noticed how few people are willing to expose themselves to this kind of treatment? Y'all a bunch of maschochists! [Yes, I'm starting Friday early...] I don't want to dictate what you do with your spare time but, at t

  1   2   >