Hi all
Hi all, it's been over two years and I'm back to writing my PhD thesis. I shudder to think how much has changed since version 1.5 :) You can expect to hear more from me over the next couple of months. Is 2.0 close enough that I should start using it, or shall I get to know 1.6.x? Have fun, Darren
Hi all
Hi all, it's been over two years and I'm back to writing my PhD thesis. I shudder to think how much has changed since version 1.5 :) You can expect to hear more from me over the next couple of months. Is 2.0 close enough that I should start using it, or shall I get to know 1.6.x? Have fun, Darren
Re: [patch] GuiSymbols
On Sun, 2008-02-03 at 17:09 +0100, Jürgen Spitzmüller wrote: from the unicodesymbols list. It's quite similar to the symbols dialogs you know from the word processors (screenshot attached). Comments welcome. Wow, you use LyX in black and white? I should send you a new video card and monitor. I'll shut up now :) Have fun, Darren
Re: important info about the floatflt package and the LyX manuals
On Tue, 2008-02-05 at 08:00 +0100, Herbert Voss wrote: Uwe Stöhr schrieb: Generally speaking I think it sucks that the user guide doesn't compile out of the box. Have other popular (Linux) LaTeX distributions also skipped the floatflt package? TeXLive came up with the removal, others followed. For Linux TeXLive is the only active LaTeX-distribution I know. Generally speaking, it sucks that they discovered that floatflt has a nosell license after 10 years and not before! Argh. contact the author to change the license ... which is sometimes difficult after all these years. This happened with prettyref as well. I looked inside prettyref when I eventually found it, and saw how little it contained. Surely there is somebody knowledgeable enough to re-implement floatflt and contribute it to the distributions. Why didn't TeXLive do that before the removal? It must have irked more than just LyX users. Have fun, Darren
Re: [patch] GuiSymbols
On Sun, 2008-02-03 at 17:09 +0100, Jürgen Spitzmüller wrote: > from the unicodesymbols list. It's quite similar to the symbols dialogs you > know from the word processors (screenshot attached). > Comments welcome. Wow, you use LyX in black and white? I should send you a new video card and monitor. I'll shut up now :) Have fun, Darren
Re: important info about the floatflt package and the LyX manuals
On Tue, 2008-02-05 at 08:00 +0100, Herbert Voss wrote: > Uwe Stöhr schrieb: > > > > Generally speaking I think it sucks that the user guide doesn't > > compile out of the box. Have other > popular (Linux) LaTeX distributions > > also skipped the floatflt package? > > > > TeXLive came up with the removal, others followed. For Linux TeXLive is > > the only active LaTeX-distribution I know. > > Generally speaking, it sucks that they discovered that floatflt has a > > nosell license after 10 years and not before! Argh. > > contact the author to change the license ... > which is sometimes difficult after all these years. This happened with prettyref as well. I looked inside prettyref when I eventually found it, and saw how little it contained. Surely there is somebody knowledgeable enough to re-implement floatflt and contribute it to the distributions. Why didn't TeXLive do that before the removal? It must have irked more than just LyX users. Have fun, Darren
Re: Alt installer for 1.5.3 can't produce the user's guide
On Tue, 2008-01-29 at 21:49 +0100, Uwe Stöhr wrote: But I'm not able to actually vie the User's Guide as PDF. I get a latex error saying LaTeX Error: File 'floatflt.sty' not found.. Then your installation was not complete. Try to reinstall LyX and open an internet connection before doing this. another format. Of course this also requires an open internet connection. So the safest way is to install LyX with an open internet connection, then you can stay offline. Is this documented in the installer? I wouldn't have anticipated that. Have fun, Darren
Re: Alt installer for 1.5.3 can't produce the user's guide
On Tue, 2008-01-29 at 21:49 +0100, Uwe Stöhr wrote: > > But I'm not able to actually vie the User's Guide as PDF. I get a latex > error saying "LaTeX > Error: > File 'floatflt.sty' not found.". > > Then your installation was not complete. Try to reinstall LyX and open an > internet connection before > doing this. > another format. Of course this also requires an open internet connection. So > the safest way is to > install LyX with an open internet connection, then you can stay offline. Is this documented in the installer? I wouldn't have anticipated that. Have fun, Darren
Conflicts in branch
Why did so many files that I never modified just become conflicted? 888888 svn update svn status C po/cs.po C po/es.po C po/eu.po C po/ko.po C po/hu.po C po/ro.po C po/nb.po C po/gl.po C po/fr.po C po/nn.po C po/pl.po C po/it.po C po/pt.po C po/ca.po C po/tr.po C po/de.po C po/ja.po C po/zh_TW.po C po/he.po C po/fi.po C po/zh_CN.po
Re: Conflicts in branch
On Mon, 2008-01-28 at 18:15 +0100, Pavel Sanda wrote: Why did so many files that I never modified just become conflicted? because they get modified when making the sources. So why are they in the repository? Have fun, Darren
Conflicts in branch
Why did so many files that I never modified just become conflicted? 8<8<8<8<8<8< svn update svn status C po/cs.po C po/es.po C po/eu.po C po/ko.po C po/hu.po C po/ro.po C po/nb.po C po/gl.po C po/fr.po C po/nn.po C po/pl.po C po/it.po C po/pt.po C po/ca.po C po/tr.po C po/de.po C po/ja.po C po/zh_TW.po C po/he.po C po/fi.po C po/zh_CN.po
Re: Conflicts in branch
On Mon, 2008-01-28 at 18:15 +0100, Pavel Sanda wrote: > > Why did so many files that I never modified just become conflicted? > > because they get modified when making the sources. So why are they in the repository? Have fun, Darren
Re: Build fails in 1.5 branch
On Thu, 2008-01-17 at 09:34 +0100, Jürgen Spitzmüller wrote: Darren Freeman wrote: Making all in doc make[2]: Entering directory `/home/dfreeman/lyx-devel/lib/doc' cd ../.. /bin/sh /home/dfreeman/lyx-devel/config/missing --run automake-1.9 --foreign lib/doc/Makefile lib/doc/Makefile.depend:21: bad characters in variable name `' lib/doc/Makefile.am:230: `lib/doc/Makefile.depend' included from here make[2]: *** [Makefile.in] Error 1 make[2]: Leaving directory `/home/dfreeman/lyx-devel/lib/doc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/dfreeman/lyx-devel/lib' make: *** [all-recursive] Error 1 Do you have svn conflicts in that file? Indeed I do, according to svn status. Which is surprising considering I didn't think I applied any patches to this working copy. Also, po/POTFILES.in is listed as modified. It looks like I must have applied a patch after all, sorry for the false alarm! After reverting those two files, it built fine. I should have investigated before posting but I was on my way out. Have fun, Darren
Re: Build fails in 1.5 branch
On Thu, 2008-01-17 at 09:34 +0100, Jürgen Spitzmüller wrote: > Darren Freeman wrote: > > Making all in doc > > make[2]: Entering directory `/home/dfreeman/lyx-devel/lib/doc' > > cd ../.. && /bin/sh /home/dfreeman/lyx-devel/config/missing --run > > automake-1.9 --foreign lib/doc/Makefile > > lib/doc/Makefile.depend:21: bad characters in variable name `' > > lib/doc/Makefile.am:230: `lib/doc/Makefile.depend' included from here > > make[2]: *** [Makefile.in] Error 1 > > make[2]: Leaving directory `/home/dfreeman/lyx-devel/lib/doc' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory `/home/dfreeman/lyx-devel/lib' > > make: *** [all-recursive] Error 1 > > Do you have svn conflicts in that file? Indeed I do, according to "svn status". Which is surprising considering I didn't think I applied any patches to this working copy. Also, po/POTFILES.in is listed as modified. It looks like I must have applied a patch after all, sorry for the false alarm! After reverting those two files, it built fine. I should have investigated before posting but I was on my way out. Have fun, Darren
Build fails in 1.5 branch
Making all in doc make[2]: Entering directory `/home/dfreeman/lyx-devel/lib/doc' cd ../.. /bin/sh /home/dfreeman/lyx-devel/config/missing --run automake-1.9 --foreign lib/doc/Makefile lib/doc/Makefile.depend:21: bad characters in variable name `' lib/doc/Makefile.am:230: `lib/doc/Makefile.depend' included from here make[2]: *** [Makefile.in] Error 1 make[2]: Leaving directory `/home/dfreeman/lyx-devel/lib/doc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/dfreeman/lyx-devel/lib' make: *** [all-recursive] Error 1
Build fails in 1.5 branch
Making all in doc make[2]: Entering directory `/home/dfreeman/lyx-devel/lib/doc' cd ../.. && /bin/sh /home/dfreeman/lyx-devel/config/missing --run automake-1.9 --foreign lib/doc/Makefile lib/doc/Makefile.depend:21: bad characters in variable name `' lib/doc/Makefile.am:230: `lib/doc/Makefile.depend' included from here make[2]: *** [Makefile.in] Error 1 make[2]: Leaving directory `/home/dfreeman/lyx-devel/lib/doc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/dfreeman/lyx-devel/lib' make: *** [all-recursive] Error 1
Re: Export - what the heck happened?
On Wed, 2008-01-09 at 07:25 -0500, [EMAIL PROTECTED] wrote: What a step backwards! FYI you have been quite impolite in your request for help. (Or is it a complaint?) That part of LyX has not been changed on purpose. You have either encountered a bug in LyX or you have a problem in the rest of your system. It is fair for the developers to enquire about your system because nobody else has this problem. Have fun, Darren
Middle-click paste in branch
Guys, I hate to be a pain, but there is yet another middle-click paste issue in the latest 1.5 branch under Linux. I select text in LyX and middle-click another app, and get an earlier selection which isn't from LyX. Shall I add/reopen a bug? Have fun, Darren
Re: Middle-click paste in branch
Also regular copy-paste fails. From LyX to Evolution. This is *bad*. Have fun, Darren On Thu, 2008-01-10 at 10:22 +1100, Darren Freeman wrote: Guys, I hate to be a pain, but there is yet another middle-click paste issue in the latest 1.5 branch under Linux. I select text in LyX and middle-click another app, and get an earlier selection which isn't from LyX. Shall I add/reopen a bug? Have fun, Darren
Re: Export - what the heck happened?
On Wed, 2008-01-09 at 13:01 -0500, [EMAIL PROTECTED] wrote: Reconfigure did the trick. Reconfigure should be run automatically on first startup and maybe every ... it does ... time LyX exits and IMO should not really be a user option. It takes a long time on slow machines. It may trash some manual adjustments, and thus be aggravating to some users. There is NO WAY I could have figure this out. It's in the User Guide! Under Export. If one of the menu entries DVI, PDF (pdflatex) or Postscript is missing, you need to ... reconfigure LyX Also, 1.4 Basic LyX Setup, which is only 8 paragraphs into the User Guide. So quit with the whining already. Best is as I said, to run reconfigure automatically at every exit (as you need to restart to activate it) See above. Have fun, Darren
Re: Middle-click paste in branch
On Thu, 2008-01-10 at 10:23 +1100, Darren Freeman wrote: Also regular copy-paste fails. From LyX to Evolution. This is *bad*. It's even worse - middle-click and regular copy-paste fail from outside apps into LyX. Nothing can be copy/pasted to or from LyX using either mechanism. Could somebody using the 1.5 branch please confirm? Have fun, Darren
Re: Middle-click paste in branch
On Thu, 2008-01-10 at 14:06 +1100, Darren Freeman wrote: It's even worse - middle-click and regular copy-paste fail from outside apps into LyX. My mistake. This one is a bug in MATLAB, which on Linux is a buggy piece of sh*t. So it's just a problem going from LyX to the outside. I think :) Have fun, Darren
Re: Export - what the heck happened?
On Wed, 2008-01-09 at 07:25 -0500, [EMAIL PROTECTED] wrote: > What a step backwards! FYI you have been quite impolite in your request for help. (Or is it a complaint?) That part of LyX has not been changed on purpose. You have either encountered a bug in LyX or you have a problem in the rest of your system. It is fair for the developers to enquire about your system because nobody else has this problem. Have fun, Darren
Middle-click paste in branch
Guys, I hate to be a pain, but there is yet another middle-click paste issue in the latest 1.5 branch under Linux. I select text in LyX and middle-click another app, and get an earlier selection which isn't from LyX. Shall I add/reopen a bug? Have fun, Darren
Re: Middle-click paste in branch
Also regular copy-paste fails. From LyX to Evolution. This is *bad*. Have fun, Darren On Thu, 2008-01-10 at 10:22 +1100, Darren Freeman wrote: > Guys, > > I hate to be a pain, but there is yet another middle-click paste issue > in the latest 1.5 branch under Linux. > > I select text in LyX and middle-click another app, and get an earlier > selection which isn't from LyX. > > Shall I add/reopen a bug? > > Have fun, > Darren
Re: Export - what the heck happened?
On Wed, 2008-01-09 at 13:01 -0500, [EMAIL PROTECTED] wrote: > Reconfigure did the trick. > Reconfigure should be run automatically on first startup and maybe every ... it does ... > time LyX exits and IMO should not really be a user option. It takes a long time on slow machines. It may trash some manual adjustments, and thus be "aggravating" to some users. > There is NO WAY I could have figure this out. It's in the User Guide! Under "Export". "If one of the menu entries DVI, PDF (pdflatex) or Postscript is missing, you need to ... reconfigure LyX" Also, "1.4 Basic LyX Setup", which is only 8 paragraphs into the User Guide. So quit with the whining already. > Best is as I said, to run reconfigure automatically at every exit (as > you need to restart to activate it) See above. Have fun, Darren
Re: Middle-click paste in branch
On Thu, 2008-01-10 at 10:23 +1100, Darren Freeman wrote: > Also regular copy-paste fails. From LyX to Evolution. > > This is *bad*. It's even worse - middle-click and regular copy-paste fail from outside apps into LyX. Nothing can be copy/pasted to or from LyX using either mechanism. Could somebody using the 1.5 branch please confirm? Have fun, Darren
Re: Middle-click paste in branch
On Thu, 2008-01-10 at 14:06 +1100, Darren Freeman wrote: > It's even worse - middle-click and regular copy-paste fail from outside > apps into LyX. My mistake. This one is a bug in MATLAB, which on Linux is a buggy piece of sh*t. So it's just a problem going from LyX to the outside. I think :) Have fun, Darren
Re: [patch] Re: xdg-open
On Tue, 2008-01-08 at 13:51 +0100, Helge Hafting wrote: Well . . . windows may have 90% of the users, but I am not sure they have a better user-experience. They seem to believe that occational crashes and such is normal. . . ;-) Can we get them to test the trunk then? They did this for M$ W0rd for a few years :) Have fun, Darren
Re: [patch] Re: xdg-open
On Tue, 2008-01-08 at 13:51 +0100, Helge Hafting wrote: > Well . . . windows may have 90% of the users, but I am not sure > they have a better user-experience. They seem to believe that > occational crashes and such is "normal". . . ;-) Can we get them to test the trunk then? They did this for M$ W0rd for a few years :) Have fun, Darren
Re: xdg-open
On Sat, 2008-01-05 at 15:52 +0100, Pavel Sanda wrote: as a consequence of including xdg-open for our viewers i got for any viewing of ps/dvi/pdf files firstly firefox opened and after that actual viewer opened (through the firefox own mechanism, which at the end means i'm not able to view dvi at all eg). anyone else facing this ? That sounds like what happened to me yesterday! But because I was running it remotely and Firefox was already running on the local display, I instead got a message that I should first close my existing Firefox session before trying again. Most annoying! I was successful at viewing as DVI though. Have fun, Darren
Re: xdg-open
On Sat, 2008-01-05 at 10:50 -0500, rgheck wrote: xdg-open is supposed just to open whatever viewer you have defined for the relevant file type. If you're not using one of the desktops for which it is defined (KDE, Gnome, XFCE) and, moreover, don't have But I am using KDE. Is it possible that by using ssh to remotely log in and use LyX, I am missing the required environment variable? Have fun, Darren
Re: xdg-open
On Sat, 2008-01-05 at 15:52 +0100, Pavel Sanda wrote: > as a consequence of including xdg-open for our viewers i got > for any viewing of ps/dvi/pdf files firstly firefox opened > and after that actual viewer opened (through the firefox own mechanism, > which at the end means i'm not able to view dvi at all eg). > > anyone else facing this ? That sounds like what happened to me yesterday! But because I was running it remotely and Firefox was already running on the local display, I instead got a message that I should first close my existing Firefox session before trying again. Most annoying! I was successful at viewing as DVI though. Have fun, Darren
Re: xdg-open
On Sat, 2008-01-05 at 10:50 -0500, rgheck wrote: > xdg-open is supposed just to open whatever viewer you have defined for > the relevant file type. If you're not using one of the desktops for > which it is defined (KDE, Gnome, XFCE) and, moreover, don't have But I am using KDE. Is it possible that by using ssh to remotely log in and use LyX, I am missing the required environment variable? Have fun, Darren
Installation failed on Mandrake 10.1
Hi all, I just compiled the latest 1.5 branch on Mandrake 10.1. I only had to specify the nonstandard qt4 directory as Mandrake 10.1 doesn't ship with it. After successfully building and installing, I was greeted with the following error dialogue when starting LyX: 88888 Unable to determine the system directory having searched /usr/local/share/lyx/./ Use the '-sysdir' command line parameter or set the environment variable LYX_DIR_15x to the LyX system directory containing the file `chkconfig.ltx'. 88888 It turns out that /usr/local/share/lyx was created with ownership root.root and mode 700. I found that the subdirectories also had modes of 700, while the files were 644 as expected. (Except for the scripts which had execute permission, also as expected.) After adding group/all read+execute permissions to the directories in the tree, LyX worked as normal. Have fun, Darren
Installation failed on Mandrake 10.1
Hi all, I just compiled the latest 1.5 branch on Mandrake 10.1. I only had to specify the nonstandard qt4 directory as Mandrake 10.1 doesn't ship with it. After successfully building and installing, I was greeted with the following error dialogue when starting LyX: 8<8<8<8<8< Unable to determine the system directory having searched /usr/local/share/lyx/./ Use the '-sysdir' command line parameter or set the environment variable LYX_DIR_15x to the LyX system directory containing the file `chkconfig.ltx'. 8<8<8<8<8< It turns out that /usr/local/share/lyx was created with ownership root.root and mode 700. I found that the subdirectories also had modes of 700, while the files were 644 as expected. (Except for the scripts which had execute permission, also as expected.) After adding group/all read+execute permissions to the directories in the tree, LyX worked as normal. Have fun, Darren
Re: CharStyle metrics broken in 1.5.3
On Sun, 2007-12-23 at 11:46 +0100, Abdelrazak Younes wrote: Darren Freeman wrote: On Sat, 2007-12-22 at 16:56 +0100, Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: Here is the patch. Please commit it yourself as I have to go. Done. I suggest a 1.5.4 release ASAP. No need to hurry IMO. Why not keep the branch somewhat frozen and release 1.5.3.1 after another week of fixing/testing? I suggest that you use the version from the 1.5 svn branch instead of 1.5.3. This is what all LyX developers (should) do. It would be wonderful if more advanced users (like you?) do the same. This would help us catch more bugs like this one before the actual release. I've been using the branch for as long as it existed :) Check out the number of bugs I've posted. I haven't had time to even verify the bug for myself, I was just going on the comments about how horrible it is. I saw no indication that 1.5.4 was imminent, and then I had a week of unread posts from the list which culminated in the release. I first realised there had been a release from the changes to bugzilla. Have fun, Darren
Re: CharStyle metrics broken in 1.5.3
On Sun, 2007-12-23 at 11:46 +0100, Abdelrazak Younes wrote: > Darren Freeman wrote: > > On Sat, 2007-12-22 at 16:56 +0100, Jürgen Spitzmüller wrote: > >> Abdelrazak Younes wrote: > >>> Here is the patch. Please commit it yourself as I have to go. > >> Done. > >> > >>> I suggest a 1.5.4 release ASAP. > >> No need to hurry IMO. > > > > Why not keep the branch somewhat frozen and release 1.5.3.1 after > > another week of fixing/testing? > > I suggest that you use the version from the 1.5 svn branch instead of > 1.5.3. This is what all LyX developers (should) do. It would be > wonderful if more advanced users (like you?) do the same. This would > help us catch more bugs like this one before the actual release. I've been using the branch for as long as it existed :) Check out the number of bugs I've posted. I haven't had time to even verify the bug for myself, I was just going on the comments about how horrible it is. I saw no indication that 1.5.4 was imminent, and then I had a week of unread posts from the list which culminated in the release. I first realised there had been a release from the changes to bugzilla. Have fun, Darren
Re: CharStyle metrics broken in 1.5.3
On Sat, 2007-12-22 at 16:56 +0100, Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: Here is the patch. Please commit it yourself as I have to go. Done. I suggest a 1.5.4 release ASAP. No need to hurry IMO. Why not keep the branch somewhat frozen and release 1.5.3.1 after another week of fixing/testing? Have fun, Darren
Re: CharStyle metrics broken in 1.5.3
On Sat, 2007-12-22 at 16:56 +0100, Jürgen Spitzmüller wrote: > Abdelrazak Younes wrote: > > Here is the patch. Please commit it yourself as I have to go. > > Done. > > > I suggest a 1.5.4 release ASAP. > > No need to hurry IMO. Why not keep the branch somewhat frozen and release 1.5.3.1 after another week of fixing/testing? Have fun, Darren
Re: Approaching LyX 1.5.3 [status update #3]
On Sat, 2007-12-08 at 17:56 +0100, Jürgen Spitzmüller wrote: consistent on screen looking Sounds part Japanese to me :) Have fun, Darren
Re: Approaching LyX 1.5.3 [status update #3]
On Sat, 2007-12-08 at 17:56 +0100, Jürgen Spitzmüller wrote: > consistent on screen looking Sounds part Japanese to me :) Have fun, Darren
Re: Problem with the toclevel of chapter* in book.layout.
On Wed, 2007-11-21 at 11:13 +, Bo Peng wrote: Open tutorial, change the layout of the introduction chapter header to chapter *, it disappear from Toc (and navigation menu). Anyone knows a quick fix? I know it's been like that for a while :) http://bugzilla.lyx.org/show_bug.cgi?id=3888 Have fun, Darren
Re: Problem with the toclevel of chapter* in book.layout.
On Wed, 2007-11-21 at 11:13 +, Bo Peng wrote: > Open tutorial, change the layout of the introduction chapter header to > chapter *, it disappear from Toc (and navigation menu). Anyone knows a > quick fix? I know it's been like that for a while :) http://bugzilla.lyx.org/show_bug.cgi?id=3888 Have fun, Darren
Command-line export?
Hi all, this would be a nice idea if somebody wanted to implement it :) I am working on a large-ish document (thesis) and would like to be able to log into the machine which houses it, and from the command-line tell LyX to do a PDF export, so I can rsync it to myself for showing somebody. What would also probably be useful to somebody, is to invoke the LyX format conversion chain from the command-line. So I could convert a JPG to an EPS from the command-line, assuming LyX is configured for it at the time. Have fun, Darren
Re: Command-line export?
On Wed, 2007-11-14 at 11:15 +0100, Abdelrazak Younes wrote: This is already implemented. Try lyx -e pdf xxx.lyx. Is it documented? How do I tell which of the three pdf exports I'm getting? (And for that matter, why are there three, and why should I care which I'm using?) Have fun, Darren
Re: Command-line export?
On Wed, 2007-11-14 at 13:01 +0100, Abdelrazak Younes wrote: Darren Freeman wrote: Is it documented? D:\devel\lyx\trunk\development\cmake\bin\releaselyx -help Never ran that before :) How do I tell which of the three pdf exports I'm getting? (And for that matter, why are there three, and why should I care which I'm using?) This is a rhetorical and recurrent question... It's not rhetorical at all, I'd like an answer :D I'm always paranoid that I'm generating a 'bad' PDF or that something else might be changing if I don't stick to the same one.. but then which one should I use? :) Perhaps the configure script should attempt to bind them one at a time to PDF until one has all the necessary executables installed to succeed in exporting a test file. This would be cool for some of the other formats too if multiple methods can be found. Have fun, Darren
Re: Command-line export?
On Wed, 2007-11-14 at 16:31 +0100, Helge Hafting wrote: Darren Freeman wrote: I'm always paranoid that I'm generating a 'bad' PDF or that something else might be changing if I don't stick to the same one.. but then which one should I use? :) pdflatex is the _fastest_ by far - a good reason for using that one. You also need pdflatex if you want to use the microtype package for improving line breaking and hyphenation. dvipdfm is slower, and hasn't been maintained for some time. ps2pdf is the slowest of all, but it is necessary if you use the pstricks package for your figures. I normally use this one because it's bound to the 'P' so I figure it's got to be the preferred one. (Now you tell me it's the slowest!!) But if I'm submitting a paper in which I have to first export to tex and manually generate a proof PDF, I use pdflatex because I'm used to it at the command line.. I'm just following what I know without really understanding in this case :) So how do I know if I'm using pstricks? I don't use it on purpose, but does LyX use it in certain cases? Then I would have been making an error in the above paragraph and not knowing it. Perhaps the configure script should attempt to bind them one at a time to PDF until one has all the necessary executables installed to succeed in exporting a test file. This would be cool for some of the other formats too if multiple methods can be found. The three ways aren't equivalent, only almost equivalent. Yay. If this is true then it *must* be documented. It's not fair that I've gone this long without an explanation. What's worse, my intuition failed to give the right answer, and I think the only case where documentation is optional is where intuition succeeds. What about having the three methods named pdf1, pdf2, pdf3, and then the configure script aliases the first successful method as pdf (using some kind of converter alias implementation), which is the only one that appears in the menu? If the user changes pdf to point to another, then when the configure script is run again it keeps the changed alias unless it happens to fail when tested. If pdf doesn't exist at all, then all three appear in the menu. This convention could be followed when building the menu, that xxxn wouldn't appear if xxx exists, where xxx is a word and n is a digit. Have fun, Darren
Command-line export?
Hi all, this would be a nice idea if somebody wanted to implement it :) I am working on a large-ish document (thesis) and would like to be able to log into the machine which houses it, and from the command-line tell LyX to do a PDF export, so I can rsync it to myself for showing somebody. What would also probably be useful to somebody, is to invoke the LyX format conversion chain from the command-line. So I could convert a JPG to an EPS from the command-line, assuming LyX is configured for it at the time. Have fun, Darren
Re: Command-line export?
On Wed, 2007-11-14 at 11:15 +0100, Abdelrazak Younes wrote: > This is already implemented. Try "lyx -e pdf xxx.lyx". Is it documented? How do I tell which of the three pdf exports I'm getting? (And for that matter, why are there three, and why should I care which I'm using?) Have fun, Darren
Re: Command-line export?
On Wed, 2007-11-14 at 13:01 +0100, Abdelrazak Younes wrote: > Darren Freeman wrote: > > Is it documented? > D:\devel\lyx\trunk\development\cmake\bin\release>lyx -help Never ran that before :) > > How do I tell which of the three pdf exports I'm > > getting? > > (And for that matter, why are there three, and why should I care which > > I'm using?) > > This is a rhetorical and recurrent question... It's not rhetorical at all, I'd like an answer :D I'm always paranoid that I'm generating a 'bad' PDF or that something else might be changing if I don't stick to the same one.. but then which one should I use? :) Perhaps the configure script should attempt to bind them one at a time to PDF until one has all the necessary executables installed to succeed in exporting a test file. This would be cool for some of the other formats too if multiple methods can be found. Have fun, Darren
Re: Command-line export?
On Wed, 2007-11-14 at 16:31 +0100, Helge Hafting wrote: > Darren Freeman wrote: > > I'm always paranoid that I'm generating a 'bad' PDF or that something > > else might be changing if I don't stick to the same one.. but then which > > one should I use? :) > > > pdflatex is the _fastest_ by far - a good reason for using that one. > You also need pdflatex if you want to use the microtype package for > improving line breaking and hyphenation. > > dvipdfm is slower, and hasn't been maintained for some time. > > ps2pdf is the slowest of all, but it is necessary if you use the > pstricks package for your figures. I normally use this one because it's bound to the 'P' so I figure it's got to be the preferred one. (Now you tell me it's the slowest!!) But if I'm submitting a paper in which I have to first export to tex and manually generate a proof PDF, I use pdflatex because I'm used to it at the command line.. I'm just following what I know without really understanding in this case :) So how do I know if I'm using pstricks? I don't use it on purpose, but does LyX use it in certain cases? Then I would have been making an error in the above paragraph and not knowing it. > > Perhaps the configure script should attempt to bind them one at a time > > to PDF until one has all the necessary executables installed to succeed > > in exporting a test file. This would be cool for some of the other > > formats too if multiple methods can be found. > > > The three ways aren't equivalent, only almost equivalent. Yay. If this is true then it *must* be documented. It's not fair that I've gone this long without an explanation. What's worse, my intuition failed to give the right answer, and I think the only case where documentation is optional is where intuition succeeds. What about having the three methods named pdf1, pdf2, pdf3, and then the configure script aliases the first successful method as pdf (using some kind of converter alias implementation), which is the only one that appears in the menu? If the user changes pdf to point to another, then when the configure script is run again it keeps the changed alias unless it happens to fail when tested. If pdf doesn't exist at all, then all three appear in the menu. This convention could be followed when building the menu, that xxxn wouldn't appear if xxx exists, where xxx is a word and n is a digit. Have fun, Darren
Re: LaTeX in-table computations.
On Sun, 2007-11-11 at 01:16 +0100, Tommaso Cucinotta wrote: I wish it were possible to make simple computations within table cells, like summing up all the rows or columns and computing If you wanted to see the results of the computation in LyX, rather than just in the generated output, you would be suggesting a basic embedded spreadsheet within LyX.. given the state of tables in LyX, I'm just happy that they seem to work a lot of the time :) Try to add a column to the end of a table and see the double cell border. Or delete the last column and get no border. Hilarious. Have fun, Darren
Re: LaTeX in-table computations.
On Sun, 2007-11-11 at 01:16 +0100, Tommaso Cucinotta wrote: > I wish it were possible to make simple computations within > table cells, like summing up all the rows or columns and computing If you wanted to see the results of the computation in LyX, rather than just in the generated output, you would be suggesting a basic embedded spreadsheet within LyX.. given the state of tables in LyX, I'm just happy that they seem to work a lot of the time :) Try to add a column to the end of a table and see the double cell border. Or delete the last column and get no border. Hilarious. Have fun, Darren
Re: [Bug 4323] Crash on adding/removing row/column of a matrix in mathed.
On Mon, 2007-11-05 at 12:02 +0200, Martin Vermeer wrote: It's in, for both trunk and branch. No status.15x entry, as it is functionality-neutral together with my earlier patch. Bravo, team! I posted the two related bugs at 4:51pm and the fix was committed that afternoon! (Your message is 9:02pm my time - roughly 4h elapsed.) Even more impressive - two developers were involved. I think this counts as a win for free software! Compare to, say, National Instruments, to whom I delivered a self-contained test case which can hard lock up a Linux box running their proprietary drivers (kernel module + .so). A year and a half after they finally admitted to the problem, which forces me to run the cards 80% under spec, no further release of any kind. And we paid them AU$2000 times 5 cards. You guys got nothing but pure street cred :D Have fun, Darren
Re: [Bug 4323] Crash on adding/removing row/column of a matrix in mathed.
On Mon, 2007-11-05 at 09:54 +0200, Martin Vermeer wrote: Unfortunately it is still impossible to insert an empty row/column at position 0. We should perhaps think about that too. Why not have two menu items: * Add Column (before) * Add Column (after) The one people are used to would have a certain keybinding, and the other would have an extra meta key, such as shift, as part of the binding. (similarly for rows) BTW I reopened the bug as part of it is not fixed in branch - adding a column still crashes and I presume the other similar cases do to. Have fun, Darren
Re: [Bug 4323] Crash on adding/removing row/column of a matrix in mathed.
BTW I reopened the bug as part of it is not fixed in branch - adding a column still crashes and I presume the other similar cases do to. Would you believe I forgot to make install ? It's fixed :D However there is a remaining issue that the cursor moves in a weird manner when adding columns (I haven't tested very much, probably other cases). The cursor can visibly move twice and then end up somewhere other than where it started.. which isn't the expected behaviour when adding a column. I have also seen a multiple element selection (three in a row) appear for no reason during the above process. This might be considered a separate bug. Anyone confirm? I can file another report if needed. Have fun, Darren
Toggle numbering on formula
Hi all, okay I finally worked out how to get formula numbering to work.. you have to toggle display mode first. Why doesn't this happen automatically? Or if there is a good reason, why do nothing when the user selects toggle numbering? The menu item should at least be inactive. Have fun, Darren
[Bug 4334] Crash when adding label to math.
Hi all, another mathed-related crash in branch. http://bugzilla.lyx.org/show_bug.cgi?id=4334 Somebody please confirm and add the keyword crash. Have fun, Darren
Removing an equation label
Hi all, is there a more elegant way to remove an equation label than toggling the line numbering twice? I ask this because copy-paste of a labelled equation results in two with the same label. I wanted the second one to be anonymous but numbered. Have fun, Darren
Re: [Bug 4323] Crash on adding/removing row/column of a matrix in mathed.
On Mon, 2007-11-05 at 12:02 +0200, Martin Vermeer wrote: > It's in, for both trunk and branch. No status.15x entry, as it is > functionality-neutral together with my earlier patch. Bravo, team! I posted the two related bugs at 4:51pm and the fix was committed that afternoon! (Your message is 9:02pm my time - roughly 4h elapsed.) Even more impressive - two developers were involved. I think this counts as a win for free software! Compare to, say, National Instruments, to whom I delivered a self-contained test case which can hard lock up a Linux box running their proprietary drivers (kernel module + .so). A year and a half after they finally admitted to the problem, which forces me to run the cards 80% under spec, no further release of any kind. And we paid them AU$2000 times 5 cards. You guys got nothing but pure street cred :D Have fun, Darren
Re: [Bug 4323] Crash on adding/removing row/column of a matrix in mathed.
On Mon, 2007-11-05 at 09:54 +0200, Martin Vermeer wrote: > Unfortunately it is still impossible to insert an empty row/column at > position 0. We should perhaps think about that too. Why not have two menu items: * Add Column (before) * Add Column (after) The one people are used to would have a certain keybinding, and the other would have an extra meta key, such as shift, as part of the binding. (similarly for rows) BTW I reopened the bug as part of it is not fixed in branch - adding a column still crashes and I presume the other similar cases do to. Have fun, Darren
Re: [Bug 4323] Crash on adding/removing row/column of a matrix in mathed.
"BTW I reopened the bug as part of it is not fixed in branch - adding a column still crashes and I presume the other similar cases do to." Would you believe I forgot to "make install" ? It's fixed :D However there is a remaining issue that the cursor moves in a weird manner when adding columns (I haven't tested very much, probably other cases). The cursor can visibly move twice and then end up somewhere other than where it started.. which isn't the expected behaviour when adding a column. I have also seen a multiple element selection (three in a row) appear for no reason during the above process. This might be considered a separate bug. Anyone confirm? I can file another report if needed. Have fun, Darren
Toggle numbering on formula
Hi all, okay I finally worked out how to get formula numbering to work.. you have to toggle display mode first. Why doesn't this happen automatically? Or if there is a good reason, why do nothing when the user selects toggle numbering? The menu item should at least be inactive. Have fun, Darren
[Bug 4334] Crash when adding label to math.
Hi all, another mathed-related crash in branch. http://bugzilla.lyx.org/show_bug.cgi?id=4334 Somebody please confirm and add the keyword "crash". Have fun, Darren
Removing an equation label
Hi all, is there a more elegant way to remove an equation label than toggling the line numbering twice? I ask this because copy-paste of a labelled equation results in two with the same label. I wanted the second one to be anonymous but numbered. Have fun, Darren
Re: Compilation problems (trunk branch)
On Sat, 2007-11-03 at 23:25 +0100, Abdelrazak Younes wrote: Please try again with latest rev. Abdel. PS: Sorry Juergen I didn't wait but this is an urgency. Fixed. Have fun, Darren
[Bug 4323] Crash on adding/removing row/column of a matrix in mathed.
Hi all, could somebody please (try to) confirm this crash in branch? Assuming it's new, I think it should be fixed for 1.5.3. http://bugzilla.lyx.org/show_bug.cgi?id=4323 Have fun, Darren
Re: Compilation problems (trunk & branch)
On Sat, 2007-11-03 at 23:25 +0100, Abdelrazak Younes wrote: > Please try again with latest rev. > > Abdel. > > PS: Sorry Juergen I didn't wait but this is an urgency. Fixed. Have fun, Darren
[Bug 4323] Crash on adding/removing row/column of a matrix in mathed.
Hi all, could somebody please (try to) confirm this crash in branch? Assuming it's new, I think it should be fixed for 1.5.3. http://bugzilla.lyx.org/show_bug.cgi?id=4323 Have fun, Darren
1.5 branch won't compile
Hi all, you'll love this :) The 1.5 stable branch won't compile for me today. See below for the relevant error. Today's revision that failed is r21399. I went backward to find the most recent revision which compiles, which is r21356. The change which broke it is therefore r21357. I'll now do a fresh build of the next revision just to be sure. If I don't write back then assume it failed again. Have fun, Darren 88888 make[7]: Entering directory `/home/dfreeman/lyx-devel/src/frontends/qt4' if /bin/sh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -Winvalid-pch --include=./pch.h -I../../../src -I../../../src/frontends -I../../../images -DQT_SHARED -I/usr/include/QtCore -I/usr/include/QtGui -I../../../boost -I../../../src/frontends/controllers -Wextra -Wall -g -O -MT Dialogs.lo -MD -MP -MF .deps/Dialogs.Tpo -c -o Dialogs.lo Dialogs.cpp; \ then mv -f .deps/Dialogs.Tpo .deps/Dialogs.Plo; else rm -f .deps/Dialogs.Tpo; exit 1; fi g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -Winvalid-pch --include=./pch.h -I../../../src -I../../../src/frontends -I../../../images -DQT_SHARED -I/usr/include/QtCore -I/usr/include/QtGui -I../../../boost -I../../../src/frontends/controllers -Wextra -Wall -g -O -MT Dialogs.lo -MD -MP -MF .deps/Dialogs.Tpo -c Dialogs.cpp -o Dialogs.o ui/PrefUi.h: In member function 'void Ui_QPrefUi::setupUi(QWidget*)': ui/PrefUi.h:123: error: 'class QGridLayout' has no member named 'setLeftMargin' ui/PrefUi.h:124: error: 'class QGridLayout' has no member named 'setTopMargin' ui/PrefUi.h:125: error: 'class QGridLayout' has no member named 'setRightMargin' ui/PrefUi.h:126: error: 'class QGridLayout' has no member named 'setBottomMargin' ui/PrefUi.h:127: error: 'class QGridLayout' has no member named 'setHorizontalSpacing' ui/PrefUi.h:128: error: 'class QGridLayout' has no member named 'setVerticalSpacing' ui/PrefUi.h:158: error: 'class QHBoxLayout' has no member named 'setLeftMargin' ui/PrefUi.h:159: error: 'class QHBoxLayout' has no member named 'setTopMargin' ui/PrefUi.h:160: error: 'class QHBoxLayout' has no member named 'setRightMargin' ui/PrefUi.h:161: error: 'class QHBoxLayout' has no member named 'setBottomMargin' ui/PrefUi.h:211: error: 'class QVBoxLayout' has no member named 'setLeftMargin' ui/PrefUi.h:212: error: 'class QVBoxLayout' has no member named 'setTopMargin' ui/PrefUi.h:213: error: 'class QVBoxLayout' has no member named 'setRightMargin' ui/PrefUi.h:214: error: 'class QVBoxLayout' has no member named 'setBottomMargin' ui/PrefUi.h:223: error: 'class QHBoxLayout' has no member named 'setLeftMargin' ui/PrefUi.h:224: error: 'class QHBoxLayout' has no member named 'setTopMargin' ui/PrefUi.h:225: error: 'class QHBoxLayout' has no member named 'setRightMargin' ui/PrefUi.h:226: error: 'class QHBoxLayout' has no member named 'setBottomMargin' ui/PrefUi.h:254: error: 'class QHBoxLayout' has no member named 'setLeftMargin' ui/PrefUi.h:255: error: 'class QHBoxLayout' has no member named 'setTopMargin' ui/PrefUi.h:256: error: 'class QHBoxLayout' has no member named 'setRightMargin' ui/PrefUi.h:257: error: 'class QHBoxLayout' has no member named 'setBottomMargin' ui/PrefUi.h:281: error: 'class QVBoxLayout' has no member named 'setLeftMargin' ui/PrefUi.h:282: error: 'class QVBoxLayout' has no member named 'setTopMargin' ui/PrefUi.h:283: error: 'class QVBoxLayout' has no member named 'setRightMargin' ui/PrefUi.h:284: error: 'class QVBoxLayout' has no member named 'setBottomMargin' make[7]: *** [Dialogs.lo] Error 1 make[7]: Leaving directory `/home/dfreeman/lyx-devel/src/frontends/qt4' make[6]: *** [all-recursive] Error 1 make[6]: Leaving directory `/home/dfreeman/lyx-devel/src/frontends/qt4' make[5]: *** [all] Error 2 make[5]: Leaving directory `/home/dfreeman/lyx-devel/src/frontends/qt4' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/dfreeman/lyx-devel/src/frontends' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/dfreeman/lyx-devel/src/frontends' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/dfreeman/lyx-devel/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/dfreeman/lyx-devel/src' make: *** [all-recursive] Error 1
Re: 1.5 branch won't compile
On Sat, 2007-11-03 at 19:27 +1100, Darren Freeman wrote: Today's revision that failed is r21399. I went backward to find the most recent revision which compiles, which is r21356. The change which broke it is therefore r21357. Sorry, I'm off-by-one. The version which compiles is r21357 and the break occurred at r21358. Have fun, Darren
Re: 1.5 branch won't compile
On Sat, 2007-11-03 at 10:17 +0100, Abdelrazak Younes wrote: Darren Freeman wrote: On Sat, 2007-11-03 at 19:27 +1100, Darren Freeman wrote: Today's revision that failed is r21399. I went backward to find the most recent revision which compiles, which is r21356. The change which broke it is therefore r21357. Sorry, I'm off-by-one. The version which compiles is r21357 and the break occurred at r21358. Are you sure it's not 21368? Sorry off-by-10 :) Must have been having a bout of dyslexia... If yes, then looks like you used Qt 4.3 Juergen... I'm using 4.2.1 (stock RPM from OpenSUSE). Have fun, Darren
1.5 branch won't compile
Hi all, you'll love this :) The 1.5 "stable" branch won't compile for me today. See below for the relevant error. Today's revision that failed is r21399. I went backward to find the most recent revision which compiles, which is r21356. The change which broke it is therefore r21357. I'll now do a fresh build of the next revision just to be sure. If I don't write back then assume it failed again. Have fun, Darren 8<8<8<8<8< make[7]: Entering directory `/home/dfreeman/lyx-devel/src/frontends/qt4' if /bin/sh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -Winvalid-pch --include=./pch.h -I../../../src -I../../../src/frontends -I../../../images -DQT_SHARED -I/usr/include/QtCore -I/usr/include/QtGui -I../../../boost -I../../../src/frontends/controllers -Wextra -Wall -g -O -MT Dialogs.lo -MD -MP -MF ".deps/Dialogs.Tpo" -c -o Dialogs.lo Dialogs.cpp; \ then mv -f ".deps/Dialogs.Tpo" ".deps/Dialogs.Plo"; else rm -f ".deps/Dialogs.Tpo"; exit 1; fi g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -Winvalid-pch --include=./pch.h -I../../../src -I../../../src/frontends -I../../../images -DQT_SHARED -I/usr/include/QtCore -I/usr/include/QtGui -I../../../boost -I../../../src/frontends/controllers -Wextra -Wall -g -O -MT Dialogs.lo -MD -MP -MF .deps/Dialogs.Tpo -c Dialogs.cpp -o Dialogs.o ui/PrefUi.h: In member function 'void Ui_QPrefUi::setupUi(QWidget*)': ui/PrefUi.h:123: error: 'class QGridLayout' has no member named 'setLeftMargin' ui/PrefUi.h:124: error: 'class QGridLayout' has no member named 'setTopMargin' ui/PrefUi.h:125: error: 'class QGridLayout' has no member named 'setRightMargin' ui/PrefUi.h:126: error: 'class QGridLayout' has no member named 'setBottomMargin' ui/PrefUi.h:127: error: 'class QGridLayout' has no member named 'setHorizontalSpacing' ui/PrefUi.h:128: error: 'class QGridLayout' has no member named 'setVerticalSpacing' ui/PrefUi.h:158: error: 'class QHBoxLayout' has no member named 'setLeftMargin' ui/PrefUi.h:159: error: 'class QHBoxLayout' has no member named 'setTopMargin' ui/PrefUi.h:160: error: 'class QHBoxLayout' has no member named 'setRightMargin' ui/PrefUi.h:161: error: 'class QHBoxLayout' has no member named 'setBottomMargin' ui/PrefUi.h:211: error: 'class QVBoxLayout' has no member named 'setLeftMargin' ui/PrefUi.h:212: error: 'class QVBoxLayout' has no member named 'setTopMargin' ui/PrefUi.h:213: error: 'class QVBoxLayout' has no member named 'setRightMargin' ui/PrefUi.h:214: error: 'class QVBoxLayout' has no member named 'setBottomMargin' ui/PrefUi.h:223: error: 'class QHBoxLayout' has no member named 'setLeftMargin' ui/PrefUi.h:224: error: 'class QHBoxLayout' has no member named 'setTopMargin' ui/PrefUi.h:225: error: 'class QHBoxLayout' has no member named 'setRightMargin' ui/PrefUi.h:226: error: 'class QHBoxLayout' has no member named 'setBottomMargin' ui/PrefUi.h:254: error: 'class QHBoxLayout' has no member named 'setLeftMargin' ui/PrefUi.h:255: error: 'class QHBoxLayout' has no member named 'setTopMargin' ui/PrefUi.h:256: error: 'class QHBoxLayout' has no member named 'setRightMargin' ui/PrefUi.h:257: error: 'class QHBoxLayout' has no member named 'setBottomMargin' ui/PrefUi.h:281: error: 'class QVBoxLayout' has no member named 'setLeftMargin' ui/PrefUi.h:282: error: 'class QVBoxLayout' has no member named 'setTopMargin' ui/PrefUi.h:283: error: 'class QVBoxLayout' has no member named 'setRightMargin' ui/PrefUi.h:284: error: 'class QVBoxLayout' has no member named 'setBottomMargin' make[7]: *** [Dialogs.lo] Error 1 make[7]: Leaving directory `/home/dfreeman/lyx-devel/src/frontends/qt4' make[6]: *** [all-recursive] Error 1 make[6]: Leaving directory `/home/dfreeman/lyx-devel/src/frontends/qt4' make[5]: *** [all] Error 2 make[5]: Leaving directory `/home/dfreeman/lyx-devel/src/frontends/qt4' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/dfreeman/lyx-devel/src/frontends' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/dfreeman/lyx-devel/src/frontends' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/dfreeman/lyx-devel/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/dfreeman/lyx-devel/src' make: *** [all-recursive] Error 1
Re: 1.5 branch won't compile
On Sat, 2007-11-03 at 19:27 +1100, Darren Freeman wrote: > Today's revision that failed is r21399. I went backward to find the most > recent revision which compiles, which is r21356. The change which broke > it is therefore r21357. Sorry, I'm off-by-one. The version which compiles is r21357 and the break occurred at r21358. Have fun, Darren
Re: 1.5 branch won't compile
On Sat, 2007-11-03 at 10:17 +0100, Abdelrazak Younes wrote: > Darren Freeman wrote: > > On Sat, 2007-11-03 at 19:27 +1100, Darren Freeman wrote: > >> Today's revision that failed is r21399. I went backward to find the most > >> recent revision which compiles, which is r21356. The change which broke > >> it is therefore r21357. > > > > Sorry, I'm off-by-one. The version which compiles is r21357 and the > > break occurred at r21358. > > Are you sure it's not 21368? Sorry off-by-10 :) Must have been having a bout of dyslexia... > If yes, then looks like you used Qt 4.3 Juergen... I'm using 4.2.1 (stock RPM from OpenSUSE). Have fun, Darren
Re: Lyx 1.5: formulae in wide table only appear offscreen while being edited
On Sun, 2007-10-14 at 09:39 -0700, Sarah Olsen wrote: In Gutsy's latest LyX, as well as in the more recent version 1.5.2, it is impossible to edit any math in cells of a table that extend off the screen to the right, ie a table which is wider than the screen. Sounds like a slightly more general case of this: http://bugzilla.lyx.org/show_bug.cgi?id=4190 As it hasn't been confirmed yet, could somebody please do that? Have fun, Darren
Re: Lyx 1.5: formulae in wide table only appear offscreen while being edited
On Sun, 2007-10-14 at 09:39 -0700, Sarah Olsen wrote: > In Gutsy's latest LyX, as well as in the more recent version 1.5.2, it > is impossible to edit any math in cells of a table that extend off the > screen to the right, ie a table which is wider than the screen. Sounds like a slightly more general case of this: http://bugzilla.lyx.org/show_bug.cgi?id=4190 As it hasn't been confirmed yet, could somebody please do that? Have fun, Darren
Re: Slowness Progress
On Sun, 2007-09-30 at 12:47 -0400, Richard Heck wrote: Should be easy to solve. Can you fix this, Abdel? Unfortunately, I do not have time now, as I'd really, really nice if a fix could be included in 1.5.2. I have been thinking I need to go back to using 1.4.5.1 myself, this gets so bad. I mean, a limit of six characters a second can make things really, really slow. +1 !!! Have fun, Darren PS that's assuming I have a vote in such matters :) I could offer beer...
Re: Listings settings
On Mon, 2007-10-01 at 14:47 +0100, John Levon wrote: I just came across this. Is there a bug filed on fixing this UI? I'm a bit concerned that new UI isn't getting the review it deserves. I for one am afraid to try it because I am working only on one very important document, and I hear too many reports that sound like potentially lurking data loss. Is this correct? Has 1.6svn been responsible for loss of data? Or would it be safe enough to use on something important? Have fun, Darren
Re: Slowness Progress
On Sun, 2007-09-30 at 12:47 -0400, Richard Heck wrote: > > Should be easy to solve. > Can you fix this, Abdel? Unfortunately, I do not have time now, as I'd > really, really nice if a fix could be included in 1.5.2. I have been > thinking I need to go back to using 1.4.5.1 myself, this gets so bad. I > mean, a limit of six characters a second can make things really, really > slow. +1 !!! Have fun, Darren PS that's assuming I have a vote in such matters :) I could offer beer...
Re: Listings settings
On Mon, 2007-10-01 at 14:47 +0100, John Levon wrote: > I just came across this. Is there a bug filed on fixing this UI? > I'm a bit concerned that new UI isn't getting the review it deserves. I for one am afraid to try it because I am working only on one very important document, and I hear too many reports that sound like potentially lurking data loss. Is this correct? Has 1.6svn been responsible for loss of data? Or would it be safe enough to use on something important? Have fun, Darren
Re: Bug 3700 - Graphic updates sometimes extremely slow
On Wed, 2007-09-19 at 08:36 +0200, Abdelrazak Younes wrote: Darren Freeman wrote: I don't think this is the problem but you can try to disable the 'hover' with the attached patch. I verified the bug with the original version, and then patched and compiled, tried again. I found the slowness to be much worse, and couldn't be cleared by resizing (I think some gain was had by copying from within LyX). What's worse is the un-patched (installed) version was then hideously slow and wouldn't speed up either! I don't know what was going on, even repainting the window decorations was slow. Bringing up the citation dialogue took a second or more to paint everything!! But then I recompiled the un-patched version, and it was back to usual, bug intact but workaround succeeded. Then I compiled the patched version, and it was fast. I haven't seen it exhibit the bug yet. I'm now going to test the patched version to see if the slowness comes back at all. What could be lingering after the normal closure of the slightly patched LyX? I did notice it failed to reconfigure when I ran the different version, so I guess it is only triggered by a hard-coded version number rather than a hash of the binary etc. What could could be a problem though is the automatic work area resizing when a toolbar (mathed or tabular) pops up. Do you use this feature? If yes, try to disable it and report back. I don't know this feature. If it's off by default, then I'm not using it. I haven't seen toolbars coming and going by themselves. Darren, I appreciate your reports but I am sorry to say they are not very useful at this point. The only thing we need is a profile report when you see this slowdown. Without experimenting this slowdown I cannot solve it, as simple as that. Okay I'll have to look into profiling. Any tips? Extra build options, preferred profiling tool? Have fun, Darren
Re: Compression and other assorted bits
On Wed, 2007-09-19 at 08:28 +0100, José Matos wrote: On Tuesday 18 September 2007 21:45:07 Bo Peng wrote: Remember, if you have file.lyz and file.lyx in the same directory, unpacking file.lyz will overwrite file.lyx. You also have to decide if you want to save file.lyx along with file.lyz if you edit file.lyx and then enable embedding. A single extension is easier to understand. At least to me this is a secondary argument. :-) I have been deliberately keeping out of this stuff, but I would like to point out that there was a thread back in late 2002 in which all this stuff came up. Back when use of XML was being debated, I suggested that we could use gzip for compression and then it wouldn't matter if the tags were long or short as the file size would be about the same. The use of .lyx.gz or .lyz was debated although I forget the outcome. I think .lyx.gz makes perfect sense to anybody who looks at it. They can take a stack of .lyx files they haven't needed for a while and gzip them legitimately. They can for whatever reason do the reverse. Just as long as the correct datestamp is written into the .gz so gunzip will keep the right stamp on the unpacked file (or is it better to omit this?). The filename shouldn't be written or if it was renamed, gunzip might change it back. I think in the case of unpacking, the user should be warned if an overwrite is taking place, just as for File-Save As or File-Save if it was externally modified. Have fun, Darren
Re: Bug 3700 - Graphic updates sometimes extremely slow
Hi all,
Can anybody explain why there are several repaints involved in a window
resize? (On Linux, Qt-4.2.1)
Starting from a small window, maximise it.
1. Window jumps to full size, Qt widgets are correctly drawn at new
sizes, but the document view is old size with old contents.
2. Document view resizes to new size, new contents.
3. Qt widgets such as scroll bar and bottom toolbar are redrawn. They
were grey in step 2.
Surely this sort of thing ought to be atomic in the sense that redraws
aren't allowed until all parameters are updated.
You can also see some shameful wasted repaints using View-{Open,Close}
All Insets. There is time spent without any repaints, while the insets
above the current view change state, then there is a string of insets
opening/closing in the current view, with text moving around, and
finally a delay while the insets below are changed and nothing much
happens. Again, shouldn't this sort of thing be done atomically without
any screen redraws until the final state is reached?
Have fun,
Darren
Re: Bug 3700 - Graphic updates sometimes extremely slow
(Just added the following to bugz..) Now I've seen the speed-up happen with opening the Outline. It seems to be specifically related to resizing the document view within the main window, not only resizing the whole thing. Also, resizing can result in slow-downs too. This is probably why I usually notice a slowdown straight after opening the Outline. It's probably just luck as to whether it gets faster or slower. Have fun, Darren
Re: Bug 3700 - Graphic updates sometimes extremely slow
On Wed, 2007-09-19 at 17:58 +1000, Darren Freeman wrote: I'm now going to test the patched version to see if the slowness comes back at all. Okay it came back fairly soon but I can't always clear it by resizing the window.. why, oh why? I don't know what else has changed. Can anybody blame the patch? Have fun, Darren
Re: Bug 3700 - Graphic updates sometimes extremely slow
On Wed, 2007-09-19 at 11:26 +0200, Abdelrazak Younes wrote: Darren Freeman wrote: On Wed, 2007-09-19 at 17:58 +1000, Darren Freeman wrote: I'm now going to test the patched version to see if the slowness comes back at all. Okay it came back fairly soon but I can't always clear it by resizing the window.. why, oh why? The phase of the moon. More seriously.. :) One thing that has nagged at me for a little while, is could it be swap-related? I have 3 or 4 major apps each using 1/3 of the physical memory (1 GB). What if some of the memory used by LyX gets swapped out due to disuse, and the act of resizing triggers LyX/Qt to inspect much of this and so the pages get swapped in? It could possibly explain why LyX gets slower and slower except I don't see why pages should get swapped out of an app that's being actively used. Unless something else is misbehaving. (I blame Firefox which idles at 10% CPU when no part of it is being displayed.) Also, I don't notice the usual pause and disc activity that would indicate swapping when LyX is in use. The fact that I can scroll over the same page of text again and again and see that it is too slow would hopefully rule out a swap issue. When I have zero swap in use, I'll verify the problem is still as described. Have fun, Darren
Re: Bug 3700 - Graphic updates sometimes extremely slow
On Wed, 2007-09-19 at 08:36 +0200, Abdelrazak Younes wrote: > Darren Freeman wrote: > I don't think this is the problem but you can try to disable the 'hover' > with the attached patch. I verified the bug with the original version, and then patched and compiled, tried again. I found the slowness to be much worse, and couldn't be cleared by resizing (I think some gain was had by copying from within LyX). What's worse is the un-patched (installed) version was then hideously slow and wouldn't speed up either! I don't know what was going on, even repainting the window decorations was slow. Bringing up the citation dialogue took a second or more to paint everything!! But then I recompiled the un-patched version, and it was back to usual, bug intact but workaround succeeded. Then I compiled the patched version, and it was fast. I haven't seen it exhibit the bug yet. I'm now going to test the patched version to see if the slowness comes back at all. What could be lingering after the normal closure of the slightly patched LyX? I did notice it failed to reconfigure when I ran the different version, so I guess it is only triggered by a hard-coded version number rather than a hash of the binary etc. > What could could be a problem though is the automatic work area resizing > when a toolbar (mathed or tabular) pops up. Do you use this feature? If > yes, try to disable it and report back. I don't know this feature. If it's off by default, then I'm not using it. I haven't seen toolbars coming and going by themselves. > Darren, I appreciate your reports but I am sorry to say they are not > very useful at this point. The only thing we need is a profile report > when you see this slowdown. Without experimenting this slowdown I cannot > solve it, as simple as that. Okay I'll have to look into profiling. Any tips? Extra build options, preferred profiling tool? Have fun, Darren
Re: Compression and other assorted bits
On Wed, 2007-09-19 at 08:28 +0100, José Matos wrote: > On Tuesday 18 September 2007 21:45:07 Bo Peng wrote: > > Remember, if you have file.lyz and file.lyx in the same directory, > > unpacking file.lyz will overwrite file.lyx. You also have to decide if > > you want to save file.lyx along with file.lyz if you edit file.lyx and > > then enable embedding. A single extension is easier to understand. > > At least to me this is a secondary argument. :-) I have been deliberately keeping out of this stuff, but I would like to point out that there was a thread back in late 2002 in which all this stuff came up. Back when use of XML was being debated, I suggested that we could use gzip for compression and then it wouldn't matter if the tags were long or short as the file size would be about the same. The use of .lyx.gz or .lyz was debated although I forget the outcome. I think .lyx.gz makes perfect sense to anybody who looks at it. They can take a stack of .lyx files they haven't needed for a while and gzip them legitimately. They can for whatever reason do the reverse. Just as long as the correct datestamp is written into the .gz so gunzip will keep the right stamp on the unpacked file (or is it better to omit this?). The filename shouldn't be written or if it was renamed, gunzip might change it back. I think in the case of unpacking, the user should be warned if an overwrite is taking place, just as for File->Save As or File->Save if it was externally modified. Have fun, Darren
Re: Bug 3700 - Graphic updates sometimes extremely slow
Hi all,
Can anybody explain why there are several repaints involved in a window
resize? (On Linux, Qt-4.2.1)
Starting from a small window, maximise it.
1. Window jumps to full size, Qt widgets are correctly drawn at new
sizes, but the document view is old size with old contents.
2. Document view resizes to new size, new contents.
3. Qt widgets such as scroll bar and bottom toolbar are redrawn. They
were grey in step 2.
Surely this sort of thing ought to be atomic in the sense that redraws
aren't allowed until all parameters are updated.
You can also see some shameful wasted repaints using View->{Open,Close}
All Insets. There is time spent without any repaints, while the insets
above the current view change state, then there is a string of insets
opening/closing in the current view, with text moving around, and
finally a delay while the insets below are changed and nothing much
happens. Again, shouldn't this sort of thing be done atomically without
any screen redraws until the final state is reached?
Have fun,
Darren
Re: Bug 3700 - Graphic updates sometimes extremely slow
(Just added the following to bugz..) Now I've seen the speed-up happen with opening the Outline. It seems to be specifically related to resizing the document view within the main window, not only resizing the whole thing. Also, resizing can result in slow-downs too. This is probably why I usually notice a slowdown straight after opening the Outline. It's probably just luck as to whether it gets faster or slower. Have fun, Darren
Re: Bug 3700 - Graphic updates sometimes extremely slow
On Wed, 2007-09-19 at 17:58 +1000, Darren Freeman wrote: > I'm now going to test the patched version to see if the slowness comes > back at all. Okay it came back fairly soon but I can't always clear it by resizing the window.. why, oh why? I don't know what else has changed. Can anybody blame the patch? Have fun, Darren
Re: Bug 3700 - Graphic updates sometimes extremely slow
On Wed, 2007-09-19 at 11:26 +0200, Abdelrazak Younes wrote: > Darren Freeman wrote: > > On Wed, 2007-09-19 at 17:58 +1000, Darren Freeman wrote: > >> I'm now going to test the patched version to see if the slowness comes > >> back at all. > > > > Okay it came back fairly soon but I can't always clear it by resizing > > the window.. why, oh why? > > The phase of the moon. More seriously.. :) One thing that has nagged at me for a little while, is could it be swap-related? I have 3 or 4 major apps each using >1/3 of the physical memory (1 GB). What if some of the memory used by LyX gets swapped out due to disuse, and the act of resizing triggers LyX/Qt to inspect much of this and so the pages get swapped in? It could possibly explain why LyX gets slower and slower except I don't see why pages should get swapped out of an app that's being actively used. Unless something else is misbehaving. (I blame Firefox which idles at 10% CPU when no part of it is being displayed.) Also, I don't notice the usual pause and disc activity that would indicate swapping when LyX is in use. The fact that I can scroll over the same page of text again and again and see that it is too slow would hopefully rule out a swap issue. When I have zero swap in use, I'll verify the problem is still as described. Have fun, Darren
Bug 4002 - Figure floats are variable width on screen.
Hi all, could somebody please confirm this as it was discussed on the list already. I thought a consensus was reached to fix the width of Figure floats to the display maximum. http://bugzilla.lyx.org/show_bug.cgi?id=4002 Aside from wasting time on redraws if the figure is centred/right-justified, it also makes it a little tricky to alter the paragraph settings of a figure which is wider than the caption because it's hard to get the cursor next to the figure without opening the figure properties. (Can that be fixed by giving a dead zone at the border of the figure which won't bring up the properties?) Have fun, Darren
Re: Bug 4002 - Figure floats are variable width on screen.
On Tue, 2007-09-18 at 10:32 +0200, Abdelrazak Younes wrote: Darren Freeman wrote: http://bugzilla.lyx.org/show_bug.cgi?id=4002 This is fixed in trunk already. Not easily backportable unfortunately. Can a different fix be applied to branch? Surely this is a simple change. The inset knows not to grow beyond a certain width, so can it be made to always be that width? Have fun, Darren
Bug 3700 - Graphic updates sometimes extremely slow
Hi all, I'm just musing about possible causes for the unbearable slowness that often befalls LyX and then mysteriously clears with a resize-maximise cycle. I now realise there are multiple levels of slowness and multiple cycles of the resize-maximise will restore speed in increments! With lyx -dbg gui, why do I see lines like the following every time I mouse over an inset? Such as when the purple corners appear on mathed, or when a Float goes dark to invite clicking. void lyx::BufferView::updateScrollbar() Updating scrollbar: height: 345 curr par: 294 default height 31 If this is really necessary, can it be made to check if there is actually a change to save on calls to Qt? Otherwise, when scrolling, I just see pairs of the following, unless I happen to land with the mouse on top of something which can generate the above.. void lyx::BufferView::scrollDocView(int)[ value = 196495] void lyx::BufferView::updateScrollbar() Updating scrollbar: height: 345 curr par: 294 default height 31 Is it possible the bug is related to these two? Note there were only 6 bugs files between 3694 and this slowness one... Bug 3694 - Inset highlighting remains true without mouse cursor. Bug 3900 - Mathed corners displayed without mouse hover What if there is a growing list of insets to highlight, all over the document (a single-file thesis no less), and it gets cleared on resize? Just some musings without actually lifting the hood to have a look for myself :) Have fun, Darren
Re: [Patch 1.5] Bug 4002 and 4029 - Figure floats are variable width on screen and correct Fixed size InsetBox
On Tue, 2007-09-18 at 20:32 +0200, Abdelrazak Younes wrote: Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: Ici :-) This looks good. I only had time for a very cursory test, though. If you have tested it well and feel confident with it, you can commit it. Yes I feel confident about it. Committed. So nice to suggest something, go to bed, wake up, recompile, and it's done :) Beat that, proprietary software :P Have fun, Darren
Bug 4002 - Figure floats are variable width on screen.
Hi all, could somebody please confirm this as it was discussed on the list already. I thought a consensus was reached to fix the width of Figure floats to the display maximum. http://bugzilla.lyx.org/show_bug.cgi?id=4002 Aside from wasting time on redraws if the figure is centred/right-justified, it also makes it a little tricky to alter the paragraph settings of a figure which is wider than the caption because it's hard to get the cursor next to the figure without opening the figure properties. (Can that be fixed by giving a dead zone at the border of the figure which won't bring up the properties?) Have fun, Darren
Re: Bug 4002 - Figure floats are variable width on screen.
On Tue, 2007-09-18 at 10:32 +0200, Abdelrazak Younes wrote: > Darren Freeman wrote: > > http://bugzilla.lyx.org/show_bug.cgi?id=4002 > > This is fixed in trunk already. Not easily backportable unfortunately. Can a different fix be applied to branch? Surely this is a simple change. The inset knows not to grow beyond a certain width, so can it be made to always be that width? Have fun, Darren
