Michael Gerz <[EMAIL PROTECTED]> writes:
> in bugzilla, 1.5.0svn in the version field does not make sense
> anymore. Instead we need a 1.6.0svn.
We have 254 open bugs against 1.5.0svn. Even if we changed the
version, we'd still have to do something about the 568 closed bugs.
I
Hi,
in bugzilla, 1.5.0svn in the version field does not make sense anymore.
Instead we need a 1.6.0svn.
Michael
Unfortunately I found
two bugs within the first minute or so:
I got a sample document through private email. The first problem is
that the chapter number of a child document will be 0 if the child
document uses a different layout from the master document. Because lyx
explicitly requires that ma
> 1. Chapter numbering bug (minor). I have a chapter that is in a separate file
> and included in the main document. The chapter is in a different (but
> compatible) style than the main document (the chapter uses report.cls and the
> main document uses a style that is derived from report.cls). I h
Thanks. By the way, I do prefer the official installer. Unfortunately I found
two bugs within the first minute or so:
It is up to Jose to decide whether or not a rc3 is needed, but I guess
a snapshot like this should help clear major problems. I do encourage
lyx-user users to try out the snapsho
> 1.5.0 is going to be release soon but I have compiled today's
> snapshot and put it at http://www.lyx.org/~bpeng/ (windows binary
> using the official windows installer, dictionary installation does not
> work).
Thanks. By the way, I do prefer the official installer. Unfortunately I found
two b
On 7/21/07, Lyx user <[EMAIL PROTECTED]> wrote:
It's approaching a month since the last release candidate. Could anyone please
upload a more recent Windows binary? I using rc2 and the frequent crashes are
very annoying.
1.5.0 is going to be release soon :-) but I have compiled today's
snapshot
It's approaching a month since the last release candidate. Could anyone please
upload a more recent Windows binary? I using rc2 and the frequent crashes are
very annoying. It looks like most of the bugs I'm experiencing have been fixed
in the trunk. Like most Windows users, I don't have a compiler
Abdelrazak Younes wrote:
> > BTW I could reproduce the crash and the patch fixes it for me. Also, it's
> > pretty straightforward. So ok to commit?
>
> OK.
Done so, since I'll be completely offline for the rest of the week.
Jürgen
Jürgen Spitzmüller wrote:
Jürgen Spitzmüller wrote:
Attached. John, please test.
BTW I could reproduce the crash and the patch fixes it for me. Also, it's
pretty straightforward. So ok to commit?
OK.
Abdel.
Jürgen Spitzmüller wrote:
> Attached. John, please test.
BTW I could reproduce the crash and the patch fixes it for me. Also, it's
pretty straightforward. So ok to commit?
Jürgen
John McCabe-Dansted wrote:
> To reproduce:
> 1) Press Cntl-N (start new file)
> 2) Press Alt-I, I, B (insert TOC from BibTeX)
> 3) Press Alt-A (Add...)
> 4) Double Click test
> 5) Press Alt-O (OK)
> 6) Press Alt-I C (Insert Citation)
> 7) Press Alt-A (Add)
>
> LyX now crashes
For the record, I hav
Abdelrazak Younes wrote:
> > Abdel, are you on a patch, or shall I?
>
> Go ahead.
Attached. John, please test.
Jürgen
Index: src/frontends/controllers/frontend_helpers.cpp
===
--- src/frontends/controllers/frontend_helpers.cpp (Revis
Jürgen Spitzmüller wrote:
Jürgen Spitzmüller wrote:
I guess idx + 1 is invalid.
Abdel, are you on a patch, or shall I?
Go ahead.
Jürgen Spitzmüller wrote:
> I guess idx + 1 is invalid.
Abdel, are you on a patch, or shall I?
Jürgen
John McCabe-Dansted wrote:
> Now it outputs:
>
> getAbbreviatedAuthor, authors[0]: Anon.
with the trailing dot? Then probably this line is to blame:
frontend_helpers.cpp, line 190ff.:
idx = fname.rfind('.');
if (idx != docstring::npos)
fname = ltrim(fname.substr(i
On 7/5/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
John, could you test if it really fixes the crash, just to make sure?
Doesn't seem to fix the crash. LyX seems to be fine with empty
authors. It appears to be authors that end with "." that cause the
problem. For example, I am not able to
John McCabe-Dansted wrote:
On 7/5/07, Jürgen Spitzmüller
<[EMAIL PROTECTED]> wrote:
could you add a debug statment and see what authors[0] returns, i.e. the
attached patch?
+ lyxerr << "getAbbreviatedAuthor, authors[0]: " <<
to_utf8(authors[0]) << endl;
Now it outputs:
getAbbreviatedAut
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
So, shall I commit?
I guess it cannot harm.
It's in.
John, could you test if it really fixes the crash, just to make sure?
Yes, please.
Abdel.
On 7/5/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
could you add a debug statment and see what authors[0] returns, i.e. the
attached patch?
+ lyxerr << "getAbbreviatedAuthor, authors[0]: " <<
to_utf8(authors[0]) << endl;
Now it outputs:
getAbbreviatedAuthor, authors[0]: Anon.
--
J
Abdelrazak Younes wrote:
> So, shall I commit?
I guess it cannot harm.
John, could you test if it really fixes the crash, just to make sure?
Jürgen
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
If I am right this patch should solve the issue. The question is
whether an empty author name is acceptable or not?
It is. Bibtex (and LyX) should use the key in this case.
So, shall I commit?
Abdel.
Abdelrazak Younes wrote:
> If I am right this patch should solve the issue. The question is
> whether an empty author name is acceptable or not?
It is. Bibtex (and LyX) should use the key in this case.
Jürgen
Jürgen Spitzmüller wrote:
John McCabe-Dansted wrote:
The backtrace is below:
I see. Seems it crashes here:
src/frontends/controllers/frontend_helpers.cpp (239ff):
vector const authors = getVectorFromString(author,
from_ascii("and "));
if (authors.empty())
return auth
John McCabe-Dansted wrote:
> The backtrace is below:
I see. Seems it crashes here:
src/frontends/controllers/frontend_helpers.cpp (239ff):
vector const authors = getVectorFromString(author,
from_ascii("and "));
if (authors.empty())
return author;
if (authors.size
On 7/5/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
John McCabe-Dansted wrote:
> I tried doing a make clean && make. Didn't help. I am using Fedora
> Core 6 with the following CFLAGS and gcc. Perhaps someone using
FYI, removing the CFLAGS didn't help.
> Fedora Core 6 could try to reprodu
John McCabe-Dansted wrote:
> I tried doing a make clean && make. Didn't help. I am using Fedora
> Core 6 with the following CFLAGS and gcc. Perhaps someone using
> Fedora Core 6 could try to reproduce the bug?
Could you provide a backtrace?
Jürgen
On 7/5/07, Michael Gerz <[EMAIL PROTECTED]> wrote:
I cannot reproduce this bug.
I tried doing a make clean && make. Didn't help. I am using Fedora
Core 6 with the following CFLAGS and gcc. Perhaps someone using
Fedora Core 6 could try to reproduce the bug?
In the mean while, I'll take out th
John,
I cannot reproduce this bug.
Michael
John McCabe-Dansted schrieb:
To reproduce:
1) Press Cntl-N (start new file)
2) Press Alt-I, I, B (insert TOC from BibTeX)
3) Press Alt-A (Add...)
4) Double Click test
5) Press Alt-O (OK)
6) Press Alt-I C (Insert Citation)
7) Press Alt-A (Add)
LyX no
To reproduce:
1) Press Cntl-N (start new file)
2) Press Alt-I, I, B (insert TOC from BibTeX)
3) Press Alt-A (Add...)
4) Double Click test
5) Press Alt-O (OK)
6) Press Alt-I C (Insert Citation)
7) Press Alt-A (Add)
LyX now crashes will the following error:
/usr/lib/gcc/i386-redhat-linux/4.1.1/../
Bennett Helm wrote:
As the subject says: I cannot type in a document on Mac. Command keys
work, but normal typing fails. Running with lyx -dbg key shows that key
presses are properly registered. Moreover, attempting to type results in
LyX registering the file as needing to be saved. But no adde
As the subject says: I cannot type in a document on Mac. Command keys
work, but normal typing fails. Running with lyx -dbg key shows that
key presses are properly registered. Moreover, attempting to type
results in LyX registering the file as needing to be saved. But no
added text shows up
Jean-Marc Lasgouttes wrote:
"Darren" == Darren Freeman <[EMAIL PROTECTED]> writes:
Darren> I'm not asking for confirmation of the part I just introduced,
Darren> I only just said it.
Darren> But I know what I saw and I've since reproduced it again at my
Darren> end. Whatever is causing the slow
Bug added, see http://bugzilla.lyx.org/show_bug.cgi?id=3700
Have fun,
Darren
On Tue, 2007-05-22 at 15:34 +0200, Jean-Marc Lasgouttes wrote:
> > "Darren" == Darren Freeman <[EMAIL PROTECTED]> writes:
>
> Darren> Please give me a little credit - there's been confirmations
> Darren> already.
> >> Confirmation of the complex behavior you describe? I did not see
> >> that.
On Tuesday 22 May 2007 4:08:22 pm Jean-Marc Lasgouttes wrote:
> He is on Suse. Could it be a bad clipboard interaction?
klipper has been working without problems for quite some time, but it can be
a suggestion to disable it and to see if the problem remains...
Using Fedora and kde I don't ha
> "Dov" == Dov Feldstern <[EMAIL PROTECTED]> writes:
>> That was something I tried early on - turning it off had no
>> effect.
Dov> Good. I mean, I'm glad that the bidi algorithm is not the
Dov> culprit. ;)
OTOH, at least we would have known where to search :)
JMarc
Darren Freeman wrote:
Next time, I'll make "top" always on top :)
You can also try xload, it's somewhat less intrusive.
Okay I have more to add.
In one instance I was able to get it to toggle from fast to slow by
selecting Document->TOC. It didn't speed up again with the TOC closed.
I checked the output of "top" and found my system to be 100.0% idle. (!)
And then I got it to go from slow to fast by resizing the L
Darren Freeman wrote:
On Tue, 2007-05-22 at 16:36 +0300, Dov Feldstern wrote:
I myself do not see this slowness. However, I suggest that people who
experience this try turning off the RTL option (Tools -> Preferences ->
Language settings -> Language -> Right-to-left language support). I seem
t
ith the particular document. I think
>> you just have to do a lot of (a particular kind of) editing.
>>
>> You could probably start editing the user guide at random and get
>> it to slow down.
Abdelrazak> I use 1.5.0svn everyday and I never got it to slow down on
Abdelrazak> Windows.
He is on Suse. Could it be a bad clipboard interaction?
JMarc
7;t really want to publish a partly done thesis but I don't think it
has anything to do with the particular document. I think you just have
to do a lot of (a particular kind of) editing.
You could probably start editing the user guide at random and get it to
slow down.
I use 1.5.0svn everyda
> I don't really want to publish a partly done thesis but I don't think it
> has anything to do with the particular document. I think you just have
i'm working with ~80 pages doc for a few days on slower hardware than you
indicated
and havent observed anything like that.
until there is some way
On Tue, 2007-05-22 at 16:36 +0300, Dov Feldstern wrote:
> I myself do not see this slowness. However, I suggest that people who
> experience this try turning off the RTL option (Tools -> Preferences ->
> Language settings -> Language -> Right-to-left language support). I seem
> to remember a com
On Tue, 2007-05-22 at 15:23 +0200, Pavel Sanda wrote:
> > But I know what I saw and I've since reproduced it again at my end.
> > Whatever is causing the slowdown I'm talking about, it closes with LyX
>
> is it possible to show the file you are talking about ?
I don't really want to publish a par
Hi!
I myself do not see this slowness. However, I suggest that people who
experience this try turning off the RTL option (Tools -> Preferences ->
Language settings -> Language -> Right-to-left language support). I seem
to remember a comment somewhere saying that 70% of the time is spent in
th
> "Darren" == Darren Freeman <[EMAIL PROTECTED]> writes:
Darren> Please give me a little credit - there's been confirmations
Darren> already.
>> Confirmation of the complex behavior you describe? I did not see
>> that. Nobody disputes that there is a general slowness problem.
Darren> I'm not
Darren Freeman wrote:
On Tue, 2007-05-22 at 14:24 +0200, Abdelrazak Younes wrote:
Darren Freeman wrote:
I restarted LyX and created a new document - problem is gone. Even after
opening my thesis, problem isn't apparent. It looks like you may have to
do actual editing of an actual thesis to repr
Stefan Schimanski wrote:
Some profiling on Mac with Qt 4.2.x tells me:
* 18% QPainter::drawTextItem
* 18% QTextEngine::shape
* 70% paintPar (includes the upper two)
* 11% updateMetrics
So 70% of the whole painting process goes into paintPar. Am I wrong that
this part would go down more or less
> But I know what I saw and I've since reproduced it again at my end.
> Whatever is causing the slowdown I'm talking about, it closes with LyX
is it possible to show the file you are talking about ?
pavel
On Tue, 2007-05-22 at 14:48 +0200, Jean-Marc Lasgouttes wrote:
> > "Darren" == Darren Freeman <[EMAIL PROTECTED]> writes:
>
> >> Yep. I really don't understand what could be the cause of the
> >> problem you're describing. I'd say it's not LyX fault but perhaps
> >> some other program that is
Some profiling on Mac with Qt 4.2.x tells me:
* 18% QPainter::drawTextItem
* 18% QTextEngine::shape
* 70% paintPar (includes the upper two)
* 11% updateMetrics
So 70% of the whole painting process goes into paintPar. Am I wrong
that this part would go down more or less linearly in the number o
> "Darren" == Darren Freeman <[EMAIL PROTECTED]> writes:
>> Yep. I really don't understand what could be the cause of the
>> problem you're describing. I'd say it's not LyX fault but perhaps
>> some other program that is slowing down your computer.
Darren> ROFL! Oh wait, you're serious. :(
D
On Tue, 2007-05-22 at 14:24 +0200, Abdelrazak Younes wrote:
> Darren Freeman wrote:
> > I restarted LyX and created a new document - problem is gone. Even after
> > opening my thesis, problem isn't apparent. It looks like you may have to
> > do actual editing of an actual thesis to reproduce this!
Stefan Schimanski wrote:
Looking through the painting code... Is there a good reason that we
don't do partial redraws while scrolling?
Theoretically no. In practice, the way we do painting is inherited from
the multi-frontend approach. There are certainly things that can be
optimized.
I mea
Darren Freeman wrote:
Further to my earlier email, I suspect that the slowness is due to
gradually accumulating cruft in internal data structures. Maybe not a
memory leak but conceptually similar, possibly fragmentation or lists
that accumulate stale junk.
I had my thesis open, and editing was s
Stefan Schimanski wrote:
Looking through the painting code... Is there a good reason that we
don't do partial redraws while scrolling? I mean a lot of the screen
might be repaintable by just bitblt'ing the old image a bit upwards or
downwards. For the usual cursor movement this is not that impo
al work?
Darren> Shouldn't that option be disabled by default? Developers can
Darren> be trusted to enable it if needed.
In beta releases and release candidates (and stable releases of
course), this is turned off by default. In 1.5.0svn mode it is on. The
option is very useful because it detects some bugs we would not see
otherwise.
JMarc
Further to my earlier email, I suspect that the slowness is due to
gradually accumulating cruft in internal data structures. Maybe not a
memory leak but conceptually similar, possibly fragmentation or lists
that accumulate stale junk.
I had my thesis open, and editing was so slw. I created
On Tue, 2007-05-22 at 10:13 +0200, Jean-Marc Lasgouttes wrote:
> > "Darren" == Darren Freeman <[EMAIL PROTECTED]> writes:
>
> Darren> Hi all, I know this was/is_being discussed in some form or
> Darren> another but I want to weigh in.
>
> Darren> On my system, AthlonXP3000+ w/ 1GB RAM, OpenSU
Looking through the painting code... Is there a good reason that we
don't do partial redraws while scrolling? I mean a lot of the screen
might be repaintable by just bitblt'ing the old image a bit upwards
or downwards. For the usual cursor movement this is not that
important because it is s
> "Darren" == Darren Freeman <[EMAIL PROTECTED]> writes:
Darren> Hi all, I know this was/is_being discussed in some form or
Darren> another but I want to weigh in.
Darren> On my system, AthlonXP3000+ w/ 1GB RAM, OpenSUSE 10.2, I find
Darren> the SVN to be rather slow. I've jumped from the 1.3
On Tue, 2007-05-22 at 08:14 +0200, Anders Ekberg wrote:
> > Darren Freeman
> > A couple hundred milliseconds per mouse wheel scroll click isn't okay,
> > dammit!
> Did you try to compile with QT4.3 (pre-version)?
>
> At least on a Mac it improves things with about 30% (as compared to
> 4.2.x).
Am 22.05.2007 um 08:14 schrieb Anders Ekberg:
Darren Freeman
Mon, 21 May 2007 20:05:26 -0700
Hi all,
I know this was/is_being discussed in some form or another but I
want to
weigh in.
On my system, AthlonXP3000+ w/ 1GB RAM, OpenSUSE 10.2, I find the
SVN to
be rather slow. I've jumped fr
Darren Freeman
Mon, 21 May 2007 20:05:26 -0700
Hi all,
I know this was/is_being discussed in some form or another but I
want to
weigh in.
On my system, AthlonXP3000+ w/ 1GB RAM, OpenSUSE 10.2, I find the
SVN to
be rather slow. I've jumped from the 1.3/XForms world into the 1.5/Qt4
and can
Hi all,
I know this was/is_being discussed in some form or another but I want to
weigh in.
On my system, AthlonXP3000+ w/ 1GB RAM, OpenSUSE 10.2, I find the SVN to
be rather slow. I've jumped from the 1.3/XForms world into the 1.5/Qt4
and can hardly believe the change in performance.
A couple hu
Leuven, E. wrote:
one for the lyx2lyx people? i get:
Warning: 271: Format not supported.
Warning: Quiting.
Error: Conversion script failed
svn update.
Abdel.
> "John" == John McCabe-Dansted <[EMAIL PROTECTED]> writes:
John> Hi when I try to open this file:
John> http://www.csse.uwa.edu.au/~john/lyx/corrupted.lyx.gz I get the
John> error /home/res/john/WWW/lyx/corrupted.lyx.gz ended
John> unexpectedly, which means that it is probably corrupted.
Joh
convert it.
-Original Message-
From: John McCabe-Dansted [mailto:[EMAIL PROTECTED]
Sent: Wed 5/16/07 14:18
To: LyX Developers List
Subject: Data Corruption with LyX 1.5.0svn?
Hi when I try to open this file:
http://www.csse.uwa.edu.au/~john/lyx/corrupted.lyx.gz
I get the error
maybe someone would like to
see if it could have been caused by a bug in lyx 1.5.0svn?
--
John C. McCabe-Dansted
PhD Student
University of Western Australia
> "Timothy" == Timothy Reaves <[EMAIL PROTECTED]> writes:
Timothy> Any idea's as to why I'm getting the following?
Timothy> cat qt4_l10n.pot layouts_l10n.pot languages_l10n.pot
Timothy> ui_l10n.pot
Timothy> | \ msguniq -o LyX-1.5.po && rm -f qt4_l10n.pot
Timothy> layouts_l10n.pot languages_l
José Matos wrote:
On Monday 07 May 2007 19:41:26 Timothy Reaves wrote:
So not only is there the issue with the .po file, now this:
Making all in src
make[1]: *** No rule to make target `version.C.in', needed by
`version.C-tmp'. Stop.
make: *** [all-recursive] Error 1
Please start fro
Updated and compiled about one hour ago and it compiles fine (with
QT4.3 snapshot 6th of May and on a PPC).
Have you made a fresh svn-download after the file renaming? That is
probably needed (at least I needed one some days ago when nothing
worked).
Anders Ekberg
On Monday 07 May 2007 19:41:26 Timothy Reaves wrote:
> So not only is there the issue with the .po file, now this:
> Making all in src
> make[1]: *** No rule to make target `version.C.in', needed by
> `version.C-tmp'. Stop.
> make: *** [all-recursive] Error 1
Please start from a fresh dire
So not only is there the issue with the .po file, now this:
Making all in src
make[1]: *** No rule to make target `version.C.in', needed by `version.C-tmp'.
Stop.
make: *** [all-recursive] Error 1
Guy Rutenberg wrote:
Timothy Reaves <[EMAIL PROTECTED]> writes:
Any idea's as to why I'm getting the following?
Dusty >
Hi, I had the same problem and I found the following workaround:
echo "" > po/language_i18n.pot
emptying the above file seems to fix the compilation problem, I guess
Timothy Reaves <[EMAIL PROTECTED]> writes:
Any idea's as to why I'm getting the following?
cat qt4_l10n.pot layouts_l10n.pot languages_l10n.pot ui_l10n.pot | \
msguniq -o LyX-1.5.po && rm -f qt4_l10n.pot layouts_l10n.pot
languages_l10n.pot
ui_l10n.pot
msguniq: found 4 fatal errors
make[3
Timothy Reaves <[EMAIL PROTECTED]> writes:
>
> Any idea's as to why I'm getting the following?
>
>
> Dusty >
>
>
Hi, I had the same problem and I found the following workaround:
echo "" > po/language_i18n.pot
emptying the above file seems to fix the compilation problem, I guess it will
ha
Any idea's as to why I'm getting the following?
cat qt4_l10n.pot layouts_l10n.pot languages_l10n.pot ui_l10n.pot | \
msguniq -o LyX-1.5.po && rm -f qt4_l10n.pot layouts_l10n.pot languages_l10n.pot
ui_l10n.pot
msguniq: : warning: Charset missing in header.
Message co
On Apr 26, 2007, at 11:24 AM, Andre Poenitz wrote:
On Thu, Apr 26, 2007 at 10:22:22AM -0400, Richard Heck wrote:
Bennett Helm wrote:
And I am getting this on a clean svn co. It looks as if there was
a plan
to change LCursor.h to Cursor.h, but that said plan wasn't
executed. Can
someone co
On Thu, Apr 26, 2007 at 10:22:22AM -0400, Richard Heck wrote:
> Bennett Helm wrote:
>
> And I am getting this on a clean svn co. It looks as if there was a plan
> to change LCursor.h to Cursor.h, but that said plan wasn't executed. Can
> someone confirm and fix this?
The plan has been executed no
Bennett Helm wrote:
And I am getting this on a clean svn co. It looks as if there was a plan
to change LCursor.h to Cursor.h, but that said plan wasn't executed. Can
someone confirm and fix this?
> Making all in controllers
> make all-recursive
> Making all in tests
> make all-am
> make[8]: Nothin
On Apr 26, 2007, at 10:05 AM, Richard Heck wrote:
Bennett Helm wrote:
I can't get LyX to compile with current svn (after running
./autogen.sh and reconfiguring). I get the following error:
make[7]: *** No rule to make target `Dialog.C', needed by
`Dialog.lo'. Stop.
Any suggestions?
I saw th
Bennett Helm wrote:
> I can't get LyX to compile with current svn (after running
> ./autogen.sh and reconfiguring). I get the following error:
>
> make[7]: *** No rule to make target `Dialog.C', needed by
> `Dialog.lo'. Stop.
>
> Any suggestions?
I saw this problem, too. make clean, and manually r
I can't get LyX to compile with current svn (after running ./
autogen.sh and reconfiguring). I get the following error:
make[7]: *** No rule to make target `Dialog.C', needed by
`Dialog.lo'. Stop.
Any suggestions?
Bennett
>>>>> "John" == John McCabe-Dansted <[EMAIL PROTECTED]> writes:
John> The current version of LyX-gc uses the '»' and '«' UTF symbols
John> to mark where the error occurs in the ChKTeX style output. Since
John> round beginning of April, 1
The current version of LyX-gc uses the '»' and '«' UTF symbols to mark
where the error occurs in the ChKTeX style output. Since round
beginning of April, 1.5.0svn stops parsing the ChKTeX input once it
reaches such these non-ASCII symbols.
I don't know whether this i
Ya, the import took care of the issue.
Richard Heck wrote:
This is from something I checked in, probably, unless headers have been
changed elsewhere. I don't have this problem on Linux. Is this on OSX?
In any event, can you try adding:
#include
to the headers in src/frontends/qt4/QParagraphDi
Today's svn-version (Revision: 17807) compiled fine on Mac PPC (OSX
10.4.8). However, there have been some shaky versions in the last
weeks so I have needed to do make clean at some occasions. Also, I
have QT 4.2.3 (with the newly released security patch) and not 4.2.0
if that could be a re
This is from something I checked in, probably, unless headers have been
changed elsewhere. I don't have this problem on Linux. Is this on OSX?
In any event, can you try adding:
#include
to the headers in src/frontends/qt4/QParagraphDialog.C and see if that
fixes the problem?
Alternatively, can s
The last couple svn versions have faild to compile because of this.
g++-4 -DHAVE_CONFIG_H -I. -I. -I../../../src -DQT_CLEAN_NAMESPACE
-DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -I../../../src
-I../../../src/frontends -I../../../images -DQT_SHARED
-I/usr/local/Trolltech/Qt-4.2.0/include
-I
Bennett Helm wrote:
--snip--
Well, this failes on both parts:
1) using the "open -a PDFSync.app $$i" doesn't open PDFSync.app (I
tried /Applications/PDFSync.app too). If I change the default PDF
viewer to PDFView, and LyX back to auto, then it does use auto.
2) command-click doesn't do a
On Apr 9, 2007, at 12:58 AM, Timothy Reaves wrote:
Timothy Reaves wrote:
Bennett Helm wrote:
On Apr 8, 2007, at 11:00 AM, Timothy Reaves wrote:
Bennett Helm wrote:
On Apr 7, 2007, at 10:31 PM, Timothy Reaves wrote:
What is the correct way to set up pdfsync with the 1.5
branch? More
Timothy Reaves wrote:
Bennett Helm wrote:
On Apr 8, 2007, at 11:00 AM, Timothy Reaves wrote:
Bennett Helm wrote:
On Apr 7, 2007, at 10:31 PM, Timothy Reaves wrote:
What is the correct way to set up pdfsync with the 1.5
branch? More specifically, PDFView.
In PDFView's preferences, use a
Bennett Helm wrote:
On Apr 8, 2007, at 11:00 AM, Timothy Reaves wrote:
Bennett Helm wrote:
On Apr 7, 2007, at 10:31 PM, Timothy Reaves wrote:
What is the correct way to set up pdfsync with the 1.5 branch?
More specifically, PDFView.
In PDFView's preferences, use a custom preset for PDFS
On Apr 8, 2007, at 11:00 AM, Timothy Reaves wrote:
Bennett Helm wrote:
On Apr 7, 2007, at 10:31 PM, Timothy Reaves wrote:
What is the correct way to set up pdfsync with the 1.5
branch? More specifically, PDFView.
In PDFView's preferences, use a custom preset for PDFSync support,
with
Bennett Helm wrote:
On Apr 7, 2007, at 10:31 PM, Timothy Reaves wrote:
What is the correct way to set up pdfsync with the 1.5 branch?
More specifically, PDFView.
In PDFView's preferences, use a custom preset for PDFSync support, with
the following entries:
/Applications/LyX.app/Conte
On Apr 7, 2007, at 10:31 PM, Timothy Reaves wrote:
What is the correct way to set up pdfsync with the 1.5
branch? More specifically, PDFView.
In PDFView's preferences, use a custom preset for PDFSync support,
with the following entries:
/Applications/LyX.app/Contents/MacOS/lyxeditor
What is the correct way to set up pdfsync with the 1.5 branch? More
specifically, PDFView.
thanks.
BTW, rerunning ./autogen.sh and ./configure seems to have fixed this
problem for me.
This has been the case for many autotools-related problems here. If
you prefer a no-autogen.sh, no-configure.py solution, you can try the
scons build system. Read INSTALL.scons for details.
Cheers,
Bo
1 - 100 of 278 matches
Mail list logo
