rgheck wrote:
> Sergiu Carpov wrote:
> > Should I send you a patch file? By the way about what patch you are
> > speaking? The one with only string comparisons or with a new FileName?
> >
> >
>
> No, we figured it out. I'll just use the string comparison for now. It
> looks as if the whole DocFil
Sergiu Carpov wrote:
Should I send you a patch file? By the way about what patch you are
speaking? The one with only string comparisons or with a new FileName?
No, we figured it out. I'll just use the string comparison for now. It
looks as if the whole DocFileName thing could use some work.
Should I send you a patch file? By the way about what patch you are
speaking? The one with only string comparisons or with a new FileName?
2009/7/9 rgheck
>
> OK, Sergiu, I think we'll go with your last patch, then.
>
> We don't have to have a GPL statement for little things like this, but if
I hereby grant permission to license my contributions to LyX under the Gnu
General Public Licence, version 2 or later.
Thanks.
2009/7/9 rgheck
> Jean-Marc Lasgouttes wrote:
>
>> rgheck writes:
>>
>>
>>> Unfortunately, this does not work, because the operator== also compares
> the
> sav
Jean-Marc Lasgouttes wrote:
rgheck writes:
Unfortunately, this does not work, because the operator== also compares the
save_abs_path_ members.
I do not know much about these DocFileName things. But looking at the
API, I realize that I do not understand it at all. There is no
DocF
OK, Sergiu, I think we'll go with your last patch, then.
We don't have to have a GPL statement for little things like this, but
if you'd like to be recognized in our list of contributors, could you
post a message to the list saying something like this:
I hereby grant permission to license my
rgheck writes:
>>> Unfortunately, this does not work, because the operator== also compares the
>>> save_abs_path_ members.
I do not know much about these DocFileName things. But looking at the
API, I realize that I do not understand it at all. There is no
DocFileName constructor allowing to spec
Pavel Sanda wrote:
Richard Heck wrote:
Perhaps I should explain the background to this. There are cases where the
kind of comparison we are doing here would return false, but where the same
location in the filesystem is in question both times. All you need is a
link somewhere to get this. I
Richard Heck wrote:
> Perhaps I should explain the background to this. There are cases where the
> kind of comparison we are doing here would return false, but where the same
> location in the filesystem is in question both times. All you need is a
> link somewhere to get this. If we want to wor
Sergiu Carpov wrote:
2009/7/8 rgheck
Jean-Marc Lasgouttes wrote:
rgheck writes:
JMarc, do you have any thoughts about this? As I said earlier, I'd
rather do the comparison a different way, but
I have to admit that I have not followed this thread and that I
2009/7/8 rgheck
> Jean-Marc Lasgouttes wrote:
>
>> rgheck writes:
>>
>>
>>> JMarc, do you have any thoughts about this? As I said earlier, I'd
>>> rather do the comparison a different way, but
>>>
>>>
>>
>> I have to admit that I have not followed this thread and that I cannot
>> extract its
Jean-Marc Lasgouttes wrote:
rgheck writes:
JMarc, do you have any thoughts about this? As I said earlier, I'd
rather do the comparison a different way, but
I have to admit that I have not followed this thread and that I cannot
extract its "substantifique mmoëlle" ("its essence" lo
rgheck writes:
> JMarc, do you have any thoughts about this? As I said earlier, I'd
> rather do the comparison a different way, but
I have to admit that I have not followed this thread and that I cannot
extract its "substantifique mmoëlle" ("its essence" looks so plain...).
Care to explain?
On 07/07/2009, rgheck wrote:
> Sergiu Carpov wrote:
>> Your solution doesn't work, because "expfile" has save_abs_path_ true
>> and in "params.filename" this fields is false. For the comparison of
>> DocFileName this value must be the same.
>>
>>
> Hmm, OK, I see the issue.
>
>> By the way, what d
Sergiu Carpov wrote:
Your solution doesn't work, because "expfile" has save_abs_path_ true
and in "params.filename" this fields is false. For the comparison of
DocFileName this value must be the same.
Hmm, OK, I see the issue.
By the way, what does it means "save_abs_path_" field?
It
Your solution doesn't work, because "expfile" has save_abs_path_ true
and in "params.filename" this fields is false. For the comparison of
DocFileName this value must be the same. By the way, what does it
means "save_abs_path_" field?
And also a minor difference is that in my example it was not-equ
Yes, i've verified with "pdfpages" and "rasterImage" (.png and .bmp).
In case of pdfpages and png rasterImage it doesn't export the included
file, i.e. no dummy overwrite message box. However for rasterImage of
type bmp lyx exports a png image.
On 07/07/2009, rgheck wrote:
> Sergiu Carpov wrote:
Sergiu Carpov wrote:
rgheck writes:
Sergiu Carpov wrote:
Hi,
I am trying to fix this bug. And I have observed an incoherences in the
source code.
I'm examining the static function "updateExternal" from "external"
namespace, see this page
http://wiki.lyx.org/sourcedoc/svn/nam
rgheck writes:
>
> Sergiu Carpov wrote:
> > Hi,
> >
> > I am trying to fix this bug. And I have observed an incoherences in the
> > source code.
> > I'm examining the static function "updateExternal" from "external"
> > namespace, see this page
> >
http://wiki.lyx.org/sourcedoc/svn/namespacelyx_
Sergiu Carpov wrote:
Hi,
I am trying to fix this bug. And I have observed an incoherences in the
source code.
I'm examining the static function "updateExternal" from "external"
namespace, see this page
http://wiki.lyx.org/sourcedoc/svn/namespacelyx_1_1external.html#940e34e099754314ff8a1ca2ac1b9b
Jürgen Spitzmüller wrote:
> updateResult is a string that holds the name of the external file and
> referencedFile is a map that holds file versions needed by different
> flavors of the inset.
>
> IOW, updateResult is the file that is actually included via InsetExternal
> (say, a *.jpg graphic), wh
Sergiu Carpov wrote:
> There it is used the class Template::Format, this class has "updateResult"
> and "referencedFiles" fields. Which are both used in "updateExternal"
> function. And now my question are:
> 1. What are the differences between this two fields?
updateResult is a string that holds
Hi,
I am trying to fix this bug. And I have observed an incoherences in the
source code.
I'm examining the static function "updateExternal" from "external"
namespace, see this page
http://wiki.lyx.org/sourcedoc/svn/namespacelyx_1_1external.html#940e34e099754314ff8a1ca2ac1b9b65
There it is used the
23 matches
Mail list logo
