Abdel, revision 21967 broke plaintext output. No plaintext file is generated,
instead, an empty file named UTF-8 is generated in the working directory.
The attached patch (against branch) fixes it, but still
odocfstream::odocfstream(string const encoding) obviously doesn't work as
intended.
Enrico Forestieri wrote:
What about the attached?
Honestly, I doubt it is worth inserting the XML-like tags and removing them
again in the next step.
Wouldn't it be easier to just show
LyX Warning: uncodable character 'x' right from the beginning?
BTW your patch forgets that LyX Warning is
On Sat, Dec 29, 2007 at 11:01:58AM +0100, Jürgen Spitzmüller wrote:
Enrico Forestieri wrote:
What about the attached?
Honestly, I doubt it is worth inserting the XML-like tags and removing them
again in the next step.
It is not strange if you think that it allows for frontend
Enrico Forestieri wrote:
Wouldn't it be easier to just show
LyX Warning: uncodable character 'x' right from the beginning?
This would already be less ugly.
OK, then let's do this.
BTW your patch forgets that LyX Warning is translatable (which of
course only makes sense if this string
On Sat, Dec 29, 2007 at 01:53:20PM +0100, Jürgen Spitzmüller wrote:
The uncodable character part will be translated as well (see Paragraph.cpp).
I see. But shouldn't this translation be decoupled from the
LyX Warning one in order to avoid problems in the matching?
I mean, there's a _(LyX
Enrico Forestieri wrote:
I see. But shouldn't this translation be decoupled from the
LyX Warning one in order to avoid problems in the matching?
I mean, there's a _(LyX Warning: uncodable character) in
Paragraph.cpp and a qt_(LyX Warning:) in the qt sources,
so, in theory, LyX Warning could
On Dec 26, 2007, at 8:39 AM, Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
Author: sts
Date: Wed Dec 26 14:31:17 2007
New Revision: 22312
URL: http://www.lyx.org/trac/changeset/22312
Log:
* compile fix
Sorry and thanks!
As I've done a lot of cleanup there please verify that everything
On Dec 27, 2007, at 6:39 AM, Abdelrazak Younes wrote:
New gift to LyX community. I've create bindings only for cua. I
don't know about the others. Someone please volunteer for Mac.
I can't think of any good bindings for this on Mac; all the obvious
ones are taken (and are intended to make
Jürgen Spitzmüller wrote:
Abdel, revision 21967 broke plaintext output. No plaintext file is generated,
instead, an empty file named UTF-8 is generated in the working directory.
The attached patch (against branch) fixes it, but still
odocfstream::odocfstream(string const encoding) obviously
Bennett Helm wrote:
On Dec 27, 2007, at 6:39 AM, Abdelrazak Younes wrote:
New gift to LyX community. I've create bindings only for cua. I don't
know about the others. Someone please volunteer for Mac.
I can't think of any good bindings for this on Mac; all the obvious ones
are taken (and
Bennett Helm wrote:
On Dec 26, 2007, at 8:39 AM, Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
Author: sts
Date: Wed Dec 26 14:31:17 2007
New Revision: 22312
URL: http://www.lyx.org/trac/changeset/22312
Log:
* compile fix
Sorry and thanks!
As I've done a lot of cleanup there please
rgheck wrote:
Abdelrazak Younes wrote:
Probably something like the bibfiles cache?
Probably a good idea.
All right, I had a quick look at this. The analogy is reasonable enough,
but it's not quite right. In that case, we basically keep a list of
timestamps and check whether the files have
hi,
I would like to have this test in the cmake build (scons has it). Otherwise
the lyxserver is disabled on unix, as it is on windows.
The changes are against trunk, but branch 1.5 is similar.
Kornel
--
Kornel Benko
[EMAIL PROTECTED]
Index: development/cmake/configCompiler.h.cmake
Considering multiview, I'd prefer a solution based on signal/slot.
Maybe static signal member in InsetLabel? See attached, untested.
OK. I wasn't thinking that the different views had different BufferList's.
In any event, the SignalSlot machinery seems to be unused at present, so
I can't
Hello everyone,
This message is mainly intended to the LyX developers. A paper [1] by
Gregor Gorjanc and due to appear in the near future on Rnews [2]
describes into great detail all the steps needed to customize LyX so
that it integrate nicely with Sweave [3] for creating reports using R.
I
rgheck wrote:
Considering multiview, I'd prefer a solution based on signal/slot.
Maybe static signal member in InsetLabel? See attached, untested.
OK. I wasn't thinking that the different views had different BufferList's.
No, the BufferList is common, it's just that mutiple views might
Abdelrazak Younes wrote:
In any event, the SignalSlot machinery seems to be unused at present,
so I can't find an example of its use. But the moment I try to use
it, I get linking errors. It's enough to add this:
static Signal modified;
~InsetLabel() { modified.fire()
to InsetLabel.h
On Sat, Dec 29, 2007 at 03:43:44PM +0100, Jürgen Spitzmüller wrote:
Enrico Forestieri wrote:
I see. But shouldn't this translation be decoupled from the
LyX Warning one in order to avoid problems in the matching?
I mean, there's a _(LyX Warning: uncodable character) in
Paragraph.cpp and
Abdel, revision 21967 broke plaintext output. No plaintext file is generated,
instead, an empty file named "UTF-8" is generated in the working directory.
The attached patch (against branch) fixes it, but still
odocfstream::odocfstream(string const & encoding) obviously doesn't work as
Enrico Forestieri wrote:
> What about the attached?
Honestly, I doubt it is worth inserting the XML-like tags and removing them
again in the next step.
Wouldn't it be easier to just show
right from the beginning?
BTW your patch forgets that "LyX Warning" is translatable (which of course
only
On Sat, Dec 29, 2007 at 11:01:58AM +0100, Jürgen Spitzmüller wrote:
> Enrico Forestieri wrote:
> > What about the attached?
>
> Honestly, I doubt it is worth inserting the XML-like tags and removing them
> again in the next step.
It is not strange if you think that it allows for frontend
Enrico Forestieri wrote:
> > Wouldn't it be easier to just show
> > right from the beginning?
>
> This would already be less ugly.
OK, then let's do this.
> > BTW your patch forgets that "LyX Warning" is translatable (which of
> > course only makes sense if this string is also displayed).
>
> I
On Sat, Dec 29, 2007 at 01:53:20PM +0100, Jürgen Spitzmüller wrote:
> The "uncodable character" part will be translated as well (see Paragraph.cpp).
I see. But shouldn't this translation be decoupled from the
"LyX Warning" one in order to avoid problems in the matching?
I mean, there's a _("")
Enrico Forestieri wrote:
> I see. But shouldn't this translation be decoupled from the
> "LyX Warning" one in order to avoid problems in the matching?
> I mean, there's a _("") in
> Paragraph.cpp and a qt_(" so, in theory, "LyX Warning" could be translated differently.
> For example, I could
On Dec 26, 2007, at 8:39 AM, Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
Author: sts
Date: Wed Dec 26 14:31:17 2007
New Revision: 22312
URL: http://www.lyx.org/trac/changeset/22312
Log:
* compile fix
Sorry and thanks!
As I've done a lot of cleanup there please verify that everything
On Dec 27, 2007, at 6:39 AM, Abdelrazak Younes wrote:
New gift to LyX community. I've create bindings only for cua. I
don't know about the others. Someone please volunteer for Mac.
I can't think of any good bindings for this on Mac; all the obvious
ones are taken (and are intended to make
Jürgen Spitzmüller wrote:
Abdel, revision 21967 broke plaintext output. No plaintext file is generated,
instead, an empty file named "UTF-8" is generated in the working directory.
The attached patch (against branch) fixes it, but still
odocfstream::odocfstream(string const & encoding)
Bennett Helm wrote:
On Dec 27, 2007, at 6:39 AM, Abdelrazak Younes wrote:
New gift to LyX community. I've create bindings only for cua. I don't
know about the others. Someone please volunteer for Mac.
I can't think of any good bindings for this on Mac; all the obvious ones
are taken (and
Bennett Helm wrote:
On Dec 26, 2007, at 8:39 AM, Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
Author: sts
Date: Wed Dec 26 14:31:17 2007
New Revision: 22312
URL: http://www.lyx.org/trac/changeset/22312
Log:
* compile fix
Sorry and thanks!
As I've done a lot of cleanup there please
rgheck wrote:
Abdelrazak Younes wrote:
Probably something like the bibfiles cache?
Probably a good idea.
All right, I had a quick look at this. The analogy is reasonable enough,
but it's not quite right. In that case, we basically keep a list of
timestamps and check whether the files have
hi,
I would like to have this test in the cmake build (scons has it). Otherwise
the lyxserver is disabled on unix, as it is on windows.
The changes are against trunk, but branch 1.5 is similar.
Kornel
--
Kornel Benko
[EMAIL PROTECTED]
Index: development/cmake/configCompiler.h.cmake
Considering multiview, I'd prefer a solution based on signal/slot.
Maybe static signal member in InsetLabel? See attached, untested.
OK. I wasn't thinking that the different views had different BufferList's.
In any event, the SignalSlot machinery seems to be unused at present, so
I can't
Hello everyone,
This message is mainly intended to the LyX developers. A paper [1] by
Gregor Gorjanc and due to appear in the near future on Rnews [2]
describes into great detail all the steps needed to customize LyX so
that it integrate nicely with Sweave [3] for creating reports using R.
I
rgheck wrote:
Considering multiview, I'd prefer a solution based on signal/slot.
Maybe static signal member in InsetLabel? See attached, untested.
OK. I wasn't thinking that the different views had different BufferList's.
No, the BufferList is common, it's just that mutiple views might
Abdelrazak Younes wrote:
In any event, the SignalSlot machinery seems to be unused at present,
so I can't find an example of its use. But the moment I try to use
it, I get linking errors. It's enough to add this:
static Signal modified;
~InsetLabel() { modified.fire()
to InsetLabel.h
On Sat, Dec 29, 2007 at 03:43:44PM +0100, Jürgen Spitzmüller wrote:
> Enrico Forestieri wrote:
> > I see. But shouldn't this translation be decoupled from the
> > "LyX Warning" one in order to avoid problems in the matching?
> > I mean, there's a _("") in
> > Paragraph.cpp and a qt_(" > so, in
36 matches
Mail list logo
