More Bugs in Lyx 1.3.6 (Windows)
Hei once more! I have found some problems regarding viewing PDFs (with v.9) (others than previously reported, I think). 1) When View-PDF is called, ps2pdf -dCompatibilityLevel=1.3 newfile1.ps is called in turn. This call fails with the following error message: Unrecoverable error: typecheck in .putdeviceprops I have not investigated too much, but the problem is with the -dCompatibilityLevel=1.3 swithc. If ps2pdf is called without options it works fine. I guess ps2pdf13 could be called instead? Be sure there is not a pdf already in the temp directory. 2) When a pdf already exists in the temp directory, which is already loaded in Acrobat, and View-PDF(dvipdfm) is called, the user gets this error: Cannot convert file. Error while executing dvipdfm The debugging message is: Unable to open newfile1.pdf The problem is that dvipdfm cannot overwrite the file (if I am not wrong). Is there no way to give the end-user a clearer hint about what is happening, that is, that a pdf already exists and it is loaded in acrobat? Then the user can choose to close acrobat and call View-PDF again. With the cannot convert file error message the user thinks something is wrong with LyX and does not realise the file is already loaded in Acrobat. A similar error happens if we call View/Update-PDF(pdflatex) while the pdf file is already loaded in Acrobat Nicolás
Re: lyx2lyx --try-hard
Jose' Matos wrote: Are you volunteering yourself to do this work? ;-) I am a bit short on time right now, but if nobody beats me I may do so in a couple of days. Georg
Re: [PATCH] reduce drastically number of calls to LyXText::getFont
Angus Leeming [EMAIL PROTECTED] writes:
| Jean-Marc Lasgouttes wrote:
Jean-Marc You mean that code like if (FOO_NOT_AVAILABLE) { // use
Jean-Marc function bar() instead x = bar(); } else { x= foo();
Jean-Marc }
Jean-Marc will compile when foo() does not exist on the system? I am
Jean-Marc surprised.
I see now that the GNU coding standard recommend this use of if(). I
still do not like the fact that it is not obvious from the code that
only one path will be followed.
| Please use the #if FOO_NOT_AVAILABLE version. Everything else is just
| playing silly buggers.
Not that I know what a silly buffer is, but I don't agree.
In this case though #if FOO is good.
--
Lgb
Re: [PATCH] reduce drastically number of calls to LyXText::getFont
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | To conclude, can I apply the following patches, or do you want to do | some testing first? No, go ahead. -- Lgb
Re: Bug in Lyx 1.3.6 (Windows)
Angus Leeming [EMAIL PROTECTED] writes: I've posted a message to the NSIS forum, so let's see what they do with it. http://forums.winamp.com/forumdisplay.php?s=forumid=65 | I got an answer. It transpires that the fault was mine. Ahhh well. Mea | culpa. But what was the error? -- Lgb
Re: patch for scrclass.inc
G. Milde wrote: The koma environment labeling is virtually equivalent to the lyxlist, so both should mapt to the same paragraph style List. I do not agree to change the name from Labeling to List in the GUI. Jürgen
Re: Bug in Lyx 1.3.6 (Windows)
Lars Gullik Bjønnes wrote:
I've posted a message to the NSIS forum, so let's see what they do with
it. http://forums.winamp.com/forumdisplay.php?s=forumid=65
| I got an answer. It transpires that the fault was mine. Ahhh well. Mea
| culpa.
But what was the error?
Text and DirRequest widgets expect different string formats:
Text: foo\r\nbar C:\\tbar
DirRequest: C:\tbar and while we're at it foo$\r$\nbar
It's inconsistent, but it is documented. See the reply I got at
http://forums.winamp.com/forumdisplay.php?s=forumid=65
We can convert from one format to the other with
${StrNSISToIO} $0 '$PathPrefix'
which fills the register $0 with the contents of $PathPrefix, making
the necessary transformations.
Angus
LyX/Win 1.3.6 bug report: buffer overrun, can't find layout description
At the very last step of the LyX setup, just before the dialogue box that says Completing the LyX Setup Wizard Congratulations! LyX has been installed successfully. I had a window appear which said the following: Microsoft Visual C++ Runtime Library Program C:\miktex\main\miktex\bin\latex.exe A buffer overrun has been detected which has corrupted the program's internal state. The program cannot safely continue to execute and must now be terminated. This was right after it was asking me to download a package. I don't know if this has anything to do with LyX or the LyX installer, but I thought I would report it anyway. Ahh! Then at the very next step (Launch LyX) I get this: LyX wasn't able to find any layout description! Check the contents of the file 'textclass.lst' Sorry, has to exit I guess I'll look through the archive to see whether this has come up already. But if someone knows a fix, please let me know! All best, djb
Re: patch for scrclass.inc
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes: Juergen G. Milde wrote: The koma environment labeling is virtually equivalent to the lyxlist, so both should mapt to the same paragraph style List. Juergen I do not agree to change the name from Labeling to List Juergen in the GUI. Could you be more specific? I was about to accept the patch :) JMarc
Re: LyX meeting in Paris. What about July 14-18?
Martin == Martin Vermeer [EMAIL PROTECTED] writes: Assuming this is 'hard' now... I'll book my tickets tomorrow evening. Martin This sounds so simple, doesn't it... Did you finally succeed? JMarc
Re: lyx1.4cvs bug, GUI scrolling affects the generated latex :-(
Now also registered as bug 1904. Helge Hafting
More about LyX meeting
So, I know have the following table for our next meeting: 13 14 15 16 17 18 19 Lars X X X X X X X (some extra vacation) AndréX X X X X Michael X X Juergen X X X X X José X X X X X X Won't come after all: Asger Who else has made up his mind? Also, for my own organization purposes, I'd appreciate to know who will come with a laptop. I am not sure we want to have one computer per person, but we need a large enough number. JMarc
Re: patch for scrclass.inc
Jean-Marc Lasgouttes wrote: Juergen I do not agree to change the name from Labeling to List Juergen in the GUI. Could you be more specific? I was about to accept the patch :) I really do not like that we are beginning to replace the termini technici of LaTeX classes and environments with arbitrary names (or translations, for that matter) if there is no special need to do so. There are not only LaTeX agnostics using LyX. For people who are familiar with the KOMA script documentation, the term Labeling is well defined, while List is just irritating. To put it different: I think people who are using KOMA-classes in LyX should be encouraged to read the excellent KOMA-script documentation (the LyX documentation can never replace that). But if the KOMA-script documentation recommends to use the environments which can not be found in LyX, because LyX has its own terminology, it gets useless. Jürgen
Re: More about LyX meeting
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | So, I know have the following table for our next meeting: | 13 14 15 16 17 18 19 | Lars X X X X X X X (some extra vacation) | AndréX X X X X | Michael X X | Juergen X X X X X | José X X X X X X | Won't come after all: Asger | Who else has made up his mind? Also, for my own organization purposes, | I'd appreciate to know who will come with a laptop. I'll bring a laptop. Please tell if you need me to bring any other networking equip. -- Lgb
Re: [PATCH] Bug 961: reintroduce LFUN_BIBDB_ADD/DEL
Jean-Marc Lasgouttes wrote:
My point is that the behaviour of getInsetByCode is intended and
should be left alone.
OK, then the comment to the function is at least misleading. How about the
following (I know that it is not exactly what you are looking for, but I do
not see the need in changing gotoInset now).
Jürgen
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.587
diff -u -r1.587 BufferView_pimpl.C
--- BufferView_pimpl.C 9 Jun 2005 09:58:03 - 1.587
+++ BufferView_pimpl.C 10 Jun 2005 08:36:21 -
@@ -51,6 +51,7 @@
#include undo.h
#include vspace.h
+#include insets/insetbibtex.h
#include insets/insetref.h
#include insets/insettext.h
@@ -122,7 +123,7 @@
boost::signals::connection lostcon;
-/// Get next inset of this class from current cursor position
+/// Return an inset of this class if it exists at the current cursor position
template class T
T * getInsetByCode(LCursor cur, InsetBase::Code code)
{
@@ -135,6 +136,31 @@
return inset;
}
+
+/// Get next inset of this class from current cursor position
+template class T
+T * findInset(LCursor cur, InsetBase::Code code)
+{
+ T * inset = 0;
+ DocIterator it = cur;
+ T * first_inset = static_castT*(it.nextInset());
+ while (it) {
+ if (!it.nextInset()) {
+ // try from the beginning, but break after one loop
+ it.pit() = 0;
+ it.pos() = 0;
+ if (!it.nextInset() || it.nextInset() == first_inset)
+break;
+ }
+ if (it.nextInset()-lyxCode() == code) {
+ inset = static_castT*(it.nextInset());
+ break;
+ }
+ it.forwardInset();
+ }
+ return inset;
+}
+
} // anon namespace
@@ -982,6 +1008,8 @@
case LFUN_MARK_ON:
case LFUN_SETMARK:
case LFUN_CENTER:
+ case LFUN_BIBDB_ADD:
+ case LFUN_BIBDB_DEL:
case LFUN_WORDS_COUNT:
flag.enabled(true);
break;
@@ -1212,6 +1240,22 @@
case LFUN_CENTER:
center();
break;
+
+ case LFUN_BIBDB_ADD: {
+ InsetBibtex * inset =
+ findInsetInsetBibtex(cursor_, InsetBase::BIBTEX_CODE);
+ if (inset)
+ inset-addDatabase(cmd.argument);
+ break;
+ }
+
+ case LFUN_BIBDB_DEL: {
+ InsetBibtex * inset =
+ findInsetInsetBibtex(cursor_, InsetBase::BIBTEX_CODE);
+ if (inset)
+ inset-delDatabase(cmd.argument);
+ break;
+ }
case LFUN_WORDS_COUNT: {
DocIterator from, to;
Index: LyXAction.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/LyXAction.C,v
retrieving revision 1.206
diff -u -r1.206 LyXAction.C
--- LyXAction.C 8 May 2005 10:02:37 - 1.206
+++ LyXAction.C 10 Jun 2005 08:36:22 -
@@ -188,6 +188,8 @@
{ LFUN_INSERT_LABEL, label-insert, Noop },
{ LFUN_INSET_OPTARG, optional-insert, Noop },
{ LFUN_INSERT_BIBITEM, bibitem-insert, Noop },
+ { LFUN_BIBDB_ADD, bibtex-database-add, Noop },
+ { LFUN_BIBDB_DEL, bibtex-database-del, Noop },
{ LFUN_INSERT_LINE, line-insert, Noop },
{ LFUN_INSERT_PAGEBREAK, pagebreak-insert, Noop },
{ LFUN_LANGUAGE, language, Noop },
Index: lfuns.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lfuns.h,v
retrieving revision 1.41
diff -u -r1.41 lfuns.h
--- lfuns.h 8 May 2005 10:02:37 - 1.41
+++ lfuns.h 10 Jun 2005 08:36:24 -
@@ -355,6 +355,8 @@
// 270
LFUN_WORDS_COUNT,
LFUN_OUTPUT_CHANGES, // jspitzm 20050121
+ LFUN_BIBDB_ADD,
+ LFUN_BIBDB_DEL,
LFUN_LASTACTION // end of the table
};
Index: insets/insetbibtex.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetbibtex.C,v
retrieving revision 1.54
diff -u -r1.54 insetbibtex.C
--- insets/insetbibtex.C 17 May 2005 11:11:45 - 1.54
+++ insets/insetbibtex.C 10 Jun 2005 08:36:37 -
@@ -271,7 +271,7 @@
bool InsetBibtex::addDatabase(string const db)
{
string contents(getContents());
- if (!contains(contents, db)) {
+ if (tokenPos(contents, ',', db) == -1) {
if (!contents.empty())
contents += ',';
setContents(contents + db);
@@ -283,16 +283,17 @@
bool InsetBibtex::delDatabase(string const db)
{
- if (contains(getContents(), db)) {
+ string contents(getContents());
+ if (contains(contents, db)) {
+ int const n = tokenPos(contents, ',', db);
string bd = db;
- int const n = tokenPos(getContents(), ',', bd);
if (n 0) {
- // Weird code, would someone care to explain this?(Lgb)
- string tmp(, );
- tmp += bd;
- setContents(subst(getContents(), tmp, , ));
+ // this is not the first database
+ string tmp = ',' + bd;
+ setContents(subst(contents, tmp, ));
} else if (n == 0)
- setContents(split(getContents(), bd, ','));
+ // this is the first (or only) database
+ setContents(split(contents, bd, ','));
else
return false;
}
Re: patch for scrclass.inc
Juergen Spitzmueller wrote: [reasons not to replace LaTeX names] I second that. Georg
Re: More about LyX meeting
On Friday 10 June 2005 09:25, Jean-Marc Lasgouttes wrote: Who else has made up his mind? Also, for my own organization purposes, I'd appreciate to know who will come with a laptop. I am not sure we want to have one computer per person, but we need a large enough number. I will carry my laptop. :-) JMarc -- José Abílio
Re: lyx1.4cvs bug, GUI scrolling affects the generated latex :-(
Helge Hafting wrote: Now also registered as bug 1904. I can reproduce the bug. I have uploaded our testcase to bugzilla. Jürgen
Re: The LyX licence
On Friday 10 June 2005 10:46, you wrote: I forgot to ask you to drop an email to the lyx-devel list stating explicitly that you agree to licence you contribution under the terms of the Gnu General Public Licence version 2 or later. I hereby licence my contributions to LyX under the Gnu General Public Licence version 2 or later. Can I have a spellcheck-as-you-go feature for LyX now? ;-) Janus Sandsgaard -- Roskilde University, Denmark. Department of Technology and Social Science. International Development Studies. ESST - Society, Science and Technology in Europe.
Re: The LyX licence
Janus Sandsgaard [EMAIL PROTECTED] writes: | I hereby licence my contributions to LyX under the Gnu General Public Licence | version 2 or later. | Can I have a spellcheck-as-you-go feature for LyX now? ;-) You have to contribute it first :-) -- Lgb
Re: Qt/WinFree bugs
Angus Leeming wrote:
Michael Schmitt wrote:
Dear Christian and all Qt developers,
I would like to tell you that the LyX team has released a series of
pre-releases for LyX 1.3.6 on Windows.
You can find the latest version at
http://wiki.lyx.org/Windows/LyX136pre
The LyX community has also generated a short list of Qt/WinFree bugs
which you can find on the same page.
Section Apparent Qt/WinFree bugs at the bottom of the page.
I've attached two tiny programs that demonstrate two of the bugs. Maybe
they'll help...
I think that the attached program demonstrates two bugs. One, definitely,
in Qt/WinFree and one, possibly, in LyX.
The problem lies with the QFont style hint (which isn't useful on *nix
because the OS doesn't support it). On my WinXP box, the compiled program
returns:
Serif: Arial [MS]
SansSerif: Arial [MS]
TypeWriter: Arial [MS]
I think that the Qt/WinFree bug is clear; different style hints should
return different fonts.
The LyX bug, if bug it is, is a little more subtle. Other Qt libraries (eg
Qt Non-Commercial 3.2.1) apparently return the font name without the
foundary on QFontInfo::family(). Ie, Arial rather than Arial [MS].
It's trivial for me to handle this difference but I'd like to establish
what Qt/WinFree *should* be returning here. The docs don't make it clear,
to me at least.
Regards,
Angus
#include qapplication.h
#include qpushbutton.h
#include cstdlib
#include iostream
#include sstream
#include string
using std::string;
template class Target, class Source
Target convert(Source arg);
template
int convertint(char * cptr)
{
return strtol(cptr, 0, 10);
}
int usage(string const name)
{
std::cerr Usage: name
[1-3]\nwhere 1==times,2==helvetica,3==courier\n;
return 1;
}
int main( int argc, char **argv )
{
if (argc != 2)
return usage(argv[0]);
int const choice = convertint(argv[1]);
QFont::StyleHint font_hint = QFont::Serif;
string font_name = Serif;
switch (choice) {
case 1:
font_hint = QFont::Serif;
font_name = Serif;
break;
case 2:
font_hint = QFont::SansSerif;
font_name = SansSerif;
break;
case 3:
font_hint = QFont::TypeWriter;
font_name = TypeWriter;
break;
default:
return usage(argv[0]);
}
QApplication a( argc, argv );
// Try the hint
QFont font;
font.setStyleHint(font_hint);
QFontInfo fi(font);
std::ostringstream ss;
ss font_name = fi.family();
QPushButton hello( ss.str(), 0 );
hello.resize( 200, 30 );
a.setMainWidget( hello );
hello.show();
return a.exec();
}
Re: The LyX licence
On Friday 10 June 2005 10:54, Lars Gullik Bjønnes wrote: You have to contribute it first :-) I'd be happy to contribute with a manual for it! :-) -j -- Roskilde University, Denmark. Department of Technology and Social Science. International Development Studies. ESST - Society, Science and Technology in Europe.
Re: The LyX licence
Janus Sandsgaard wrote: On Friday 10 June 2005 10:46, you wrote: I forgot to ask you to drop an email to the lyx-devel list stating explicitly that you agree to licence you contribution under the terms of the Gnu General Public Licence version 2 or later. I hereby licence my contributions to LyX under the Gnu General Public Licence version 2 or later. Thank you. Can I have a spellcheck-as-you-go feature for LyX now? ;-) Sure. Just roll your sleeves up and contribute a little more :-P Janus Sandsgaard Angus
Re: LyX/Win 1.3.6 bug report: buffer overrun, can't find layout description
David Boutillier wrote: At the very last step of the LyX setup, just before the dialogue box that says Completing the LyX Setup Wizard Congratulations! LyX has been installed successfully. I had a window appear which said the following: Microsoft Visual C++ Runtime Library Program C:\miktex\main\miktex\bin\latex.exe A buffer overrun has been detected which has corrupted the program's internal state. The program cannot safely continue to execute and must now be terminated. This was right after it was asking me to download a package. I don't know if this has anything to do with LyX or the LyX installer, but I thought I would report it anyway. Ahh! Then at the very next step (Launch LyX) I get this: LyX wasn't able to find any layout description! Check the contents of the file 'textclass.lst' Sorry, has to exit I guess I'll look through the archive to see whether this has come up already. But if someone knows a fix, please let me know! cd C:\Program Files\LyX\Resources\lyx path to\sh.exe configure --without-latex-config Thereafter, try the latex configuration again (sh configure) and see if your latex problems continue. Angus
Re: More Bugs in Lyx 1.3.6 (Windows)
Nicolás wrote: Hei once more! I have found some problems regarding viewing PDFs (with v.9) (others than previously reported, I think). 1) When View-PDF is called, ps2pdf -dCompatibilityLevel=1.3 newfile1.ps is called in turn. This call fails with the following error message: Unrecoverable error: typecheck in .putdeviceprops I have not investigated too much, but the problem is with the -dCompatibilityLevel=1.3 swithc. If ps2pdf is called without options it works fine. I guess ps2pdf13 could be called instead? Jean-Marc? Be sure there is not a pdf already in the temp directory. 2) When a pdf already exists in the temp directory, which is already loaded in Acrobat, and View-PDF(dvipdfm) is called, the user gets this error: Cannot convert file. Error while executing dvipdfm The debugging message is: Unable to open newfile1.pdf The problem is that dvipdfm cannot overwrite the file (if I am not wrong). Is there no way to give the end-user a clearer hint about what is happening, that is, that a pdf already exists and it is loaded in acrobat? Then the user can choose to close acrobat and call View-PDF again. With the cannot convert file error message the user thinks something is wrong with LyX and does not realise the file is already loaded in Acrobat. A similar error happens if we call View/Update-PDF(pdflatex) while the pdf file is already loaded in Acrobat I don't think that there's anythng we can do about this. You could try submitting a bug report to Adobe asking them not to be so rude as to keep the HANDLE on the file open... Nicolás Angus
Re: More Bugs in Lyx 1.3.6 (Windows)
Nicolás a écrit: 2) When a pdf already exists in the temp directory, which is already loaded in Acrobat, and View-PDF(dvipdfm) is called, the user gets this error: Cannot convert file. Error while executing dvipdfm The debugging message is: Unable to open newfile1.pdf This is an acrobat specific problem. Acrobat/acroread denys writing access on openened pdf-files because it is designed to change files (add links, set the crop box etc.). This problem don't appear when using gsview as this is designed as a pdf-viewer. regards Uwe
1.3.6 Windows pre Help not working
Hello, in yesterday's version (9). Is the documentationnot included?
Re: More Bugs in Lyx 1.3.6 (Windows)
Angus Leeming wrote: A similar error happens if we call View/Update-PDF(pdflatex) while the pdf file is already loaded in Acrobat I don't think that there's anythng we can do about this. You could try submitting a bug report to Adobe asking them not to be so rude as to keep the HANDLE on the file open... Fabrice Popineau's fpTeX distribution for windows (http://www.fptex.org/) contains the pdfopen and pdfclose commands which are working around this. A UNIX port (xpdfopen) has been released recently (I didn't test either one). Jürgen
Re: More about LyX meeting
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars I'll bring a laptop. Please tell if you need me to bring any Lars other networking equip. I think I will find the necessary stuff, but I'll ask otherwise. JMarc
Re: More about LyX meeting
Jose' == Jose' Matos [EMAIL PROTECTED] writes: Jose' I will carry my laptop. :-) Noted. JMarc PS: what is so funny about it? Especially on a friday.
Re: More Bugs in Lyx 1.3.6 (Windows)
Angus Leeming wrote: Nicolás wrote: Hei once more! 2) When a pdf already exists in the temp directory, which is already loaded in Acrobat, and View-PDF(dvipdfm) is called, the user gets this error: Cannot convert file. Error while executing dvipdfm ... I don't think that there's anythng we can do about this. You could try submitting a bug report to Adobe asking them not to be so rude as to keep the HANDLE on the file open... I do not expect Adobe to do that (do you?) :-) What I was, indeed, trying to propose is to present a more helpful error message to the end-user. Something that could indicate him/her what to do to solve the problem. I guess it would not be difficult to check first if the file already exists and set a flag to true. Then try to overwrite and if an error arises, and the flag was set to true, report to the end-user that the file may already be opened with Acrobat, and that he/she may try to close it and call again View-PDF Nicolás
Re: 1.3.6 Windows pre Help not working
Jean-Claude Christnach wrote: Hello, in yesterday's version (9). Is the documentationnot included? No. I have just built a snapshot from the CVS repository. When Jean-Marc comes to release 1.3.6 proper, he'll add the docs. Thereafter, I'll grab his release to build the Windows installer. Regards, Angus
Re: More Bugs in Lyx 1.3.6 (Windows)
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Nicolás wrote: Hei once more! I have found some problems regarding viewing PDFs (with v.9) (others than previously reported, I think). 1) When View-PDF is called, ps2pdf -dCompatibilityLevel=1.3 newfile1.ps is called in turn. This call fails with the following error message: Unrecoverable error: typecheck in .putdeviceprops I have not investigated too much, but the problem is with the -dCompatibilityLevel=1.3 swithc. If ps2pdf is called without options it works fine. I guess ps2pdf13 could be called instead? Angus Jean-Marc? Yes, it seems that calling ps2pdf13 is a good idea. I'll do that. JMarc
[LyXWin1.3.6CVS] installer issue
Hello Angus, I encountered an installer unpleasantness: When I set the path to e.g. the sh.exe, go to the next step, python, and then backwards to the MSYS step, the installer looses the path information for the sh.exe and jumps to the install option. I expect that the setted path is still the default and that the installer don't jump to the inststll option. Because if the path is correct, I want to continue without setting the path again. Btw. What do I need to fix such bugs by myself? I installed NSIS and need your source (and possibly a hint from you to sail around NSIS cliffs). Where is it stored in the CVS? regards Uwe
Re: More Bugs in Lyx 1.3.6 (Windows)
Juergen Spitzmueller wrote: Angus Leeming wrote: A similar error happens if we call View/Update-PDF(pdflatex) while the pdf file is already loaded in Acrobat I don't think that there's anythng we can do about this. You could try submitting a bug report to Adobe asking them not to be so rude as to keep the HANDLE on the file open... Fabrice Popineau's fpTeX distribution for windows (http://www.fptex.org/) contains the pdfopen and pdfclose commands which are working around this. A UNIX port (xpdfopen) has been released recently (I didn't test either one). Interesting. I read this as saying that: $ pdfclose my_file.pdf; pdfopen my_file.pdf will reopen my_file.pdf in acroread. Correct? Is it possible to grab the windows sources/executable separately? I'd rather not download the whole of this beast... Angus
Re: More about LyX meeting
On Friday 10 June 2005 11:20, Jean-Marc Lasgouttes wrote: Jose' == Jose' Matos [EMAIL PROTECTED] writes: Jose' I will carry my laptop. :-) Noted. JMarc PS: what is so funny about it? Especially on a friday. Here it is holiday, so I am not working. Also it is cooler than it was on previous days with temperatures around 37 C. :-) So today I dare to exempt me from the no smile rule and I act accordingly. ;-) -- José Abílio
Re: [LyXWin1.3.6CVS] installer issue
Uwe Sthr wrote:
Hello Angus,
I encountered an installer unpleasantness:
When I set the path to e.g. the sh.exe, go to the next step, python, and
then backwards to the MSYS step, the installer looses the path
information for the sh.exe and jumps to the install option.
I expect that the setted path is still the default and that the
installer don't jump to the inststll option. Because if the path is
correct, I want to continue without setting the path again.
Btw. What do I need to fix such bugs by myself?
Woo!
See below for where to find lyx_installer.nsi et al. You'll probably need
to edit download.nsh so that it checks the registry setting only if
${ExePath} is empty:
!macro DownloadEnter_Private ExePath RegistryKey RegistrySubKey
RemoveFromPath AddtoPath Required DownloadLabel HomeLabel PageHeader
PageDescription
!define skipBackupLbl skipBackup_${__LINE__}
- StrCpy ${ExePath}
- ReadRegStr ${ExePath} HKLM ${RegistryKey} ${RegistrySubKey}
+ ${if} ${ExePath} ==
+ReadRegStr ${ExePath} HKLM ${RegistryKey} ${RegistrySubKey}
+ ${endif}
I installed NSIS and
need your source (and possibly a hint from you to sail around NSIS
cliffs). Where is it stored in the CVS?
development\Win32\packaging
See the README for a complete list of everything I do after I have run
make install to create a tree ready for packaging. I suspect that it's
sufficient for you to simply copy your installed LyX tree to the equivalent
of J:\Programs\LyX, ready to be packaged again. Ie, you can skip everything
that the README suggests you do exceptfor the final step, building the
installer.
The installer code lives in
development\Win32\packaging\installer\lyx_installer.nsi
You'll need to also rebuild lyx_path_prefix.dll. See the description at the
top of lyx_path_prefix.C. It's possible that compilation will fail. If so,
you'll have to edit NSIS/Contrib/ExDLL/exdll.h, so:
-typedef {
+typedef struct exec_flags_ {
int autoclose;
int all_user_var;
int exec_error;
int abort;
int exec_reboot;
int reboot_called;
int XXX_cur_insttype; // deprecated
int XXX_insttype_changed; // deprecated
int silent;
int instdir_error;
int rtl;
int errlvl;
} exec_flags;
typedef struct {
- exec_flags *exec_flags;
+ struct exec_flags_ *exec_flags;
int (__stdcall *ExecuteCodeSegment)(int, HWND);
} extra_parameters;
(This bug has been fixed in NSIS 2.07b)
Angus
Re: [LyXWin 1.3.6pre9] Spell-checking works, but...
Paul A. Rubin wrote:
... except for the bug, reported long ago for other versions, that
opening multiple documents and then spell-checking more than one of
them causes LyX to crash. Still.
Cool! Detailed HOWTO please.
Seems to be somewhat document-dependent, and may vary by astrological or
meteorological conditions. I'm attaching two files from one of my
classes. I can crash LyX using the following algorithm:
1. Open both docs (order seems immaterial).
2. Spell check one of them (again, does not seem to matter which) and
click Ignore All every time a word is flagged. (My spelling is
impeccable, so this is the appropriate response each time.)
3. Switch to the other document, position the cursor at the beginning,
and commence checking. The first time I click Ignore All, LyX
disappears into bit oblivion.
Ok, the attached patch fixes the crash and allows you to spell check
multiple docs.
Jean-Marc, I have no idea why this bit of code exists but it is just plain
bad! The rest of the code assumes the existence of a valid speller_, so
resetting the pointer to 0 is just evil. Noetheless, I think that we should
recreate it in case the user has changed his lyxrc preferences.
Note that no such patch is needed for 1.4.x.
Ok to commit?
Angus
Index: src/frontends/controllers/ControlSpellchecker.C
===
RCS file:
/usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ControlSpellchecker.C,v
retrieving revision 1.36.2.4
diff -u -a -u -r1.36.2.4 ControlSpellchecker.C
--- src/frontends/controllers/ControlSpellchecker.C 10 May 2005 15:00:13
- 1.36.2.4
+++ src/frontends/controllers/ControlSpellchecker.C 10 Jun 2005 09:01:14
-
@@ -63,11 +63,11 @@
{
lyxerr[Debug::GUI] spell startSession endl;
- if (speller_.get()) {
- lyxerr[Debug::GUI] startSession: speller exists endl;
- speller_.reset(0);
- return;
- }
+// if (speller_.get()) {
+// lyxerr[Debug::GUI] startSession: speller exists endl;
+// speller_.reset(0);
+// return;
+// }
// create spell object
string tmp;
Re: [LyXWin 1.3.6pre9] Crash on Save As
Paul A. Rubin wrote: I must be slipping -- took me the better part of 10 minutes to crash it! :-) I created a trivial document and clicked File | Save As ... I then clicked the up arrow button to move up one directory level, and then double clicked on another directory. Note that when the dialog first opens, the file name field has the focus, but after navigating around that's no longer true (although the cursor is still in it). I then hit a key and LyX crashed. This one looks and feels like a Qt/WinFree bug. (The dialog is a Qt built in.) I can't get the crash on linux. I can get it on Windows. What happens on linux is that, when you type a key, the directory starting with that letter is highlighted in the file browser. If there's no directory starting with this letter, then nothing is highlighted. -- Angus
Re: More Bugs in Lyx 1.3.6 (Windows)
Thanks! Peter Kümmel wrote: Nicolás wrote: 2) When a pdf already exists in the temp directory, which is already loaded in Acrobat, and View-PDF(dvipdfm) is called, the user gets this error: Cannot convert file. Error while executing dvipdfm The debugging message is: Unable to open newfile1.pdf The problem is that dvipdfm cannot overwrite the file (if I am not wrong). Is there no way to give the end-user a clearer hint about what is happening, that is, that a pdf already exists and it is loaded in acrobat? Then the user can choose to close acrobat and call View-PDF again. With the cannot convert file error message the user thinks something is wrong with LyX and does not realise the file is already loaded in Acrobat. A similar error happens if we call View/Update-PDF(pdflatex) while the pdf file is already loaded in Acrobat Nicolás A other workaround is to use the explorer to view generated pdfs. The explorer loads the pdf-plugin which allows overwriting its viewed files. So you has to reload the page after a update. Maybe there are also some short cuts to reload the pdf without changing the viewed page. Peter
Re: patch for scrclass.inc
On 10.06.05, Juergen Spitzmueller wrote: Juergen I do not agree to change the name from Labeling to List Juergen in the GUI. I really do not like that we are beginning to replace the termini technici of LaTeX classes and environments with arbitrary names (or translations, for that matter) if there is no special need to do so. I totally agree with you. However, there is a need here, which is the harmonisation of the names. List is not arbitrary but chosen after the name of the same style in non-koma layouts. There are not only LaTeX agnostics using LyX. For people who are familiar with the KOMA script documentation, the term Labeling is well defined, while List is just irritating. So we have to weight the arguments for 3 possible options: 1. Call the lyx-list/labeling style List in all layouts. + Nice for people learning koma after LyX or documentation agnostics. - Bad for people that know koma or read its superb documentation 2. Call the style Labeling in koma and List elsewhere. + No big changes involved. - Missing harmony: Two names for one style See the attached patches for this solution 3. Call the style Labeling in all layouts. + Replace the arbitrary, too generic, and LyX specific name by the standard name established in the Tex community. - The average LyX user has to re-adjust. Documentation update needed. Personally, I'd favour variant 3 (without insisting on it, as I cannot provide a complete set of patches). The attached patch provides solution 2 The following patch provides a backwards compatibility (conversion of a koma document to a non-koma alternative), as stdclass.inc is not included by the koma layouts but (almost) all other classes. --- /usr/src/lyx-cvs/devel/lib/layouts/stdclass.inc~2005-05-23 11:04:10.0 +0200 +++ /usr/src/lyx-cvs/devel/lib/layouts/stdclass.inc 2005-06-10 14:24:41.0 +0200 @@ -45,3 +45,8 @@ Input stdlayouts.inc Input stdfloats.inc Input stdcounters.inc + +# convert Labeling (from koma-script documents) to List +Style Labeling +ObsoletedBy List +End - To put it different: I think people who are using KOMA-classes in LyX should be encouraged to read the excellent KOMA-script documentation (the LyX documentation can never replace that). But if the KOMA-script documentation recommends to use the environments which can not be found in LyX, because LyX has its own terminology, it gets useless. As this problem is not restricted to Labeling, I have a Feature suggestion -- LyX could tell the latex name of the layout styles * as supplement or tooltips in the drop-layouts list. * in the status line after change of layout Layout changed to %s (%s) % (Style, latex-name) Günter -- G.Milde web.de --- /usr/src/lyx-cvs/devel/lib/layouts/scrclass.inc 2005-05-23 11:04:10.0 +0200 +++ /home/milde/.lyx/layouts/scrclass.inc 2005-06-10 14:13:37.0 +0200 @@ -3,6 +3,8 @@ # Bernd Rellermeyer [EMAIL PROTECTED], 1998/7/23. # Update for Koma Script Release =2.8q # Juergen Spitzmueller [EMAIL PROTECTED], 2003/2/08. +# Mapped List to Labeling +# Guenter Milde g.milde web.de SecNumDepth 2 @@ -20,8 +22,6 @@ Input stdcounters.inc Input stdfloats.inc -NoStyle List - Style Description LabelFont Family Sans @@ -29,21 +29,15 @@ End Style Labeling - MarginManual - LatexType List_Environment - LatexName labeling - NextNoindent 1 - LabelSep xxx - ParSkip 0.4 - TopSep0.7 - BottomSep 0.7 - ParSep0.5 - Align Block - AlignPossible Block, Left - LabelType Manual - LabelString 00.00. +CopyStyle List +LatexName labeling +Preamble # overwrite the preamble code definition +EndPreamble End +Style List +Obsoletedby Labeling +End Input stdsections.inc @@ -260,5 +254,4 @@ End Input lyxmacros.inc -Input scrmacros.inc
Re: More Bugs in Lyx 1.3.6 (Windows)
Angus Leeming wrote: Interesting. I read this as saying that: $ pdfclose my_file.pdf; pdfopen my_file.pdf will reopen my_file.pdf in acroread. Correct? I think so, yes. Here's the documentation: http://www.ctan.org/tex-archive/support/xpdfopen/xpdfopen.pdf Is it possible to grab the windows sources/executable separately? I'd rather not download the whole of this beast... AFAIK it's included in bin-pdftools, to be found here (don't know which one of the two versions is the right one): ftp://ftp.ctan.org/tex-archive/systems/win32/fptex/current/binary HTH, Jürgen
obsolete Comments layout style?
Browsing the layouts directory for my scrclass pathch, I found a problem in obsolete.inc. Style Comment ObsoletedBy Standard End But: Comment vs. Standard is not just a naming convention. Silently replacing comments by standard output can result in ugly surprises. Example: Someone asks me for a copy of an old publication. I do not find the pdf but have the lyx file lying around. So I open it in LyX and print. (Without an extra check, as I know that this was the final version.) Unfortunately, there was a section I took out by uncommenting. :-( My suggestion: Do not obsolete Comment style, so the user gets a warning. --- /usr/src/lyx-cvs/devel/lib/layouts/obsolete.inc 2003-10-13 11:50:10.0 +0200 +++ /usr/src/lyx-cvs/devel/lib/layouts/obsolete.inc.gm 2005-06-10 14:32:43.0 +0200 @@ -14,7 +14,3 @@ Style LaTeX ObsoletedBy Standard End - -Style Comment - ObsoletedBy Standard -End Alternative suggestion: Remover obsolete.inc altogether, as it is no longer included by any of the standard layouts. Günter -- G.Milde web.de
Re: patch for scrclass.inc
G. Milde wrote: So we have to weight the arguments for 3 possible options: 1. Call the lyx-list/labeling style List in all layouts. [...] 2. Call the style Labeling in koma and List elsewhere. [...] 3. Call the style Labeling in all layouts. [...] Personally, I'd favour variant 3 (without insisting on it, as I cannot provide a complete set of patches). I'd favour variant 2, but I'm also fine with variant 3, as long as the docs are updated. As this problem is not restricted to Labeling, I have a Feature suggestion -- LyX could tell the latex name of the layout styles * as supplement or tooltips in the drop-layouts list. * in the status line after change of layout Layout changed to %s (%s) % (Style, latex-name) I also think that we should do something about it. I think the LaTeX terms should be visible _before_ the change. Personally, I'd prefer a lyxrc which lets me switch off all translations for the layouts completely, or shows the latex name instead. Jürgen Günter
Re: obsolete Comments layout style?
G. Milde wrote: Style Comment ObsoletedBy Standard End This is just because we now have comment inset. lyx2lyx will do the right thing. Jürgen
Re: obsolete Comments layout style?
G == G Milde [EMAIL PROTECTED] writes: G But: Comment vs. Standard is not just a naming convention. Silently G replacing comments by standard output can result in ugly surprises. Comment environments are replaced by note insets in lyx2lyx. G Example: Someone asks me for a copy of an old publication. I do not G find the pdf but have the lyx file lying around. So I open it in G LyX and print. (Without an extra check, as I know that this was the G final version.) Did you try it? G Alternative suggestion: G Remover obsolete.inc altogether, as it is no longer included by any G of the standard layouts. This is a very good suggestion actually. I think lyx2lyx does the job for us right now (although it does not seem to handle LaTeX_Title). JMarc
Re: obsolete Comments layout style?
On Friday 10 June 2005 13:45, Jean-Marc Lasgouttes wrote: This is a very good suggestion actually. I think lyx2lyx does the job for us right now (although it does not seem to handle LaTeX_Title). You never asked for it. ;-) We can add it for the first translation after 221. Doing it simultaneously with removing the obsolete.inc it should be enough. Do you want me to do it? JMarc -- José Abílio
LyXWinUtils
Seems that this file misses some msys stuff. I could only install lyx if I use the original msys files. I also get the error message that it can't fine textclass.lst. If I use the sh.exe of LyXWinUtils.rar then lyx won't run, its allways exits. With the original msys files the installation proceeds and don't cares about the error. Peter
Re: More Bugs in Lyx 1.3.6 (Windows)
Nicolás wrote: 2) When a pdf already exists in the temp directory, which is already loaded in Acrobat, and View-PDF(dvipdfm) is called, the user gets this error: Cannot convert file. Error while executing dvipdfm The debugging message is: Unable to open newfile1.pdf The problem is that dvipdfm cannot overwrite the file (if I am not wrong). Is there no way to give the end-user a clearer hint about what is happening, that is, that a pdf already exists and it is loaded in acrobat? Then the user can choose to close acrobat and call View-PDF again. With the cannot convert file error message the user thinks something is wrong with LyX and does not realise the file is already loaded in Acrobat. A similar error happens if we call View/Update-PDF(pdflatex) while the pdf file is already loaded in Acrobat Nicolás A other workaround is to use the explorer to view generated pdfs. The explorer loads the pdf-plugin which allows overwriting its viewed files. So you has to reload the page after a update. Maybe there are also some short cuts to reload the pdf without changing the viewed page. Peter
Re: [LyXWin1.3.6CVS] installer issue
Angus Leeming wrote: See below for where to find lyx_installer.nsi et al. Thanks. But I need some time to get it work. So could you fix the problem I found in the meantime? thanks and regards Uwe
Re: LyXWinUtils
Peter Kümmel schrieb: Seems that this file misses some msys stuff. I could only install lyx if I use the original msys files. I'm the author of this package and tested it on two Win2000 systems with success. But this package is still under development and I have to investigate further. I'll remove it from the wiki page until it is stable. I also get the error message that it can't fine textclass.lst. If I use the sh.exe of LyXWinUtils.rar then lyx won't run, its allways exits. Thanks for the report. I'll test it again. Probably I accidently missed the msysxx.dll in the package. regards Uwe
Re: obsolete Comments layout style?
Jose' == Jose' Matos [EMAIL PROTECTED] writes: Jose' On Friday 10 June 2005 13:45, Jean-Marc Lasgouttes wrote: This is a very good suggestion actually. I think lyx2lyx does the job for us right now (although it does not seem to handle LaTeX_Title). Jose' You never asked for it. ;-) We can add it for the first Jose' translation after 221. Doing it simultaneously with removing Jose' the obsolete.inc it should be enough. The change was actually done in 0.11.34, so you may want to do it for translation after 210. I let you be the judge. Jose' Do you want me to do it? Yes please. JMarc
Re: [LyXWin 1.3.6pre9] Spell-checking works, but...
Angus Leeming wrote: Ok, the attached patch fixes the crash and allows you to spell check multiple docs. Jean-Marc, I have no idea why this bit of code exists but it is just plain bad! The rest of the code assumes the existence of a valid speller_, so resetting the pointer to 0 is just evil. Noetheless, I think that we should recreate it in case the user has changed his lyxrc preferences. Note that no such patch is needed for 1.4.x. Ok to commit? I took the executive decision to do so, because hard crashes are always bad. Angus
Re: More Bugs in Lyx 1.3.6 (Windows)
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus Nicolás wrote:
Hei once more! I have found some problems regarding viewing PDFs
(with v.9) (others than previously reported, I think). 1) When
View-PDF is called, ps2pdf -dCompatibilityLevel=1.3 newfile1.ps
is called in turn. This call fails with the following error
message: Unrecoverable error: typecheck in .putdeviceprops I
have not investigated too much, but the problem is with the
-dCompatibilityLevel=1.3 swithc. If ps2pdf is called without
options it works fine. I guess ps2pdf13 could be called instead?
Angus Jean-Marc?
I propose the following pair of patches. I could not refrain from
simplifying the 1.4.0cvs version, though :)
JMarc
Index: lib/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/ChangeLog,v
retrieving revision 1.363.2.111
diff -u -p -r1.363.2.111 ChangeLog
--- lib/ChangeLog 25 May 2005 12:59:53 - 1.363.2.111
+++ lib/ChangeLog 10 Jun 2005 14:11:04 -
@@ -1,3 +1,7 @@
+2005-06-10 Jean-Marc Lasgouttes [EMAIL PROTECTED]
+
+ * configure.m4 (ps_to_pdf_command): use ps2pdf13 by default.
+
2005-05-25 Angus Leeming [EMAIL PROTECTED]
* configure.m4: strip '\r' characters from the generated
Index: lib/configure.m4
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/configure.m4,v
retrieving revision 1.60.2.22
diff -u -p -r1.60.2.22 configure.m4
--- lib/configure.m4 26 May 2005 10:14:20 - 1.60.2.22
+++ lib/configure.m4 10 Jun 2005 14:11:04 -
@@ -282,8 +282,7 @@ SEARCH_PROG([for a DVI previewer],DVI_VI
SEARCH_PROG([for a HTML previewer],HTML_VIEWER, mozilla file://\$\$p\$\$i netscape)
# Search for a program to convert ps to pdf
-SEARCH_PROG([for a PS to PDF converter],ps_to_pdf_command,ps2pdf)
-test $ps_to_pdf_command = ps2pdf ps_to_pdf_command=ps2pdf -dCompatibilityLevel=1.3 \$\$i
+SEARCH_PROG([for a PS to PDF converter],ps_to_pdf_command, ps2pdf13 \$\$i)
# Search for a program to convert dvi to ps
SEARCH_PROG([for a DVI to PS converter],dvi_to_ps_command,dvips)
Index: lib/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/ChangeLog,v
retrieving revision 1.706
diff -u -p -r1.706 ChangeLog
--- lib/ChangeLog 9 Jun 2005 09:58:02 - 1.706
+++ lib/ChangeLog 10 Jun 2005 14:19:14 -
@@ -1,3 +1,7 @@
+2005-06-10 Jean-Marc Lasgouttes [EMAIL PROTECTED]
+
+ * configure.m4: use ps2pdf13 for ps-pdf converter. Simplify code.
+
2005-06-01 Jean-Marc Lasgouttes [EMAIL PROTECTED]
* configure.m4: fix shortcut for text format.
Index: lib/configure.m4
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/configure.m4,v
retrieving revision 1.99
diff -u -p -r1.99 configure.m4
--- lib/configure.m4 9 Jun 2005 09:58:02 - 1.99
+++ lib/configure.m4 10 Jun 2005 14:19:14 -
@@ -29,7 +29,7 @@ dnl
define(SEARCH_PROG,[dnl
changequote([,])dnl
MSG_CHECKING($1)
-MSG_RESULT(($3))
+MSG_RESULT()
$2=
for ac_prog in $3
do
@@ -249,8 +249,7 @@ FIG_VIEWER=$FIG_EDITOR
SEARCH_PROG([for a GRACE viewer and editor], GRACE_EDITOR, xmgrace)
GRACE_VIEWER=$GRACE_EDITOR
-SEARCH_PROG([for a FEN viewer and editor], FEN_EDITOR, xboard)
-test $FEN = xboard FEN_EDITOR=xboard -lpf \$\$i -mode EditPosition
+SEARCH_PROG([for a FEN viewer and editor], FEN_EDITOR, xboard -lpf \$\$i -mode EditPosition)
FEN_VIEWER=$FEN_EDITOR
SEARCH_PROG([for a raster image viewer], RASTERIMAGE_VIEWER, xv kview gimp)
@@ -262,46 +261,33 @@ SEARCH_PROG([for a text editor], TEXT_ED
# Search for an installed reLyX or a ready-to-install one
save_PATH=${PATH}
PATH=${PATH}:./reLyX/
-SEARCH_PROG([for a LaTeX - LyX converter],tex_to_lyx_command,reLyX)
+SEARCH_PROG([for a LaTeX - LyX converter],tex_to_lyx_command, reLyX -f \$\$i)
PATH=${save_PATH}
-test $tex_to_lyx_command = reLyX tex_to_lyx_command=reLyX -f \$\$i
tex_to_lyx_command=`echo $tex_to_lyx_command | sed s,reLyX,reLyX$version_suffix,`
-SEARCH_PROG([for a Noweb - LyX converter],literate_to_lyx_command,noweb2lyx)
-test $literate_to_lyx_command = noweb2lyx literate_to_lyx_command=noweb2lyx \$\$i \$\$o
+SEARCH_PROG([for a Noweb - LyX converter],literate_to_lyx_command,noweb2lyx \$\$i \$\$o)
literate_to_lyx_command=`echo $literate_to_lyx_command | sed s,noweb2lyx,noweb2lyx$version_suffix,`
# Search something to process a literate document
-SEARCH_PROG([for a Noweb - LaTeX converter],literate_to_tex_command,noweave)
-test $literate_to_tex_command = noweave literate_to_tex_command=noweave -delay -index \$\$i \$\$o
+SEARCH_PROG([for a Noweb - LaTeX converter],literate_to_tex_command,noweave -delay -index \$\$i \$\$o)
-SEARCH_PROG([for a HTML - Latex converter],html_to_latex_command,html2latex)
-test $html_to_latex_command = html2latex html_to_latex_command=html2latex \$\$i
+SEARCH_PROG([for a HTML - Latex
Re: [LyXWin 1.3.6pre9] Spell-checking works, but...
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus I took the executive decision to do so, because hard crashes
Angus are always bad.
OK. I was pondering whether this is related to
http://bugzilla.lyx.org/show_bug.cgi?id=1451
but it is probably not. I guess I should apply the patch I have for
that.
JMarc
Index: src/frontends/controllers/ControlSpellchecker.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ControlSpellchecker.C,v
retrieving revision 1.36.2.5
diff -u -p -r1.36.2.5 ControlSpellchecker.C
--- src/frontends/controllers/ControlSpellchecker.C 10 Jun 2005 14:15:34 - 1.36.2.5
+++ src/frontends/controllers/ControlSpellchecker.C 10 Jun 2005 14:27:23 -
@@ -59,6 +59,13 @@ void ControlSpellchecker::clearParams()
}
+void ControlSpellchecker::updateSlot(bool switched)
+{
+ if (switched)
+ hide();
+}
+
+
void ControlSpellchecker::startSession()
{
lyxerr[Debug::GUI] spell startSession endl;
Index: src/frontends/controllers/ControlSpellchecker.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ControlSpellchecker.h,v
retrieving revision 1.14.2.3
diff -u -p -r1.14.2.3 ControlSpellchecker.h
--- src/frontends/controllers/ControlSpellchecker.h 7 Dec 2004 10:49:05 - 1.14.2.3
+++ src/frontends/controllers/ControlSpellchecker.h 10 Jun 2005 14:27:23 -
@@ -83,6 +83,10 @@ private:
/// not needed.
virtual void apply() {}
+ /** Instantiation of ControlConnectBD private virtual method.
+ Slot connected to update signal. */
+ virtual void updateSlot(bool);
+
/// current word being checked and lang code
WordLangTuple word_;
Re: More Bugs in Lyx 1.3.6 (Windows)
Jean-Marc Lasgouttes wrote: Hei once more! I have found some problems regarding viewing PDFs (with v.9) (others than previously reported, I think). 1) When View-PDF is called, ps2pdf -dCompatibilityLevel=1.3 newfile1.ps is called in turn. This call fails with the following error message: Unrecoverable error: typecheck in .putdeviceprops I have not investigated too much, but the problem is with the -dCompatibilityLevel=1.3 swithc. If ps2pdf is called without options it works fine. I guess ps2pdf13 could be called instead? Angus Jean-Marc? I propose the following pair of patches. I could not refrain from simplifying the 1.4.0cvs version, though :) JMarc The 1.3 patch looks good. For 1.4 shouldn't we be using tex2lyx rather than reLyX (since you've touched this part of the script...) Angus
Re: [LyX 1.3.6CVS] LaTeX-preamble problems
Georg == Georg Baum [EMAIL PROTECTED] writes: I'd prefer a solution that works always... Georg Me too, but that is unfortunately impossible :-( And what about loading wasysym package _after_ amsmath? It seems to work here. JMarc
Re: More Bugs in Lyx 1.3.6 (Windows)
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus The 1.3 patch looks good. For 1.4 shouldn't we be using tex2lyx Angus rather than reLyX (since you've touched this part of the Angus script...) Well, I did not really touch it with my brain, just my fingers. Yes, we shall eventually switch for tex2lyx. I believe Lars sent a patch for that earlier. JMarc
Re: [LyXWin 1.3.6pre9] Spell-checking works, but...
Jean-Marc Lasgouttes wrote: Angus I took the executive decision to do so, because hard crashes Angus are always bad. OK. I was pondering whether this is related to http://bugzilla.lyx.org/show_bug.cgi?id=1451 but it is probably not. I don't think that it is related intimately. It does highlight the fact that the spell checking code in 1.3.x is more fragile than it should be (because no one really understands the logic of what is going on). Fortunately, the code in 1.4.x should be much more robust and much more transparent. I guess I should apply the patch I have for that. That would be good. JMarc Angus
Re: More Bugs in Lyx 1.3.6 (Windows)
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Angus == Angus Leeming [EMAIL PROTECTED] writes: | Angus The 1.3 patch looks good. For 1.4 shouldn't we be using tex2lyx | Angus rather than reLyX (since you've touched this part of the | Angus script...) | Well, I did not really touch it with my brain, just my fingers. | Yes, we shall eventually switch for tex2lyx. I believe Lars sent a | patch for that earlier. Possibly... I have no idea how to to it thoug. but imho we should change the default to be tex2lyx asap. -- Lgb
Re: [PATCH] reduce drastically number of calls to LyXText::getFont
Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Jean-Marc The following patch reduces the number of calls to getFont Jean-Marc by the two following means: Jean-Marc For your enjoyment, I also attach the patch that removes Jean-Marc font metrics caching for qt, which I think is also Jean-Marc relevant. The two patches are now applied. Bennett, you said at the time that the fontcache patch make things worse. If this is still true, I can keep the fontcache for qt/mac. Testing on qt/win would be appreciated too, of course. JMarc
Re: More Bugs in Lyx 1.3.6 (Windows)
Lars Gullik Bjønnes wrote: Jean-Marc Lasgouttes writes: | Angus The 1.3 patch looks good. For 1.4 shouldn't we be using tex2lyx | Angus rather than reLyX (since you've touched this part of the | Angus script...) | Well, I did not really touch it with my brain, just my fingers. | Yes, we shall eventually switch for tex2lyx. I believe Lars sent a | patch for that earlier. Possibly... I have no idea how to to it though. but imho we should change the default to be tex2lyx asap. At the same time, why don't we retire reLyX into a CVS repository of its own? Ie, it's available but we can ignore it entirely, leaving it to die a neglected death. Angus
Re: [PATCH] reduce drastically number of calls to LyXText::getFont
Jean-Marc Lasgouttes wrote: Jean-Marc The following patch reduces the number of calls to getFont Jean-Marc by the two following means: Jean-Marc For your enjoyment, I also attach the patch that removes Jean-Marc font metrics caching for qt, which I think is also Jean-Marc relevant. The two patches are now applied. Bennett, you said at the time that the fontcache patch make things worse. If this is still true, I can keep the fontcache for qt/mac. Testing on qt/win would be appreciated too, of course. Personally, I'm not going to try compiling LyX/Win 1.4.x until 1.3.6 is released. Maybe you can lean on Rob Bearman... Angus
Re: [PATCH] reduce drastically number of calls to LyXText::getFont
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Personally, I'm not going to try compiling LyX/Win 1.4.x until Angus 1.3.6 is released. Maybe you can lean on Rob Bearman... We'll see if someone complains. Actually, what would be useful is someone running a profiler on LyX/Win. JMarc
Re: More Bugs in Lyx 1.3.6 (Windows)
Angus Leeming [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: Jean-Marc Lasgouttes writes: | Angus The 1.3 patch looks good. For 1.4 shouldn't we be using tex2lyx | Angus rather than reLyX (since you've touched this part of the | Angus script...) | Well, I did not really touch it with my brain, just my fingers. | Yes, we shall eventually switch for tex2lyx. I believe Lars sent a | patch for that earlier. Possibly... I have no idea how to to it though. but imho we should change the default to be tex2lyx asap. | At the same time, why don't we retire reLyX into a CVS repository of | its own? Ie, it's available but we can ignore it entirely, leaving it | to die a neglected death. Or just let it be available from the Attic... (and possibly a tar.gz file on the ftp server) -- Lgb
Re: [LyXWin1.3.6CVS] installer issue
Hello Angus, In Version 11 of the installer is still a bug: When I go back to the previous install step, the folder appears with an additional \bin. E.g. I set the path to sh.exe as F:\LyXTest and it appears as F:\LyXTest\bin when I go back. So I have to correct the path if I want go to the next install step. And another issue I mentioned some days ago: If I have three times the same path for a .exe file (in my case for python, perl, and sh), the installer prints them out three times for the path_prefix altough it is set only once in lyxrc.defaults. OK this is not a big problem but confuses the user. regards Uwe p.s. I just uploaded a corrected version of the LyXWinUtils to http://wiki.lyx.org/uploads/Tools/LyXWinTest/LyXWinUtils.rar Peter Kmmel helped me to find the Problem. There is only one problem left now. Using the LyXWinUtils, I get the following message in LyX's debug window when I update the view of a DVI: --- Converting from latex to dvi2 Running latex lyx::sum() using istreambuf_iterator (fast) lyx::sum() using istreambuf_iterator (fast) Converting from dvi2 to dvi Calling python F:/LyXTest/LyX/Resources/lyx/scripts/clean_dvi.py newfile1.dvi tmpfile.out 'import site' failed; use -v for traceback renaming file F:/LyXTest/LyX/Temp/lyx_tmpdir328a01220/lyx_tmpbuf0/tmpfile.out to F:/LyXTest/LyX/Temp/lyx_tmpdir328a01220/lyx_tmpbuf0/newfile1.dvi -- The update was successful but I don't like the message 'import site' failed; use -v for traceback Export or view the file as pdf, dvi, and ps works without this message. Do you have an idea?
Re: [LyXWin1.3.6CVS] installer issue
On Friday 10 June 2005 16:50, Uwe Sthr wrote: The update was successful but I don't like the message 'import site' failed; use -v for traceback Export or view the file as pdf, dvi, and ps works without this message. Do you have an idea? Usually this means that the python installation is crippled and/or incomplete. -- Jos Ablio
Re: [LyXWin1.3.6CVS] installer issue
Hi Angus,
A small problem with version 10:
If you next, back from the MSYS page you get strange results.
It keeps on appending \bin. After the second entry into the page
it can't find sh.exe any more.
Probable fix: (from version 9 nsi file)
in file lyx_installer.nsi line 336
${DownloadEnter} \
$MinSYSPath $2 Inno Setup: App Path \
\bin \
RemovefromPath is blank.
Addtopath is set to \bin.
Johann
Re: obsolete Comments layout style?
On Friday 10 June 2005 14:31, Jean-Marc Lasgouttes wrote: Jose' You never asked for it. ;-) We can add it for the first Jose' translation after 221. Doing it simultaneously with removing Jose' the obsolete.inc it should be enough. The change was actually done in 0.11.34, so you may want to do it for translation after 210. I let you be the judge. Here it comes. :-) Please let us release 1.4 so that I can use 2.2 python features... JMarc I will apply it unless I get strong objections. Shall I remove obsolete.inc as well? -- José Abílio
Checking for additional software on windows
Hi all, I thought about including checking for acrobat, aspell and more. As Angus suggested having all these options before even installing lyx could be too much for most users. What about creating a secondary installer to check for required software? The functionality would be a smaller subset of the current installer (first couple of pages) plus pages for the additional software. If a user needs to add more functionality to lyx he can just run the config or features program from the start menu. Maybe later on it can be moved into Edit-Reconfigure for windows platforms?? The operation would be similar to the installer, the only difference is it can be run at any time and would include all support software. It will allow a windows user to easily extend the functionality of lyx (by installing additional supporting applications). So if a user installs a new version of acrobat or decides he needs to be able to convert tex files to lyx he can just run the config/features option from the start menu and be guided through a couple of questions. Any further ideas/comments would be appreciated. Regards, Johann
Re: obsolete Comments layout style?
On Friday 10 June 2005 17:06, Jose' Matos wrote: Here it comes. :-) -- José Abílio Index: lyx_0_12.py === RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/lyx2lyx/lyx_0_12.py,v retrieving revision 1.6 diff -u -p -r1.6 lyx_0_12.py --- lyx_0_12.py 5 Jan 2005 18:52:59 - 1.6 +++ lyx_0_12.py 10 Jun 2005 16:01:52 - @@ -273,12 +273,26 @@ def update_latexaccents(file): i = i + 1 +def obsolete_latex_title(file): +body = file.body +i = 0 +while 1: +i = find_token(body, '\\layout', i) +if i == -1: +return + +if string.find(string.lower(body[i]),'latex_title') != -1: +body[i] = '\\layout Title' + +i = i + 1 + + convert = [[215, [header_update, add_end_document, remove_cursor, final_dot, update_inset_label, update_latexdel, update_space_units, space_before_layout, formula_inset_space_eat, update_tabular, update_vfill, remove_empty_insets, - remove_formula_latex, update_latexaccents]]] + remove_formula_latex, update_latexaccents, obsolete_latex_title]]] revert = []
Re: [PATCH] reduce drastically number of calls to LyXText::getFont
On Jun 10, 2005, at 10:56 AM, Jean-Marc Lasgouttes wrote: Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Jean-Marc The following patch reduces the number of calls to getFont Jean-Marc by the two following means: Jean-Marc For your enjoyment, I also attach the patch that removes Jean-Marc font metrics caching for qt, which I think is also Jean-Marc relevant. The two patches are now applied. Bennett, you said at the time that the fontcache patch make things worse. If this is still true, I can keep the fontcache for qt/mac. It does feel slower. These are the results I'm now getting with Shark's time profile (granularity set at source line), starting at the point when times as a percentage of the total really start dropping. ... | + 99.1% main.C:49 (LyX) | | + 98.8% lyxfont.C:973 (LyX) | | | + 98.7% lyxfont.C:973 (LyX) | | | | + 86.8% counters.C:343 (LyX) | | | | | + 86.8% qtTimeout.C:59 (LyX) | | | | | | + 86.8% math_atom.C:49 (LyX) | | | | | | | + 86.8% texrow.C:85 (LyX) | | | | | | | | + 86.3% main.C:49 (LyX) | | | | | | | | | + 86.3% main.C:49 (LyX) | | | | | | | | | | + 74.2% Timeout.C:71 (LyX) | | | | | | | | | | | + 74.2% SpellBase.C:49 (LyX) | | | | | | | | | | | | + 62.4% SpellBase.C:49 (LyX) | | | | | | | | | | | | | + 62.3% SpellBase.C:49 (LyX) | | | | | | | | | | | | | | + 60.1% SpellBase.C:49 (LyX) | | | | | | | | | | | | | | | + 55.5% SpellBase.C:49 (LyX) | | | | | | | | | | | | | | | | + 37.7% QtView_moc.C:102 (LyX) | | | | | | | | | | | | | | | | | + 37.7% QtView_moc.C:102 (LyX) | | | | | | | | | | | | | | | | | | + 35.1% lengthcombo.C:62 (LyX) | | | | | | | | | | | | | | | | | | | + 33.7% lengthcombo.C:62 (LyX) | | | | | | | | | | | | | | | | | | | | + 33.1% lengthcombo.C:62 (LyX) | | | | | | | | | | | | | | | | | | | | | + 0.4% lengthcombo.C:62 (LyX) | | | | | | | | | | | | | | | | | | | | | | 0.0% lengthcombo.C:62 (LyX) | | | | | | | | | | | | | | | | | | | | | | 0.0% qt_helpers.C:205 (LyX) | | | | | | | | | | | | | | | | | | | | | 0.1% shared_count.hpp:269 (LyX) | | | | | | | | | | | | | | | | | | | | | + 0.1% qt_helpers.C:205 (LyX) | | | | | | | | | | | | | | | | | | | | | | 0.0% stl_alloc.h:677 (LyX) | | | | | | | | | | | | | | | | | | | | 0.1% lengthcombo_moc.C:131 (LyX) | | | | | | | | | | | | | | | | | | | | 0.0% qt_helpers.C:205 (LyX) ... But, frankly, the difference in speed introduced with the fontcache patch is trivial compared to the slowness of lyx-140 overall: it really is unusable on the Mac, and something else must account for the slowness. I'd love to help fix this, but I need guidance. Apparently Shark's profiling -- as I'm doing it, at least -- isn't providing the needed data. If there is another tool I should use that others are more familiar with, let me know, and I'll do what I can. (gprof, e.g., is already on my machine.) Bennett
Re: [PATCH] reduce drastically number of calls to LyXText::getFont
Bennett Helm wrote: But, frankly, the difference in speed introduced with the fontcache patch is trivial compared to the slowness of lyx-140 overall: it really is unusable on the Mac, and something else must account for the slowness. I'm not sure if this is related, but valgrind also reports some leaks which look like they are related to font handling (I do not really understand its output, so I might be wrong). Attached is the report of: (a.) starting LyX, (b.) new doc, (c) type Hello, (d) quit. HTH, Jürgen ==15243== ==15243== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 128 from 5) ==15243== malloc/free: in use at exit: 1263323 bytes in 14431 blocks. ==15243== malloc/free: 375 allocs, 4429944 frees, 894213754 bytes allocated. ==15243== For counts of detected errors, rerun with: -v ==15243== searching for pointers to 14431 not-freed blocks. ==15243== checked 1970504 bytes. ==15243== ==15243== 44 (32 direct, 12 indirect) bytes in 1 blocks are definitely lost in loss record 103 of 376 ==15243==at 0x1B904718: operator new(unsigned) (in /usr/lib/valgrind/vgpreload_memcheck.so) ==15243==by 0x1CDE8CB6: ??? ==15243==by 0x1BD66329: QInputContextFactory::create(QString const, QWidget*) (in /usr/lib/qt3/lib/libqt-mt.so.3.3.4) ==15243==by 0x1CDA4DBB: ??? ==15243==by 0x1CDA4FAE: ??? ==15243==by 0x1CDA521A: ??? ==15243==by 0x1BD66329: QInputContextFactory::create(QString const, QWidget*) (in /usr/lib/qt3/lib/libqt-mt.so.3.3.4) ==15243==by 0x1BAE9FE8: QWidget::createInputContext() (in /usr/lib/qt3/lib/libqt-mt.so.3.3.4) ==15243==by 0x1BAEA244: QWidget::focusInputContext() (in /usr/lib/qt3/lib/libqt-mt.so.3.3.4) ==15243==by 0x1BBBA639: QWidget::setFocus() (in /usr/lib/qt3/lib/libqt-mt.so.3.3.4) ==15243==by 0x1BB24619: QApplication::setActiveWindow(QWidget*) (in /usr/lib/qt3/lib/libqt-mt.so.3.3.4) ==15243==by 0x1BABCCF6: QApplication::x11ProcessEvent(_XEvent*) (in /usr/lib/qt3/lib/libqt-mt.so.3.3.4) ==15243== ==15243== ==15243== 6797 (112 direct, 6685 indirect) bytes in 7 blocks are definitely lost in loss record 142 of 376 ==15243==at 0x1B9045A4: malloc (in /usr/lib/valgrind/vgpreload_memcheck.so) ==15243==by 0x1C093FD2: FcPatternCreate (in /usr/lib/libfontconfig.so.1.0.4) ==15243==by 0x1C092A38: FcFontRenderPrepare (in /usr/lib/libfontconfig.so.1.0.4) ==15243==by 0x1C092D91: FcFontSetMatch (in /usr/lib/libfontconfig.so.1.0.4) ==15243==by 0x1C092F26: FcFontMatch (in /usr/lib/libfontconfig.so.1.0.4) ==15243==by 0x1C06F97A: XftFontMatch (in /usr/X11R6/lib/libXft.so.2.1.1) ==15243==by 0x1BB45639: loadEngine(QFont::Script, QFontPrivate const*, QFontDef const, QtFontFamily*, QtFontFoundry*, QtFontStyle*, QtFontSize*, QtFontEncoding*, bool) (in /usr/lib/qt3/lib/libqt-mt.so.3.3.4) ==15243==by 0x1BB4BD06: QFontDatabase::findFont(QFont::Script, QFontPrivate const*, QFontDef const, int) (in /usr/lib/qt3/lib/libqt-mt.so.3.3.4) ==15243==by 0x1BACFA29: QFontPrivate::load(QFont::Script) (in /usr/lib/qt3/lib/libqt-mt.so.3.3.4) ==15243==by 0x1BAD0331: QFont::rawName() const (in /usr/lib/qt3/lib/libqt-mt.so.3.3.4) ==15243==by 0x824F1C5: (anonymous namespace)::isChosenFont(QFont, std::string const) (qfont_loader.C:188) ==15243==by 0x824F52C: (anonymous namespace)::getSymbolFont(std::string const) (qfont_loader.C:224) ==15243== ==15243== ==15243== 465 (52 direct, 413 indirect) bytes in 1 blocks are definitely lost in loss record 145 of 376 ==15243==at 0x1B9045A4: malloc (in /usr/lib/valgrind/vgpreload_memcheck.so) ==15243==by 0x1C31FAFF: XGetFontPath (in /usr/X11R6/lib/libX11.so.6.2) ==15243==by 0x824EF3E: qfont_loader::addToFontPath() (qpaintdevice.h:332) ==15243==by 0x82503E0: qfont_loader::available(LyXFont const) (qfont_loader.C:419) ==15243==by 0x824BCF8: lyx_gui::font_available(LyXFont const) (lyx_gui.C:323) ==15243==by 0x81AA4B1: augmentFont(LyXFont, std::string const) (math_support.C:681) ==15243==by 0x8189589: (anonymous namespace)::math_font_available(std::string) (math_factory.C:88) ==15243==by 0x8189C70: (anonymous namespace)::initSymbols() (math_factory.C:178) ==15243==by 0x818A16E: initMath() (math_factory.C:228) ==15243==by 0x810557F: LyX::priv_exec(int, char**) (lyx_main.C:233) ==15243==by 0x8105150: LyX::exec(int, char**) (lyx_main.C:143) ==15243==by 0x8064CC6: main (main.C:47) ==15243== ==15243== ==15243== 12544 bytes in 4 blocks are possibly lost in loss record 260 of 376 ==15243==at 0x1B904718: operator new(unsigned) (in /usr/lib/valgrind/vgpreload_memcheck.so) ==15243==by 0x1C1DA348: std::__default_alloc_templatetrue, 0::_S_chunk_alloc(unsigned, int) (in /usr/lib/libstdc++.so.5.0.5) ==15243==by 0x1C1DA43C: std::__default_alloc_templatetrue, 0::_S_refill(unsigned) (in /usr/lib/libstdc++.so.5.0.5) ==15243==by 0x1C1DA756: std::__default_alloc_templatetrue, 0::allocate(unsigned) (in /usr/lib/libstdc++.so.5.0.5) ==15243==by 0x1C1DCF69:
Re: [LyXWin1.3.6CVS] installer issue
Johann Kellerman wrote:
Hi Angus,
A small problem with version 10:
If you next, back from the MSYS page you get strange results.
It keeps on appending \bin. After the second entry into the page
it can't find sh.exe any more.
Probable fix: (from version 9 nsi file)
in file lyx_installer.nsi line 336
${DownloadEnter} \
$MinSYSPath $2 Inno Setup: App Path \
\bin \
RemovefromPath is blank.
Addtopath is set to \bin.
Johann
Ach, Du Lieber Gott!
Actually, I think that the trick is to separate out this searching of the
registry/manipulation of the returned string into the onInit function so
that it really is done only once.
See the just committed (1.3.x branch) lyx_installer.nsi and download.nsh.
Now uploaded as Version 12.
Angus
Re: More Bugs in Lyx 1.3.6 (Windows)
Juergen Spitzmueller wrote: Angus Leeming wrote: Interesting. I read this as saying that: $ pdfclose my_file.pdf; pdfopen my_file.pdf will reopen my_file.pdf in acroread. Correct? I think so, yes. Here's the documentation: http://www.ctan.org/tex-archive/support/xpdfopen/xpdfopen.pdf Is it possible to grab the windows sources/executable separately? I'd rather not download the whole of this beast... AFAIK it's included in bin-pdftools, to be found here (don't know which one of the two versions is the right one): ftp://ftp.ctan.org/tex-archive/systems/win32/fptex/current/binary For info, ftp://ftp.ctan.org/tex-archive/systems/win32/fptex/current/binary/bin-pdftools-win32.zip is the one we want. It contains e2pall epstopdf pdfclose pdfdde pdfopen pdftosrc vpe ftp://ftp.ctan.org/tex-archive/systems/win32/fptex/current/binary/bin-pdftools.zip contains e2pall and epstopdf only. Angus
Re: The LyX licence
From: Angus Leeming [EMAIL PROTECTED] I forgot to ask you to drop an email to the lyx-devel list stating explicitly that you agree to licence you contribution under the terms of the Gnu General Public Licence version 2 or later. Here you are: I hereby license my contribution to LyX under the Gnu General Public Licence version 2 or later. I checked about the status of the French translation of the GPL: currently under progress, so the text should be in english for French users. -- Jean-Pierre
Re: [PATCH] reduce drastically number of calls to LyXText::getFont
On 6/10/05 9:36 AM, Bennett Helm [EMAIL PROTECTED] wrote: But, frankly, the difference in speed introduced with the fontcache patch is trivial compared to the slowness of lyx-140 overall: it really is unusable on the Mac, and something else must account for the slowness. I'd love to help fix this, but I need guidance. Apparently Shark's profiling -- as I'm doing it, at least -- isn't providing the needed data. If there is another tool I should use that others are more familiar with, let me know, and I'll do what I can. (gprof, e.g., is already on my machine.) Bennett I've been building 1.4 on the Mac (against qt-mac-free-3.3.4) for comparison purposes but I haven't seen any glaring perf problems. Forgive me if I'm confusing the issue by not having followed this thread carefully, but I've run the latest build on a 512MB Mac Mini and a 768MB G4 Powerbook, loaded up the User's Guide, copied and pasted it a couple of times to make a bigger file, and find no discernable degradation in responsiveness when I type in random places. I was curious after having read that 1.4 Mac is unusable. Am I missing something? Assuming not, I'd be curious to know what the memory configuration of Bennett's machine is. Is it possible that the issue isn't one of code perf but of swapping? Thanks Rob
problems compiling on mac os
Hi everyone, I am trying to compile lyx on mac os (native), following the instructions in the Wiki. However, compilation always stops at what I assume to be the last linking step with the message: libtool: cannot find the library `' I assume this is a problem with libtool, however I have no experience with this program. Can anyone help? Regards -Carlos
Re: [PATCH] reduce drastically number of calls to LyXText::getFont
On Jun 10, 2005, at 1:55 PM, Rob Bearman wrote: I've been building 1.4 on the Mac (against qt-mac-free-3.3.4) for comparison purposes but I haven't seen any glaring perf problems. Forgive me if I'm confusing the issue by not having followed this thread carefully, but I've run the latest build on a 512MB Mac Mini and a 768MB G4 Powerbook, loaded up the User's Guide, copied and pasted it a couple of times to make a bigger file, and find no discernable degradation in responsiveness when I type in random places. I was curious after having read that 1.4 Mac is unusable. Am I missing something? Assuming not, I'd be curious to know what the memory configuration of Bennett's machine is. Is it possible that the issue isn't one of code perf but of swapping? Rob - I have a 512MB iMac G4 (1.25GHz); it's surely not my hardware that's the issue. Perhaps it's the configuration. Here's what I've got (compiled with gcc-3.3): ./configure --with-frontend=qt --without-x --prefix=/Applications/LyX-140.app --enable-maintainer-mode --with-included-gettext --enable-optimization=-Os --disable-concept-checks --with-version-suffix --with-qt-dir=/Users/bennett/lyx/qt-mac-free-3.3.4 --without-aiksaurus (which means I'm also using qt-mac-free-3.3.4). Furthermore, I've got: LDFLAGS=-framework Carbon -framework OpenGL -framework AGL -framework QuickTime -lz Anything out of line here? Do you have something different? Why do I say things are so slow as to be unusable? When I type into an empty document, lyx starts off (according to top) using about 20% of CPU. After I've finished typing 4 lines of text, CPU usage for lyx is up to about 45%. After 10 lines of text, it's up to 75%. By 15 lines of text, CPU usage is pegged at 100% overall, and text appears on screen only after a delay -- a delay which increases the longer the document is, at least up to a point. With a long document, when I type The quick brown fox jumps over the lazy dogs. (which takes me about 7 or 8 seconds), the delay goes up to 9 seconds *after* I finish typing before all the text appears. The complexity of the document -- whether with or without math, footnotes, bibliographical entries, cross-references, etc. -- seems not to be a factor. Bennett
Re: The LyX licence
Jean-Pierre Chrétien wrote: I forgot to ask you to drop an email to the lyx-devel list stating explicitly that you agree to licence you contribution under the terms of the Gnu General Public Licence version 2 or later. Here you are: I hereby license my contribution to LyX under the Gnu General Public Licence version 2 or later. Thanks, Jean-Pierre. -- Angus
Re: [LyXWin 1.3.6pre9] Crash on Save As
Angus Leeming wrote: This one looks and feels like a Qt/WinFree bug. (The dialog is a Qt built in.) Bugger! So I have to go back and try again to find a bug that's yours? ;-) Will you notify the Qt/WinFree folks of the bug, or do I need to do that? -- Paul
Re: [PATCH] reduce drastically number of calls to LyXText::getFont
On 6/10/05 12:32 PM, Bennett Helm [EMAIL PROTECTED] wrote: I have a 512MB iMac G4 (1.25GHz); it's surely not my hardware that's the issue. Perhaps it's the configuration. Here's what I've got (compiled with gcc-3.3): ./configure --with-frontend=qt --without-x --prefix=/Applications/LyX-140.app --enable-maintainer-mode --with-included-gettext --enable-optimization=-Os --disable-concept-checks --with-version-suffix --with-qt-dir=/Users/bennett/lyx/qt-mac-free-3.3.4 --without-aiksaurus (which means I'm also using qt-mac-free-3.3.4). Furthermore, I've got: LDFLAGS=-framework Carbon -framework OpenGL -framework AGL -framework QuickTime -lz Anything out of line here? Do you have something different? Why do I say things are so slow as to be unusable? When I type into an empty document, lyx starts off (according to top) using about 20% of CPU. After I've finished typing 4 lines of text, CPU usage for lyx is up to about 45%. After 10 lines of text, it's up to 75%. By 15 lines of text, CPU usage is pegged at 100% overall, and text appears on screen only after a delay -- a delay which increases the longer the document is, at least up to a point. With a long document, when I type The quick brown fox jumps over the lazy dogs. (which takes me about 7 or 8 seconds), the delay goes up to 9 seconds *after* I finish typing before all the text appears. The complexity of the document -- whether with or without math, footnotes, bibliographical entries, cross-references, etc. -- seems not to be a factor. Bennett I've been building with exactly the configuration specified in the README.MacOSX file. I thought at one time I needed --disable-concept-checks, but it turns out I've been mistakenly leaving off the 's' at the end for some time (which I guess means the bogus flag was ignored). I just built clean without it - after rerunning ./configure - to verify. I'm building on Tiger, but before 4/29 I'd been building on 10.3 without seeing major issues. I do see the increase in processor use that you report - both on the Mac and on Windows, increasing as the document grows but only if I hammer away at the keyboard. Normal typing doesn't hit that hard on the processor and even hammering doesn't give me delays. I don't know why we're seeing a difference, but I have the same results on three machines (Powerbook, Mini, G5). I'm exposing my ignorance here, but I remember having to download a gettext library at some point, from somewhere. Can a difference like this (assuming yours is different than mine) have an effect? Thanks Rob
Re: [LyXWin 1.3.6pre9] Crash on Save As
Paul A. Rubin wrote: This one looks and feels like a Qt/WinFree bug. (The dialog is a Qt built in.) Bugger! So I have to go back and try again to find a bug that's yours? ;-) Oh, you already did that. The spellchecker bug was entirely mine because, even if I didn't write the exact piece of code, I designed the framework that nobody understood in which it sat. Which was the reason the bug existed. I wore sackcloth and ashes for 40 days as penitence and then rewrote the framework so that even I could understand it. (The bug in question doesn't exist in the 1.4.x series :-P) Will you notify the Qt/WinFree folks of the bug, or do I need to do that? I'll try and create a minimal test case that exposes the problem and then submit that. -- Paul -- Angus
Re: problems compiling on mac os
On Jun 10, 2005, at 2:19 PM, Carlos Oliveira wrote: Hi everyone, I am trying to compile lyx on mac os (native), following the instructions in the Wiki. I'm a bit confused here. By native I assume you mean LyX/Mac. But the wiki page for that (http://wiki.lyx.org/LyX/Mac) simply tells you to use the instructions found in the README.MacOSX file that comes with the source code rather than providing the instructions in the wiki. Do you instead mean LyX/X11 on Mac (http://wiki.lyx.org/LyX/Mac-X11)? I assume you mean LyX/Mac. However, compilation always stops at what I assume to be the last linking step with the message: libtool: cannot find the library `' I assume this is a problem with libtool, however I have no experience with this program. Can anyone help? Assuming everything configured properly, this sounds like you forgot to delete libqt.la from your Qt source tree: qt-mac-free-3.3.4/lib/libqt.la Try deleting that and recompiling lyx. Bennett
Re: Lyx 1.3.6pre
I'm using version 12, installed before my previous questions were sended.
With instant preview I'm referring just to the good looking math formulae
inside a document. I wasn't able to make it work (this worked well after all
the tunning, in version 1.3.5)
My imcluded pictures displays as expected for eps and png formats so I guess
the other formats will also work.
Accented characters are lost. Not possible to make á, é, í, ó, ú ü, or any
double keystroke accented letter.
Is there a way to have messages for debugging the installation?
Thanks
Eugenio
P.D. Nice implementation and after setting the LANG variable accordingly,
everything works in spanish. Changing the spellchecker by hand in the
configuration makes it possible to spellchecks the document (it is not posible
to change it from within Edit -- Preferences
Eugenio Guevara wrote:
Hi all,
Hi, Eugenio.
It's probably best if you post questions about this prerelease to the
lyx-devel@lists.lyx.org list. In fact, when you reply to this mail, please
send it to lyx-devel. We are, after all, talking about a prerelease and by
using it you're acting as one of my guinea pigs :-)
You don't need to subscribe to lyx-devel to post there and you can follow
the conversation through the gmane news interface. Alternatively, I can CC
you direct.
First, could you tell me which version of the prerelease you're using.
We're up to version 12 on the wiki now.
I just started to test this version. It looks good but I'm having
problems with Instant preview
Just to clear up any confusion, what do you mean by Instant Preview? Do
you mean the display of graphics files (\includegraphics{figure_1.eps}) on
the LyX screen or do you mean the pretty-printing of math formulae, as
described here: http://wiki.lyx.org/LyX/InstantPreview ?
Either way, could you be more precise. having problems isn't much help...
and accented letters in spanish.
Accented letters that needs the two keystrokes are not recognized
but the ñ is. Any clue?
I haven't investigated yet, but my feeling is that this is a bug in the
underlying Qt/Win Free library. See
http://wiki.lyx.org/Windows/LyX136pre#known_bugs for the complete list of
problems that we've isolated but not yet solved.
With instant preview I tried even using the scripts from version
1.3.5 with no results.
You'll have to be more precise than this I'm afraid...
Thanks
Eugenio
Angus
More Bugs in Lyx 1.3.6 (Windows)
Hei once more! I have found some problems regarding viewing PDFs (with v.9) (others than previously reported, I think). 1) When View->PDF is called, ps2pdf -dCompatibilityLevel=1.3 "newfile1.ps" is called in turn. This call fails with the following error message: <> I have not investigated too much, but the problem is with the -dCompatibilityLevel=1.3 swithc. If ps2pdf is called without options it works fine. I guess ps2pdf13 could be called instead? Be sure there is not a pdf already in the temp directory. 2) When a pdf already exists in the temp directory, which is already loaded in Acrobat, and View->PDF(dvipdfm) is called, the user gets this error: "Cannot convert file. Error while executing dvipdfm ...". The debugging message is: "Unable to open newfile1.pdf" The problem is that dvipdfm cannot overwrite the file (if I am not wrong). Is there no way to give the end-user a clearer hint about what is happening, that is, that a pdf already exists and it is loaded in acrobat? Then the user can choose to close acrobat and call View->PDF again. With the "cannot convert file" error message the user thinks something is wrong with LyX and does not realise the file is already loaded in Acrobat. A similar error happens if we call View/Update->PDF(pdflatex) while the pdf file is already loaded in Acrobat Nicolás
Re: lyx2lyx --try-hard
Jose' Matos wrote: > Are you volunteering yourself to do this work? ;-) I am a bit short on time right now, but if nobody beats me I may do so in a couple of days. Georg
Re: [PATCH] reduce drastically number of calls to LyXText::getFont
Angus Leeming <[EMAIL PROTECTED]> writes:
| Jean-Marc Lasgouttes wrote:
>> Jean-Marc> You mean that code like if (FOO_NOT_AVAILABLE) { // use
>> Jean-Marc> function bar() instead x = bar(); } else { x= foo();
>> Jean-Marc> }
>> Jean-Marc> will compile when foo() does not exist on the system? I am
>> Jean-Marc> surprised.
>> I see now that the GNU coding standard recommend this use of if(). I
>> still do not like the fact that it is not obvious from the code that
>> only one path will be followed.
>
| Please use the #if FOO_NOT_AVAILABLE version. Everything else is just
| playing silly buggers.
Not that I know what a "silly buffer" is, but I don't agree.
In this case though "#if FOO" is good.
--
Lgb
Re: [PATCH] reduce drastically number of calls to LyXText::getFont
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | To conclude, can I apply the following patches, or do you want to do | some testing first? No, go ahead. -- Lgb
Re: Bug in Lyx 1.3.6 (Windows)
Angus Leeming <[EMAIL PROTECTED]> writes: >> I've posted a message to the NSIS forum, so let's see what they do with >> it. http://forums.winamp.com/forumdisplay.php?s==65 > | I got an answer. It transpires that the fault was mine. Ahhh well. Mea | culpa. But what was the error? -- Lgb
Re: patch for scrclass.inc
G. Milde wrote: > The koma environment "labeling" is virtually equivalent to the lyxlist, so > both should mapt to the same paragraph style "List". I do not agree to change the name from "Labeling" to "List" in the GUI. Jürgen
Re: Bug in Lyx 1.3.6 (Windows)
Lars Gullik Bjønnes wrote:
I've posted a message to the NSIS forum, so let's see what they do with
it. http://forums.winamp.com/forumdisplay.php?s==65
| I got an answer. It transpires that the fault was mine. Ahhh well. Mea
| culpa.
But what was the error?
"Text" and "DirRequest" widgets expect different string formats:
Text: "foo\r\nbar C:\\tbar"
DirRequest: "C:\tbar" and while we're at it "foo$\r$\nbar"
It's inconsistent, but it is documented. See the reply I got at
http://forums.winamp.com/forumdisplay.php?s==65
We can convert from one format to the other with
${StrNSISToIO} $0 '$PathPrefix'
which fills the register "$0" with the contents of "$PathPrefix", making
the necessary transformations.
Angus
LyX/Win 1.3.6 bug report: buffer overrun, & can't find layout description
At the very last step of the LyX setup, just before the dialogue box that says "Completing the LyX Setup Wizard Congratulations! LyX has been installed successfully." I had a window appear which said the following: "Microsoft Visual C++ Runtime Library Program C:\miktex\main\miktex\bin\latex.exe A buffer overrun has been detected which has corrupted the program's internal state. The program cannot safely continue to execute and must now be terminated." This was right after it was asking me to download a package. I don't know if this has anything to do with LyX or the LyX installer, but I thought I would report it anyway. Ahh! Then at the very next step (Launch LyX) I get this: "LyX wasn't able to find any layout description! Check the contents of the file 'textclass.lst' Sorry, has to exit" I guess I'll look through the archive to see whether this has come up already. But if someone knows a fix, please let me know! All best, djb
Re: patch for scrclass.inc
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> G. Milde wrote: >> The koma environment "labeling" is virtually equivalent to the >> lyxlist, so both should mapt to the same paragraph style "List". Juergen> I do not agree to change the name from "Labeling" to "List" Juergen> in the GUI. Could you be more specific? I was about to accept the patch :) JMarc
Re: LyX meeting in Paris. What about July 14-18?
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: >> Assuming this is 'hard' now... I'll book my tickets tomorrow >> evening. Martin> This sounds so simple, doesn't it... Did you finally succeed? JMarc
Re: lyx1.4cvs bug, GUI scrolling affects the generated latex :-(
Now also registered as bug 1904. Helge Hafting
More about LyX meeting
So, I know have the following table for our next meeting: 13 14 15 16 17 18 19 Lars X X X X X X X (some extra vacation) AndréX X X X X Michael X X Juergen X X X X X José X X X X X X Won't come after all: Asger Who else has made up his mind? Also, for my own organization purposes, I'd appreciate to know who will come with a laptop. I am not sure we want to have one computer per person, but we need a large enough number. JMarc
Re: patch for scrclass.inc
Jean-Marc Lasgouttes wrote: > Juergen> I do not agree to change the name from "Labeling" to "List" > Juergen> in the GUI. > > Could you be more specific? I was about to accept the patch :) I really do not like that we are beginning to replace the termini technici of LaTeX classes and environments with arbitrary names (or translations, for that matter) if there is no special need to do so. There are not only LaTeX agnostics using LyX. For people who are familiar with the KOMA script documentation, the term "Labeling" is well defined, while "List" is just irritating. To put it different: I think people who are using KOMA-classes in LyX should be encouraged to read the excellent KOMA-script documentation (the LyX documentation can never replace that). But if the KOMA-script documentation recommends to use the environments which can not be found in LyX, because LyX has its own terminology, it gets useless. Jürgen
Re: More about LyX meeting
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | So, I know have the following table for our next meeting: > | 13 14 15 16 17 18 19 | Lars X X X X X X X (some extra vacation) | AndréX X X X X | Michael X X | Juergen X X X X X | José X X X X X X > | Won't come after all: Asger > > | Who else has made up his mind? Also, for my own organization purposes, | I'd appreciate to know who will come with a laptop. I'll bring a laptop. Please tell if you need me to bring any other networking equip. -- Lgb
Re: [PATCH] Bug 961: reintroduce LFUN_BIBDB_ADD/DEL
Jean-Marc Lasgouttes wrote:
> My point is that the behaviour of getInsetByCode is intended and
> should be left alone.
OK, then the comment to the function is at least misleading. How about the
following (I know that it is not exactly what you are looking for, but I do
not see the need in changing gotoInset now).
Jürgen
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.587
diff -u -r1.587 BufferView_pimpl.C
--- BufferView_pimpl.C 9 Jun 2005 09:58:03 - 1.587
+++ BufferView_pimpl.C 10 Jun 2005 08:36:21 -
@@ -51,6 +51,7 @@
#include "undo.h"
#include "vspace.h"
+#include "insets/insetbibtex.h"
#include "insets/insetref.h"
#include "insets/insettext.h"
@@ -122,7 +123,7 @@
boost::signals::connection lostcon;
-/// Get next inset of this class from current cursor position
+/// Return an inset of this class if it exists at the current cursor position
template
T * getInsetByCode(LCursor & cur, InsetBase::Code code)
{
@@ -135,6 +136,31 @@
return inset;
}
+
+/// Get next inset of this class from current cursor position
+template
+T * findInset(LCursor & cur, InsetBase::Code code)
+{
+ T * inset = 0;
+ DocIterator it = cur;
+ T * first_inset = static_cast(it.nextInset());
+ while (it) {
+ if (!it.nextInset()) {
+ // try from the beginning, but break after one loop
+ it.pit() = 0;
+ it.pos() = 0;
+ if (!it.nextInset() || it.nextInset() == first_inset)
+break;
+ }
+ if (it.nextInset()->lyxCode() == code) {
+ inset = static_cast(it.nextInset());
+ break;
+ }
+ it.forwardInset();
+ }
+ return inset;
+}
+
} // anon namespace
@@ -982,6 +1008,8 @@
case LFUN_MARK_ON:
case LFUN_SETMARK:
case LFUN_CENTER:
+ case LFUN_BIBDB_ADD:
+ case LFUN_BIBDB_DEL:
case LFUN_WORDS_COUNT:
flag.enabled(true);
break;
@@ -1212,6 +1240,22 @@
case LFUN_CENTER:
center();
break;
+
+ case LFUN_BIBDB_ADD: {
+ InsetBibtex * inset =
+ findInset(cursor_, InsetBase::BIBTEX_CODE);
+ if (inset)
+ inset->addDatabase(cmd.argument);
+ break;
+ }
+
+ case LFUN_BIBDB_DEL: {
+ InsetBibtex * inset =
+ findInset(cursor_, InsetBase::BIBTEX_CODE);
+ if (inset)
+ inset->delDatabase(cmd.argument);
+ break;
+ }
case LFUN_WORDS_COUNT: {
DocIterator from, to;
Index: LyXAction.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/LyXAction.C,v
retrieving revision 1.206
diff -u -r1.206 LyXAction.C
--- LyXAction.C 8 May 2005 10:02:37 - 1.206
+++ LyXAction.C 10 Jun 2005 08:36:22 -
@@ -188,6 +188,8 @@
{ LFUN_INSERT_LABEL, "label-insert", Noop },
{ LFUN_INSET_OPTARG, "optional-insert", Noop },
{ LFUN_INSERT_BIBITEM, "bibitem-insert", Noop },
+ { LFUN_BIBDB_ADD, "bibtex-database-add", Noop },
+ { LFUN_BIBDB_DEL, "bibtex-database-del", Noop },
{ LFUN_INSERT_LINE, "line-insert", Noop },
{ LFUN_INSERT_PAGEBREAK, "pagebreak-insert", Noop },
{ LFUN_LANGUAGE, "language", Noop },
Index: lfuns.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lfuns.h,v
retrieving revision 1.41
diff -u -r1.41 lfuns.h
--- lfuns.h 8 May 2005 10:02:37 - 1.41
+++ lfuns.h 10 Jun 2005 08:36:24 -
@@ -355,6 +355,8 @@
// 270
LFUN_WORDS_COUNT,
LFUN_OUTPUT_CHANGES, // jspitzm 20050121
+ LFUN_BIBDB_ADD,
+ LFUN_BIBDB_DEL,
LFUN_LASTACTION // end of the table
};
Index: insets/insetbibtex.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetbibtex.C,v
retrieving revision 1.54
diff -u -r1.54 insetbibtex.C
--- insets/insetbibtex.C 17 May 2005 11:11:45 - 1.54
+++ insets/insetbibtex.C 10 Jun 2005 08:36:37 -
@@ -271,7 +271,7 @@
bool InsetBibtex::addDatabase(string const & db)
{
string contents(getContents());
- if (!contains(contents, db)) {
+ if (tokenPos(contents, ',', db) == -1) {
if (!contents.empty())
contents += ',';
setContents(contents + db);
@@ -283,16 +283,17 @@
bool InsetBibtex::delDatabase(string const & db)
{
- if (contains(getContents(), db)) {
+ string contents(getContents());
+ if (contains(contents, db)) {
+ int const n = tokenPos(contents, ',', db);
string bd = db;
- int const n = tokenPos(getContents(), ',', bd);
if (n > 0) {
- // Weird code, would someone care to explain this?(Lgb)
- string tmp(", ");
- tmp += bd;
- setContents(subst(getContents(), tmp, ", "));
+ // this is not the first database
+ string tmp = ',' + bd;
+ setContents(subst(contents, tmp, ""));
} else if (n == 0)
- setContents(split(getContents(), bd, ','));
+ // this is the first (or only) database
+ setContents(split(contents, bd, ','));
else
return false;
}
