Bennett Helm <[EMAIL PROTECTED]> writes:
> Me too, but in practice it's not that simple, especially when
> upgrading (with changed user directory locations). We should, in
> effect, make the LyX/Mac Installer program a part of the LyX.app
> bundle and ensure it will run at the appropriate times au
On Sep 4, 2007, at 6:55 AM, Jean-Marc Lasgouttes wrote:
"Bo Peng" <[EMAIL PROTECTED]> writes:
What about using the comment field of the zip file? It appears in
the
first bits of the binary IIRC. The comment could actually be the
manifest and start with an indication of the lyx format (and ma
"Bo Peng" <[EMAIL PROTECTED]> writes:
>> What about using the comment field of the zip file? It appears in the
>> first bits of the binary IIRC. The comment could actually be the
>> manifest and start with an indication of the lyx format (and maybe
>> version).
>
> I do not know the zip format wel
On Saturday 01 September 2007 03:05:24 Richard Heck wrote:
> In a way tee does not allow? Sounds like a new project!
>
> rh
The problem here is we don't have an "inverse tee". diff for example receives
from two streams to a single a single one.
I know that I can use "diff somefile -" and here th
José Matos wrote:
And yes, I had the need sometimes to use pipes in a non-linear way and no
shell allows me to do it.
In a way tee does not allow? Sounds like a new project!
rh
--
==
Richard G Heck, Jr
Professor of Philosophy
On Friday 31 August 2007 18:13:54 Abdelrazak Younes wrote:
> Planning 20 years in advance is not an easy task...
Or sometimes even desirable. :-)
> Abdel.
--
José Abílio
On Friday 31 August 2007 15:55:26 Richard Heck wrote:
> Bo Peng wrote:
> >> 1/ if it is not done already, support for reading/writing compressed
> >> lyx files should be removed: it has no interested wrt .zip file
> >> version.
> >
> > I agree. It does not make sense to keep two compressed version.
On Friday 31 August 2007 15:25:17 Bo Peng wrote:
> > 1/ if it is not done already, support for reading/writing compressed
> > lyx files should be removed: it has no interested wrt .zip file
> > version.
>
> I agree. It does not make sense to keep two compressed version. I am
> not sure if lyx2lyx d
On Friday 31 August 2007 15:15:04 Jean-Marc Lasgouttes wrote:
Oh, nice and good old Fridays discussions.
> I disagree 100%. One thing that people like about LyX files is that
> they are text files on which one can do straightforward search and
> repalce without looking for fancy python librarie
Jean-Marc Lasgouttes wrote:
Richard Heck <[EMAIL PROTECTED]> writes:
By the way, let it not be lost in this discussion how useful this will be.
Sure. This is why it should be done right. Ideally, I'd like LyX 2.3
Which year?
to use the same bundle structure. This requires some planning.
> What about using the comment field of the zip file? It appears in the
> first bits of the binary IIRC. The comment could actually be the
> manifest and start with an indication of the lyx format (and maybe
> version).
I do not know the zip format well enough to do this. Our embedded
minzip might
"Bo Peng" <[EMAIL PROTECTED]> writes:
>> 2/ is the new zip base version designed such that a "file" utility can
>> guess its type based on the first few characters of the binary file?
>> It could be doable if the first file (the manifest?) is stored instead
>> of deflated.
>
> Yes. It is a regular
Richard Heck <[EMAIL PROTECTED]> writes:
> By the way, let it not be lost in this discussion how useful this will be.
Sure. This is why it should be done right. Ideally, I'd like LyX 2.3
to use the same bundle structure. This requires some planning.
JMarc
> By the way, let it not be lost in this discussion how useful this will be.
OK. Let us adjust the feature after it is (almost) done.
Bo
Bo Peng wrote:
1/ if it is not done already, support for reading/writing compressed
lyx files should be removed: it has no interested wrt .zip file
version.
I agree. It does not make sense to keep two compressed version. I am
not sure if lyx2lyx decompress compressed lyx file though.
Jo
> 1/ if it is not done already, support for reading/writing compressed
> lyx files should be removed: it has no interested wrt .zip file
> version.
I agree. It does not make sense to keep two compressed version. I am
not sure if lyx2lyx decompress compressed lyx file though.
> 2/ is the new zip b
José Matos <[EMAIL PROTECTED]> writes:
> First: the compressed feature is done in such a way that inside lyx the user
> should not care if the file is compressed or not. The same should happen for
> embedded files.
>
> Second: people who write scripts to modify should know better. :-)
> We shoul
"Bo Peng" <[EMAIL PROTECTED]> writes:
> What preference? How to predict the compression status of a .lyx file?
> The compression status can only be tested against the .lyx file, the
> same hold for bundled file.
We are _designing_ a format and its use should be predictable. If
people do batch pro
On Thursday 30 August 2007 22:58:50 Bo Peng wrote:
> What do you mean by directories? Right now, files under the document
> directory is saved in their original subdirectories (Christian's
> suggestion).
Ah, OK. That was what I meant but I thought that you said it was not
implemented yet.
--
Jo
> We need to support directories. Actually I would like to see that support
> the sooner possible.
What do you mean by directories? Right now, files under the document
directory is saved in their original subdirectories (Christian's
suggestion).
> Don't forget that what are doing requires a f
On Thursday 30 August 2007 20:46:16 Bo Peng wrote:
> Agreed. I think it can be done before XML. :-)
>
> Jose?
We need to support directories. Actually I would like to see that support
the sooner possible.
Don't forget that what are doing requires a file format update, in this case
this mean
On 8/30/07, José Matos <[EMAIL PROTECTED]> wrote:
> On Thursday 30 August 2007 20:22:04 Bo Peng wrote:
> > Updated patch attached. This time, embedding will always result in a
> > zipped file.
>
> There is no need to revert the feature as long as you have the status of the
> package in the lyx fi
On Thursday 30 August 2007 20:22:04 Bo Peng wrote:
> Updated patch attached. This time, embedding will always result in a
> zipped file.
There is no need to revert the feature as long as you have the status of the
package in the lyx file.
Actually I found your first implementation neat. :-)
On Thursday 30 August 2007 20:11:28 Richard Heck wrote:
> How'd you get that working? I know there are shells other than bash that
> have really good text completion, but I haven't used them.
For bash there is the bash-completion package:
http://www.caliban.org/bash/
There are packages availa
> I'd let it in on the condition that already once did not work:
> If the feature is known to be broken before 1.6 release it will
> be deactivated.
Agreed. I think it can be done before XML. :-)
Jose?
Bo
On Thu, Aug 30, 2007 at 02:22:04PM -0500, Bo Peng wrote:
> > I will remove that small feature though, because embedding status will
> > be lost if a file without any embedded file is reopened. This can
> > upset the user if s/he insert a figure later and expect it to be
> > embedded.
>
> Updated p
> I will remove that small feature though, because embedding status will
> be lost if a file without any embedded file is reopened. This can
> upset the user if s/he insert a figure later and expect it to be
> embedded.
Updated patch attached. This time, embedding will always result in a
zipped fi
José Matos wrote:
On Thursday 30 August 2007 19:49:18 Richard Heck wrote:
I think the idea was that people would set it compressed or not and
never change it. I don't know that this is true.
rh
First: the compressed feature is done in such a way that inside lyx the user
should not ca
On Thursday 30 August 2007 19:49:18 Richard Heck wrote:
> I think the idea was that people would set it compressed or not and
> never change it. I don't know that this is true.
>
> rh
First: the compressed feature is done in such a way that inside lyx the user
should not care if the file is compr
Bo Peng wrote:
As I said, this could be problematic anyway, since some LyX files might
be compressed and some might not be. JMarc responded that it was
"predictable" if you knew how the preferences were set, but preference
settings change.
What preference? How to predict the compression sta
> As I said, this could be problematic anyway, since some LyX files might
> be compressed and some might not be. JMarc responded that it was
> "predictable" if you knew how the preferences were set, but preference
> settings change.
What preference? How to predict the compression status of a .lyx
Bo Peng wrote:
I am not sure this is a good idea. For example, people doing scripting
would be very unhappy to see that the file format is not predictable.
So you prefer a zipped file with an empty manifest? What do you mean
by 'doing scripting'? Do you expect people to manually unzip a bun
> I am not sure this is a good idea. For example, people doing scripting
> would be very unhappy to see that the file format is not predictable.
So you prefer a zipped file with an empty manifest? What do you mean
by 'doing scripting'? Do you expect people to manually unzip a bundled
file?
Bo
Richard Heck <[EMAIL PROTECTED]> writes:
> But Bo's earlier point was that the file format already isn't predictable.
It is bad, but at least it is predictable when the prefs are known.
> Welcome back!
Not really back yet. Kind of back :)
Jean-Marc Lasgouttes wrote:
"Bo Peng" <[EMAIL PROTECTED]> writes:
2. In case that there is no embedded file, .lyx file will *not* be
saved in a bundled format even if embedding is enabled. That is to
say, it is not trivial to tell in advance which file format will be
used.
I am not sur
"Bo Peng" <[EMAIL PROTECTED]> writes:
> 2. In case that there is no embedded file, .lyx file will *not* be
> saved in a bundled format even if embedding is enabled. That is to
> say, it is not trivial to tell in advance which file format will be
> used.
I am not sure this is a good idea. For exam
Bo Peng wrote:
So I could go either way.
The only advantage of using another file extension such as .lyb is to
tell users immediately if a file is in a bundled format. However,
because of the existence of compressed .lyx file, it does not help to
decide if it is safe to svn or view a .lyx
> So I could go either way.
The only advantage of using another file extension such as .lyb is to
tell users immediately if a file is in a bundled format. However,
because of the existence of compressed .lyx file, it does not help to
decide if it is safe to svn or view a .lyx file. Also, there are
José Matos wrote:
On Friday 24 August 2007 20:12:07 Bo Peng wrote:
I guess you know what I meant. :-)
And here is another one with some minor adjustments.
Bo
I am playing with your patch, reordering the diffs to better understand the
general structure. It helps if the first files in t
On Friday 24 August 2007 20:12:07 Bo Peng wrote:
> I guess you know what I meant. :-)
>
> And here is another one with some minor adjustments.
>
> Bo
I am playing with your patch, reordering the diffs to better understand the
general structure. It helps if the first files in the patch are the new
On Wednesday 29 August 2007 03:13:59 Bo Peng wrote:
> Forgotten?
Not at all. :-)
I had a deadline yesterday (Fedora development frozen in order to release F8
test 2 next week).
Today I will focus my attention on LyX. :-)
> Bo
--
José Abílio
On 8/24/07, Bo Peng <[EMAIL PROTECTED]> wrote:
> > > And here is another one with some minor adjustments.
> >
> > I will only look into this next Monday. :-(
>
> I will be happy to spend more time with my kids this weekend, so take
> your time. :-)
Forgotten?
Bo
> > And here is another one with some minor adjustments.
>
> I will only look into this next Monday. :-(
I will be happy to spend more time with my kids this weekend, so take
your time. :-)
Bo
On Friday 24 August 2007 20:12:07 Bo Peng wrote:
> I guess you know what I meant. :-)
>
> And here is another one with some minor adjustments.
I will only look into this next Monday. :-(
This should not dissuade other people from commenting the patch.
Expect other bombastic revelations as
> The updated patch is updated.
I guess you know what I meant. :-)
And here is another one with some minor adjustments.
Bo
Index: src/insets/InsetGraphics.h
===
--- src/insets/InsetGraphics.h (revision 19780)
+++ src/insets/InsetGra
> Jose, can I apply (an updated patch)?
The updated patch is updated.
Bo
Index: src/insets/InsetGraphics.h
===
--- src/insets/InsetGraphics.h (revision 19780)
+++ src/insets/InsetGraphics.h (working copy)
@@ -78,6 +78,8 @@
void edi
> Not really but this one is recommended to avoid the evaluation of end()
> at each iteration:
At least icc optimizes for such uses..., anyway, I will follow the convention.
Jose, can I apply (an updated patch)? I have some confidence in this
patch so it should be OK to apply. The next patch will
Bo Peng wrote:
Thank you for reviewing the patch.
+ for (FileList::iterator it = file_list_.begin(); it != file_list_.end();
++it)
+ it->invalidate();
Same for-style here...
I am not quite sure about this style issue. Is
FileList::iterator it = file_list_.begin();
for (; i
Bo Peng wrote:
> Thank you for reviewing the patch.
>
>> > + for (FileList::iterator it = file_list_.begin(); it !=
>> > file_list_.end(); ++it)
>> > + it->invalidate();
>> >
>> Same for-style here...
>
> I am not quite sure about this style issue. Is
>
> FileList::iterator it =
Thank you for reviewing the patch.
> > + for (FileList::iterator it = file_list_.begin(); it !=
> > file_list_.end(); ++it)
> > + it->invalidate();
> >
> Same for-style here...
I am not quite sure about this style issue. Is
FileList::iterator it = file_list_.begin();
for (; it !
Comments within.
Index: src/EmbeddedFiles.cpp
===
--- src/EmbeddedFiles.cpp (revision 0)
+++ src/EmbeddedFiles.cpp (revision 0)
@@ -0,0 +1,317 @@
+// -*- C++ -*-
+/**
+ * \file EmbeddedFiles.h
+ * This file is part of Ly
51 matches
Mail list logo
