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: 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: 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: 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: Error making svn 1_5_X
On Fri, 2008-01-18 at 09:38 +1100, Roger Mc Murtrie wrote: > lib/doc/Makefile.depend:21: bad characters in variable name `' Roger, this is the same problem I had. There was a svn conflict introduced because Makefile.depend is regenerated by automake but it is also in the repository (somebody tell me why this should be in the repository then, since automake is mandatory for an svn build?). There must have been one change that caused a local modification of this file, which was not committed at the time of the change, followed by another change recently in the svn repository that conflicts with the existing change. Try "svn revert lib/doc/Makefile.depend" and build it again. Don't bother with "make clean" or anything like that. 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
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: 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: 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
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
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: 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
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 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
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 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: 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: 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: 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 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
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: 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
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
[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
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
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
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.
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
[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
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: 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
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: 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: 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: 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
(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
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
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: 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
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: [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 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: 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 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: Display index name in the label of InsetIndex?
On Sun, 2007-09-16 at 09:20 +0300, Martin Vermeer wrote: > On Sat, Sep 15, 2007 at 11:36:37PM -0500, Bo Peng wrote: > > Can I make the label of InsetIndex more meaningful by displaying > > 'Idx:name' instead of 'Idx'? > > > > A simple patch is attached. I will commit it if there is no objection > > in one day. > > ... and for the closed inset, you can leave out the Idx: prefix on the > button. Curious people will click on it anyway... One of my bugz enhancement requests was that all collapsed Insets should have a mouse over text which reminds you of the contents. Such as the start of the caption or note or whatever. In which case a lot of characters can be shown because it's on top of the document rather than inline. This would eliminate clicking on a figure inset just to remember that it was a huge graphic. Have fun, Darren
Re: View Menu proposal
On Fri, 2007-09-14 at 12:36 +0200, Tommaso Cucinotta wrote: > Waiting for the process to die would only work for simple apps > like "gv". For example, the default behaviour of acroread is, > on Linux, to open a new window and wait if it is not running, > or to display the requested document into the already running > window, if it is already running, and *exit immediately*. Here's another way to keep track of open files: lsof ~/tmp/lyx_tmpdir3909cEWtW6/lyx_tmpbuf0/thesis.* COMMANDPID USER FD TYPE DEVICE SIZENODE NAME kghostvie 4428 dfreeman 13r REG9,0 107171924 3004525 /home/dfreeman/tmp/lyx_tmpdir3909cEWtW6/lyx_tmpbuf0/thesis.ps gs4838 dfreeman 13r REG9,0 107171924 3004525 /home/dfreeman/tmp/lyx_tmpdir3909cEWtW6/lyx_tmpbuf0/thesis.ps gs4839 dfreeman 13r REG9,0 107171924 3004525 /home/dfreeman/tmp/lyx_tmpdir3909cEWtW6/lyx_tmpbuf0/thesis.ps kpdf 5039 dfreeman 13r REG9,0 6475882 3004856 /home/dfreeman/tmp/lyx_tmpdir3909cEWtW6/lyx_tmpbuf0/thesis.pdf So kghostview keeps it in use, kpdf does too. But kdvi doesn't, of course :) To test for kghostview and kpdf, then, call `lsof filename` and if it returns an empty string it's not being viewed anymore. Maybe this can be one more attribute of the viewer configurations - method of checking if it is still in use. One could then use custom shell scripts for more complex tests. Have fun, Darren
Re: View Menu proposal
On Fri, 2007-09-14 at 09:29 +0200, Jean-Marc Lasgouttes wrote: > Darren Freeman <[EMAIL PROTECTED]> writes: > > > Add three radio buttons to the configuration dialogue, under "Action to > > perform when a preview is still open", which would be "Ask what to do", > > "Always update the existing preview", and "Always open a new preview". > > Ugh. Not really a simplification of the use of LyX, is it? I think it is, actually. Half as many menu entries and less key bindings. Come to think of it, how come only DVI and PS have keyboard shortcuts? Are we all supposed to bind our favourite PDF method or could there be a default one chosen for a shortcut (to aid newbies in choosing one for example)? If you closed the old preview, no change in behaviour. After the first time the dialogue appears, you either get your favourite action from now on, or you get asked each time the existing preview is open. This is very much like the UI of other popular apps. With shortcuts for the buttons on the dialogue, this is speedy from the keyboard too. (replace an extra shift modifier with a trailing Enter etc.) Perhaps there can be a statement next to the "Don't ask me again" box which lets you know the setting can be changed later in the appropriate configuration dialogue. Have fun, Darren
Re: View Menu proposal (was: Re: Master Preview)
On Fri, 2007-09-14 at 11:31 +1000, Darren Freeman wrote:
> Suggestion: A dialogue could ask whether the user wants to update the
> existing preview, thus only one menu item is required for each file
> format to preview. They need only one set of keybindings, plus two more
> for "Update existing" and "Open new preview". One of those could be the
> default so it's really "Enter" plus one more ("N" for example). Maybe a
> third option "Cancel" in case I didn't perform any edits and I forgot it
> was open on another desktop or whatever.
Further suggestion:
Add three radio buttons to the configuration dialogue, under "Action to
perform when a preview is still open", which would be "Ask what to do",
"Always update the existing preview", and "Always open a new preview".
The above suggested preview dialogue would only appear if the first
radio button is set. A (deselected) check box would be added to the
dialogue, for "Always do this", which sets one of the other radio
buttons in the configuration dialogue based on the action chosen.
(Except in the case of Cancel...)
Have fun,
Darren
Re: View Menu proposal (was: Re: Master Preview)
On Fri, 2007-09-14 at 00:57 +0200, Tommaso Cucinotta wrote:
> Also, let me propose some rework of the View menu (independently
> from the master-buffer-view being accepted or not):
I'm in favour of this change compared to the present menu.
However I'd like to make a couple of suggestions for the View/Update
functionality which is a bit clunky IMHO.
Assumption: View and Update perform equivalently when the most recent
preview was closed by the user.
Suggestion: Update should be the preferred behaviour, which is easier to
access from the menu and which the keyboard shortcuts point to. A user
who genuinely wants ten open previews will ask for it. (This could be
made a configuration option as to which is the preferred and which is
"alternate".)
Assumption: It is possible to detect whether the most recent preview is
still open. (See first assumption, I believe this is implied by that.)
Suggestion: A dialogue could ask whether the user wants to update the
existing preview, thus only one menu item is required for each file
format to preview. They need only one set of keybindings, plus two more
for "Update existing" and "Open new preview". One of those could be the
default so it's really "Enter" plus one more ("N" for example). Maybe a
third option "Cancel" in case I didn't perform any edits and I forgot it
was open on another desktop or whatever.
The above suggestions sound to my untrained self to be straightforward
to implement and big improvement in the UI. If there is support I'll
file an enhancement on bugz.
Have fun,
Darren
Re: Lyx/branch crashes during exit.
On Tue, 2007-09-11 at 22:50 -0500, Bo Peng wrote:
> #2 points to
> GuiFontLoader::~GuiFontLoader()
> {
> #if QT_VERSION >= 0x040200
> for (int i = 0 ; i < num_math_fonts; ++i) {
> if (fontID[i] >= 0)
> QFontDatabase::removeApplicationFont(fontID[i]);
> }
>
> delete [] fontID;
> #endif
> }
I should have said, using Qt 4.2.1, so this code is being compiled.
Have fun,
Darren
Re: Lyx/branch crashes during exit.
On Tue, 2007-09-11 at 22:50 -0500, Bo Peng wrote: > On linux, simply start and quit lyx. r20206 didn't do this. I just built r20235 and tried. Sorry but following your procedure I don't get a crash. OpenSUSE 10.2. Have fun, Darren
Figure scaling in LyX display
Hi all, how does LyX know how to scale an EPS figure when viewing it on-screen? It's set to 100% and on my 16cm wide figure, it's more like 12.5cm. I'm used to my 16cm-wide PNG figures requiring a 30% scaling in the LyX display to end up with something much bigger. My display is 90DPI according to my calibration in Gimp. So it could be rendering at 70DPI by default and displaying 1:1 pixel wise. Or is it the PNG which displays wrong? They were 600DPI and if the figure size matadata were being ignored, instead using 1:1 pixel scaling, it would be huge and require scaling in LyX. Have fun, Darren
Re: Fwd: [Bug 4173] Middle-button paste between apps sometimes uses old selection.
On Mon, 2007-09-10 at 17:16 +0200, Jürgen Spitzmüller wrote: > Jean-Marc Lasgouttes wrote: > > > I am not sure which of your patches has not been put to branch, could > > > you take care of this? > > > > I thought all patches were on the branch, and I am not sure what > > problems are remaining, actually. > > I'm not sure either, but I remember Darren reported that there are still > unresolved issues. Darren? There is a patch floating around which still applies cleanly. I just haven't had a chance to verify the corner cases. Please go on without me :) Make sure it's in branch. Have fun, Darren
Bugzilla error
Changes submitted for bug 4045 Software error: Insecure dependency in exec while running with -T switch at /home/bugzilla/mozilla/webtools/bugzilla/process_bug.cgi line 1267. For help, please send mail to the webmaster ([EMAIL PROTECTED]), giving this error message and the time and date of the error.
Re: Slow down and speed up after copy and paste.
On Sun, 2007-09-09 at 12:28 +0300, Martin Vermeer wrote: > On Sun, Sep 09, 2007 at 05:59:45PM +1000, Darren Freeman wrote: > > On Sat, 2007-09-08 at 22:07 +0200, Pavel Sanda wrote: > > > it seems i was able to catch another way how to reproduce the bug 4045. > > > 1. launch lyx, new doc > > > 2. launch firefox/openoffice, select text, copy text > > > 3. try to write something quickly or move with cursor, everything is > > > unbearably slow. > > > > > > anybody can confirm ? > > > > Yes. OpenSUSE 10.2, 1.5 SVN branch. > Just like the earlier slowness which was cleared by window > resize, is this cleared by paste? Or by a new copy? Or... It doesn't seem to matter which app generated the most recent selection in the clipboard, if it wasn't LyX then LyX will slow down appreciably. If there was already something in the clipboard before LyX was started, or if something is placed there during the LyX session, editing will be slow. (Mash keyboard and wait for it to catch up.) Copy something within LyX (select and Ctrl-C) and the problem is solved. This seems to be independent of the status of the X11 select and middle-click pasting. You can select what you like in any app including LyX and it won't clear the slow-down. You can middle-click paste and it won't improve things either. Have fun, Darren
Re: [PATCH] floatflt->wrapfig, now with .lyx version number increase
On Sat, 2007-09-08 at 23:39 +0200, Helge Hafting wrote: > Second iteration of the floatflt->wrapfig transition patch, > for lyx-1.6 only due to the format change. In which case maybe we can accept the words (broken) or (bugs) or (see docs) in the 1.5.x menu items? It seems to have been agreed now that it won't be fixed in 1.5. The LaTeX package would have to be fixed instead. Can we have a mechanism for bringing up a popup message with checkboxes for "Don't remind me again" and "Remind me once per session"? This would be a nice way to alert the user to errata that they need to read in the manual etc. for features that are quirky or for any reason not intuitive. I think it would be appreciated by users, without cluttering the interface. Have fun, Darren
Re: Slow down and speed up after copy and paste.
On Sat, 2007-09-08 at 22:07 +0200, Pavel Sanda wrote: > it seems i was able to catch another way how to reproduce the bug 4045. > 1. launch lyx, new doc > 2. launch firefox/openoffice, select text, copy text > 3. try to write something quickly or move with cursor, everything is > unbearably slow. > > anybody can confirm ? Yes. OpenSUSE 10.2, 1.5 SVN branch. I wouldn't have used the word "unbearably". Compared to the bug that plagues me, which is cleared on a window resize, the slowness here was quite modest :) But it was still unacceptable for a new document in any editor. If you want, add your above case to the bug and I'll confirm it. CC: me if you like as this whole business is getting to me. I can hardly bear to edit my thesis on my desktop PC. Have fun, Darren
Re: Speed up compilation [was Re: Link Error in src/client]
On Fri, 2007-09-07 at 09:25 +0100, José Matos wrote: > On Friday 07 September 2007 08:25:30 Darren Freeman wrote: > > Check out gcc's new precompiled header functionality. > > http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html > > > > Basically gcc-3.4 and newer allow you to dump the state of the compiler > > to disc after your headers are compiled, and then load it in place of > > those headers, saving you most of the compile time. > > Thanks Darren, > I use F7 and F8 (rawhide), gcc-4.1.2, to test lyx so this is not a > problem. > And as Jean-Marc said in the reply to this message that is already the > default in autotools. > > I suspect that something is wrong in the dependency handling since I > use a > builddir != srcdir. :-( Don't forget that it only uses the pre-compiled header for the first #include. To get the benefits you still have to include all the project includes from one header. Lyx isn't doing this, right? Have fun, Darren
Re: Link Error in src/client
On Thu, 2007-09-06 at 20:32 +0200, Andre Poenitz wrote: > ccache is dead easy. > > As root > > ln -s /usr/local/bin/gcc /usr/bin/ccache > ln -s /usr/local/bin/g++ /usr/bin/ccache Oh god no! You'll (try to) overwrite /usr/bin/ccache! :) Have fun, Darren PS. I do that too, sometimes :D
Speed up compilation [was Re: Link Error in src/client]
On Thu, 2007-09-06 at 18:51 +0100, José Matos wrote: > I am not reticent. I am still compiling. :-( > > That is why I like André's goal to reduce the compile time. Does anyone has > some simple step by step procedure to make ccache (or any other compiler > cache) work. It is really frustrating to almost recompile lyx everytime there > is a new update. :-( Check out gcc's new precompiled header functionality. http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html Basically gcc-3.4 and newer allow you to dump the state of the compiler to disc after your headers are compiled, and then load it in place of those headers, saving you most of the compile time. The catch is you have to include exactly the same headers in the same order with all the same options, in order for the pre-compiled image to be used. So you might create an all.h header which #includes most of the headers you expect to use, and then the first thing each .cpp does is #include "all.h". Now the compiler can grab the pre-compiled version of that and skip all the headers. Of course this means often including things you wouldn't have otherwise included, for consistency, but lets face it the reason for not including something is usually to speed up compilation in the first place. I remember Andrew Tridgell (Samba) giving us a talk on it just after another person demoed distcc, a distributed gcc. By using precompiled headers, Tridge was able to compile Samba-4 faster on one machine than distcc on multiple machines. I think that lends a lot of support to the idea of a single include which pulls in most of the other includes, and precompiling it. One can mix and match the two methods for compatibility, see the above link. Have fun, Darren
Re: Link Error in src/client
On Thu, 2007-09-06 at 18:23 +0200, Enrico Forestieri wrote: > On Fri, Sep 07, 2007 at 12:28:45AM +1000, Darren Freeman wrote: > > > I have been getting away with "patch > filenames manually. However in that one case, it decided to use the > > Makefile.am in a higher directory than the one it should have, hence not > > finding the section to modify. > > That's error prone. You have to look at the paths in the patch file > and count how many path elements must be elided (number of slashes /) > such that the file can be accessed from your current dir. Then, you > should specify this number using the -p option. Most patches you > find on this list should be applied using -p0, so the command should be > > patch -p0 < file.diff Hmmm... how embarrassment. I forgot that -p0 makes things work properly. It's annoying that it doesn't behave this way by default. I thought the resulting troubles were because the patch came from svn, but alas it works fine with the above. Reverted and reapplied the patch. Probably missed client/Makefile.am the first time around because now it's compiled OK :) Sorry to worry you like that. Have fun, Darren
Re: Link Error in src/client
On Thu, 2007-09-06 at 15:08 +0200, Enrico Forestieri wrote: > On Thu, Sep 06, 2007 at 09:40:15PM +1000, Darren Freeman wrote: > > > On Thu, 2007-09-06 at 04:45 +0200, Enrico Forestieri wrote: > > > Please, try the attached patch. > > > > BTW I am using autoconf-2.60-21 and automake-1.9.6-35. > > > > The attachment shows the rejected change from your patch, because the > > relevant target wasn't there to patch. > > If you don't have src/client/Makefile.am, then your tree is messed up. Sorry, it was the way I was applying the patch. I have been getting away with "patch
Re: Link Error in src/client
On Thu, 2007-09-06 at 04:45 +0200, Enrico Forestieri wrote: > Please, try the attached patch. BTW I am using autoconf-2.60-21 and automake-1.9.6-35. The attachment shows the rejected change from your patch, because the relevant target wasn't there to patch. Still failed with the same problem. Have fun, Darren Makefile.am.rej Description: application/reject
Re: Dapper install mostly unusable...What's wrong?
On Thu, 2007-09-06 at 11:49 +0200, Helge Hafting wrote: > Darren Freeman wrote: > > I personally think that LyX should include a warning about each and > > every feature that doesn't work reliably for whatever reason, including > > buggy software which LyX relies on. > > > Good idea - consider filing a bug report at bugzilla.lyx.org > about this. Text wrap is broken, and I don't think it'll be > fixed anytime soon either. http://bugzilla.lyx.org/show_bug.cgi?id=4208 Consider adding HTML export which is an interesting experience at times. Have fun, Darren
File revert dialogue text minor edit
Hi all, the following dialogue has an extra unwanted carriage return in the text. Also, what's with the weird filename? Why all the dots out front? It was invoked as "lyx thesis.lyx &". "Any changes will be lost. Are you sure you want to revert to the saved version" "of the document .../thesis/thesis.lyx?" Have fun, Darren
Re: Bugzilla server error
On Wed, 2007-09-05 at 14:27 +0200, Hans Meine wrote: > Am Mittwoch, 05. September 2007 14:22:35 schrieb Darren Freeman: > > On Wed, 2007-09-05 at 14:18 +0200, Jean-Marc Lasgouttes wrote: > > > I am taker for any hints. > > > > Here is a quick and lazy solution to get things going again: > > > > mv /var/foo /home/foo > > ln -s /home/foo /var > > Uuh, first use "lsof" to check that no files (e.g. logfiles) below /var/foo > are still opened by a running process (e.g. syslog daemon). That'd make for > ugly surprises... ;-/ Hmm.. I guess common sense is required :) /var/lib would be pretty safe, no? Using cp -a followed by ln -s followed by "mv && mv" to pretend to atomically replace the dir with the link. Then check if anybody is still reading anything from that dir before finally removing it. Have fun, Darren
Re: Bugzilla server error
On Wed, 2007-09-05 at 14:18 +0200, Jean-Marc Lasgouttes wrote: > I am taker for any hints. Here is a quick and lazy solution to get things going again: mv /var/foo /home/foo ln -s /home/foo /var Have fun, Darren
Bugzilla server error
I was entering an enhancement request a few min ago. Will redo and see if it works. 8<8<8<8< Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [EMAIL PROTECTED] and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. Apache/2.0.54 (Fedora) Server at bugzilla.lyx.org Port 80
Re: Dapper install mostly unusable...What's wrong?
On Wed, 2007-09-05 at 13:17 +0200, Helge Hafting wrote: > get that to work. If you don't like to experiment, don't > use the text wrap float. Perhaps LyX should include > a warning about how broken this particular feature is. I personally think that LyX should include a warning about each and every feature that doesn't work reliably for whatever reason, including buggy software which LyX relies on. I was a new user once, and let me tell you the learning curve would be less steep if I knew which things were meant for more experienced gurus or which weren't working properly due to dodgy external software. Maybe there should be an option for setting the interface to Beginner/Experienced/Advanced.. and such things as the minibuffer and View->DVI would appear by default when setting the appropriate level. Maybe the levels can be defined by the contents of the different manuals. x I have read the Tutorial x I have read the Users Guide o I have read the Extended Features Guide => You have attained the level of Experienced. You will be promoted again after slaying the Evil Red Toad. Maybe we can upgrade the user based on how far they get with an inbuilt multiple choices quiz :) Have fun, Darren
Re: Link Error in src/client
On Tue, 2007-09-04 at 18:44 -0400, Richard Heck wrote: > On Linux. It links fine in src/ itself. Hi all, I just updated to the latest SVN, r20063, of the 1.5 branch and hit make (Linux). Only change was to os_unix.cpp . It was clearly running the config script again as it did a lot of checks before compiling. Unfortunately it failed on linking to the new font config stuff. So this problem applies to branch as well. I just did a "make clean" and will try building again. If I get any different I'll let you know, but assume otherwise. Have fun, Darren 8<8<8<8<8<8<8<--- g++ -g -O -o lyxclient boost.o client.o debug.o gettext.o Messages.o ../../src/support/.libs/libsupport.a -L/usr/src/packages/BUILD/qt-x11-opensource-src-4.2.1/lib /usr/lib/libQtCore.so -L/usr/lib -lpthread ../../boost/libs/regex/src/.libs/libboost_regex.a ../../boost/libs/filesystem/src/.libs/libboost_filesystem.a /usr/lib/libaspell.so /usr/lib/libSM.so -lICE -lm -lz /usr/lib/libX11.so /usr/lib/libXau.so /usr/lib/libXdmcp.so -ldl ../../src/support/.libs/libsupport.a(os.o): In function `lyx::support::os::restoreFontResources()': /home/dfreeman/lyx-devel/src/support/os_unix.cpp:245: undefined reference to `FcConfigAppFontClear' ../../src/support/.libs/libsupport.a(os.o): In function `lyx::support::os::addFontResources()': /home/dfreeman/lyx-devel/src/support/os_unix.cpp:236: undefined reference to `FcConfigAppFontAddDir' collect2: ld returned 1 exit status make[4]: *** [lyxclient] Error 1 make[4]: Leaving directory `/home/dfreeman/lyx-devel/src/client' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/dfreeman/lyx-devel/src/client' 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: Lyx problems in importing txt2tags .tex files
On Wed, 2007-09-05 at 11:18 +0200, Jean-Marc Lasgouttes wrote: > José Matos <[EMAIL PROTECTED]> writes: > > > As I have told you (I think) I saw a latex class where it was necessary to > > include the title elements in the preamble as there was not any \maketitle > > element. The crazy things that people do with latex is amazing. :-) > > Yes, I know that. I think we need a new tag 'ToPreamble' to layout > files. I jumped in at the end of the thread so sorry if this sounds stupid or irrelevant :) I don't know how layout files work either so I'm at risk of both. Please consider the elsart class which has serious trouble with multiple authors, which require their own \author field plus arguments. You basically have to resort to ERT to make it work. See the thread started by me on 25 Jul, "Elsart class complex frontmatter". One problem is you want the author field to be in frontmatter, but as soon as you put an ERT on its own in a standard environment, you end the frontmatter and prevent it and everything after it from appearing in the output. So the mechanism which decides when to begin and end frontmatter could use improvement, perhaps in the way you are describing the 'ToPreamble' tag as 'ToFrontmatter'. Could there be a "frontmatter" option for ERT insets? Have fun, Darren
Re: LyX CVS/SVN diff support.
On Mon, 2007-09-03 at 12:34 +0100, José Matos wrote: > On Monday 03 September 2007 12:25:53 Darren Freeman wrote: > > But I can't see it happening anytime soon or ever.. > > Just curious, why? Wouldn't it be a huge amount of work? Okay I retract that. I can't see it happening soon :) It would be ultra-cool though. Even so far as to draw those sexy splines in the middle joining the changed sections. Have fun, Darren
Re: LyX CVS/SVN diff support.
On Mon, 2007-09-03 at 12:12 +0200, Tommaso Cucinotta wrote: > diff of .lyx files. Something that shows a double-work area > window with my local version on the left and the remote > committed version on the right, highlighting in both work-areas > the changes between the two (this might be done [ graphically ] > in a way that is very similar to change tracking, I guess). If you haven't used it, give "kompare" a go. For regular text files, it's fantastic! Although this isn't the nicest solution, it gets you partway there. If you can read raw LyX you can see your changes in a reasonable manner. If LyX could do the very same thing, well that would be damn cool :) But I can't see it happening anytime soon or ever.. Have fun, Darren
RE: Minus and plus font issue?
On Fri, 2007-08-31 at 15:19 +0200, Leuven, E. wrote: > thanks for reminding people why they are not using linux anymore ... At least most Linux distros come with LyX ready to go. I solved the problem in this way. I asked YaST to install the version of LyX that comes with SuSE 10.2, and it asked to install free-ttf-fonts, which is a dependency. So I cancelled and just installed the fonts. Problem solved. I mustn't have installed the bundled version of LyX because I knew I would be compiling it myself. Otherwise this wouldn't have been an issue. There is still the outstanding problem of getting the as-compiled LyX to install fonts on SuSE, and I'll let the developers nut out why and how to fix. I think a bug like this isn't reason enough to bash an operating system. Most people will install a pre-compiled package anyway and the fonts will go in automatically. Thanks to Enrico for taking the time to point out where I was going wrong. Have fun, Darren
Minus and plus font issue?
Hi all, I'm used to having certain symbols not display in mathed, instead showing with red text for the TeX name of the symbol. I live with that and it's probably the fault of OpenSuSE 10.2 which I am using. However I just found that \pm displays correctly while \mp shows up as red text. Is this the case for other people or is it still a font issue at my end? Have fun, Darren
Re: Middle-click copy-paste borked in SVN
On Mon, 2007-08-27 at 10:08 +0200, Jürgen Spitzmüller wrote: > Darren Freeman wrote: > > There is a simple patch under test. > > Could you create a bugzilla entry and upload the patch there, please? http://bugzilla.lyx.org/show_bug.cgi?id=4173 Have fun, Darren
Re: Middle-click copy-paste borked in SVN
On Mon, 2007-08-27 at 08:28 +0200, Jürgen Spitzmüller wrote: > Bo Peng wrote: > > A 'better' fix has been committed, but there is still a problem of > > copy/paste table cells. > > Do we have a bugzilla entry? Sorry for asking, I'm still trying to catch > up ... I started the thread, but due to proximity to the 1.5 release I expected it to be on everybody's mind and fixed within a couple of days :) So no, not to my knowledge. There is a simple patch under test. Have fun, Darren
Re: Figure scaling: ugly, inefficient
On Thu, 2007-08-23 at 16:24 +0100, José Matos wrote: > On Wednesday 15 August 2007 11:05:11 Darren Freeman wrote: > > If nobody else puts their hand up, I might work on this some day, but > > currently I have other obligations :) I have a background in image > > processing and I would certainly offer advice to whoever works on it. > > It seems Darren that you the only one sufficiently annoyed by this > "feature" > to do something about it. :-) Bugger :) If anyone wants me, I'll be in my room! Have fun, Darren
Re: Slow down and speed up after copy and paste.
On Tue, 2007-08-21 at 17:21 -0500, Bo Peng wrote: > > i could not find it in bugz and the reason is, that it is uncorfimed. > > http://bugzilla.lyx.org/show_bug.cgi?id=4045 > > So I confirmed it. Mine too, please, if you try window resizing. If that works, the two are dupes. Have fun, Darren
Re: Slow down and speed up after copy and paste.
On Tue, 2007-08-21 at 18:34 +0200, Abdelrazak Younes wrote: > Bo Peng wrote: > > Just to report, as far as I remember, a known problem. > > I believe there's a bugzilla item from Darren Freeman. He was the only > one with these symptoms AFAIK, up until now. http://bugzilla.lyx.org/show_bug.cgi?id=3700 > > become very slow. However, if I > > select, copy and paste, lyx will speed up a lot. > > Does window resizing help the same? Ditto. Either I haven't seen this for a while or I've forgotten to resize to clear it. I just got used to it being [EMAIL PROTECTED] slow. It does still get worse with amount of editing. Maybe it's an undo problem? Also it's worse in large paragraphs than small ones. (Worked out by hitting enter in a big paragraph so the two halves contain the same stuff.) As far as my LyX experience goes, I would mark this problem as critical. Nobody would ever use it, but unfortunately I'm a junkie now. But most people seem not to have this issue so I'll suffer on in silence :) Have fun, Darren
Re: middle-button paste no longer works properly
On Mon, 2007-08-20 at 08:54 -0500, Bo Peng wrote: > > Can I revert this patch shortly? I like my working dir to be in sync > > with the repository. Is it possible this needs to be propagated from > > trunk to 1.5 branch? > > Is this in trunk or branch? If things work OK after you revert, I have > my OK. (Make sure to test middle paste within and between table and > formula as well). I'm currently using the 1.5 branch with your patch. I don't think I've done a lot of middle-click pasting with tables and formulae so I should check first. I'm grappling with the incredible slowness problem mainly so I don't tend to notice the bugs anymore as I'm barely getting any work done. Have fun, Darren
1.5 branch wouldn't start
Hi all, yesterday I updated my 1.5 branch to r19653, compiled and installed. The only changes I could see during the update were to .po files. However I didn't restart LyX that day. Now this morning I was unable to start LyX, in the sense that nothing happened when I ran the executable. Updating to r19676, compiling and installing, seems to have fixed it. If you recall, I had similar behaviour a few months back but couldn't investigate as I installed a newer OS and it didn't have the same problem. Have fun, Darren
Re: middle-button paste no longer works properly
On Thu, 2007-07-26 at 23:04 -0500, Bo Peng wrote: > On 7/26/07, Bo Peng <[EMAIL PROTECTED]> wrote: > > > Going the other way is even worse - mark something in > > > LyX 1.5.0 (released) and you (usually) can't paste it into thunderbird. > > Could you please test the attached patch? > > JMarc and I tried to move numerous haveSelection calls to some > 'source' locations, and we obviously missed some cases. I have been testing in the 1.5.x-svn for a while and whilst I haven't checked if it is a complete fix, I haven't had any new problems either. Can I revert this patch shortly? I like my working dir to be in sync with the repository. Is it possible this needs to be propagated from trunk to 1.5 branch? Have fun, Darren Index: src/insets/InsetTabular.cpp === --- src/insets/InsetTabular.cpp (revision 19221) +++ src/insets/InsetTabular.cpp (working copy) @@ -3490,6 +3490,7 @@ cell(cur.idx())->dispatch(cur, cmd); break; } + theSelection().haveSelection(bvcur.selection()); } Index: src/Text3.cpp === --- src/Text3.cpp (revision 19221) +++ src/Text3.cpp (working copy) @@ -1586,6 +1586,7 @@ } needsUpdate |= (cur.pos() != cur.lastpos()) && cur.selection(); + theSelection().haveSelection(bv->cursor().selection()); // FIXME: The cursor flag is reset two lines below // so we need to check here if some of the LFUN did touch that.
Justified section headings?
Hi all, I just typed a Section heading until it reached the width of the line, where it then wrapped to the next line as you would expect. What I wasn't expecting is that the display on-screen is fully justified, and that looks downright ugly in my particular case as the spacing is now huge. Yes, a small number of big words in a big bold font looks ugly fully justified! Is this really necessary for an Environment which isn't normally that long anyway? It would have been one line if the Outline were hidden. Have fun, Darren
Figure scaling: ugly, inefficient
Hi all, I observed this with 1.5.2svn. Scaling on screen by a "nice" number like 50% or 25% gives better scrolling performance versus other factors. I think in any case the scaled image should be computed once and cached or at least held in a buffer for scrolling. No decimal point is allowed in the Qt4 dialogue box, so I can't enter 12.5%. Based on the above, that's the number I wanted :) In general, on-screen scaling in LyX is still pretty ugly compared to most software. In LyX it seems to scale down (decimate) by grabbing every Nth pixel, so you get horrible aliasing, especially with narrow line art where lines will be broken or disappear altogether. What would look much better is low-pass filtering prior to decimation, which would eliminate the above aliasing problems. If nobody else puts their hand up, I might work on this some day, but currently I have other obligations :) I have a background in image processing and I would certainly offer advice to whoever works on it. Have fun, Darren
Re: [PATCH 4114] Enable File -> Revert if buffer is clean but the file is externally modified.
On Tue, 2007-08-07 at 21:51 -0500, Bo Peng wrote: > I filed this bug because I would like to have a better way to reload > externally modified .lyx file. Currently, one has to close and reopen > the file, or make the buffer dirty to use File->revert. Sorry dude but I beat you to it :) http://bugzilla.lyx.org/show_bug.cgi?id=3766 Please do the honours :P Have fun, Darren
Edit->Math->Toggle Numbering
Does the above menu item work? I've never used equation numbering but a friend asked me to demonstrate it. I followed the user guide and.. nothing happened. 1.5.x branch Have fun, Darren
Re: Compress file corrupted
On Thu, 2007-08-02 at 16:05 +0200, Jean-Marc Lasgouttes wrote: > Bennett Helm <[EMAIL PROTECTED]> writes: > > >> Looks like gzstream.* did not get compiled and/or linked. Does running > >> 'make clean && make ' in src/support improve the situation? > > > > Nope -- same problem. > > Did the makefile get recreated automatically? (it did for me) > > Does running ./autogen.sh help? > > This is the 1.5 branch, right? I'm on the 1.5 branch and it built fine under Linux without reconfiguring or anything. Have fun, Darren
Re: Licence
On Fri, 2007-08-03 at 10:24 +0200, Jean-Marc Lasgouttes wrote: > Darren Freeman <[EMAIL PROTECTED]> writes: > > I hereby grant permission to licence my contributions to LyX under the > > GNU General Public Licence, version 2 or later. > > Thanks Darren. > > What e-,ail address do you want to use for the entry? [EMAIL PROTECTED] thanks! Have fun, Darren
Licence
I hereby grant permission to licence my contributions to LyX under the GNU General Public Licence, version 2 or later. Darren Freeman
Re: 1.5.0 "slowness"
On Tue, 2007-07-31 at 00:00 +0300, Martin Vermeer wrote: > ...and more importantly, you just confirmed my diagnosis of > the problem. There is something in qt, or LyX's use of qt, > that responds very badly to DRI both being turned on and > practically unusable. Could all who are interested in this bug/thread please consider the following "bug" which I think is related to why LyX is much slower on figure floats: http://bugzilla.lyx.org/show_bug.cgi?id=4002 "The figure float box is roughly the full width of the window, but in fact it is changing a small amount with every keypress. This causes the figures to move because they are in a centred paragraph." I'm not keeping up with what X with and without DRI are doing. With DRI, perhaps it's supposed to locally blit from one place to another. However, who knows how good or bad the s/w implementation is, it might have been faster to send it again from the source buffer. Could the 16/24 bit issue be related to a format conversion between LyX/Qt4 and the X display, which is skipped in one case but not the other? Have fun, Darren
Re: 1.5.0 "slowness"
On Tue, 2007-07-31 at 18:12 +0200, Andre Poenitz wrote: > On Tue, Jul 31, 2007 at 03:34:53PM +1000, Darren Freeman wrote: > > On Mon, 2007-07-30 at 22:41 -0600, Bob Lounsbury wrote: > > > That's strange. I have an Athlon XP 2000+ with 1GB of RAM, and I have > > > not noticed any slowness at all. I wonder if it has anything to do > > > with the graphics card. This computer has an ATI 9800 graphics card, > > > which is a very nice card. With my iBook I had a lot of slowness until > > > > I have a Radeon 9200SE. > > > > It is certainly using DRI at 24bpp. > > > > I can't test the X settings hypothesis right now as I have a lot of > > unsaved work open. Sounds likely though! > > You can start new X servers on display :1, :2 etc... Hadn't thought of that :) It's trivial on OpenSUSE 10.2 or Mandrake 10.x.. I tried that and couldn't find a clear improvement with DRI off and 16 bit. It would be better to try this on a single server though in case there is some interaction with the already running KDE or Qt. Have fun, Darren
