Re: Qt: was Slow scrolling
On Jan 4, 2012, at 11:36 PM, Stephan Witt wrote: > Am 05.01.2012 um 05:16 schrieb Jerry: > >> Do the developers monitor this list? > > I think so. > >> Or does someone need to file a bug report for the slow scrolling problem? > > Perhaps. But ATM there is no problem description to reproduce it, AFAICS. > Some users have a problem only on Lion - you have it on Snow Leopard (SL) too. > I see no problem here on my system (SL) - perhaps I have lower requirements. > > Stephan BTW, thanks for your help. I gather that you're the person who builds the Mac binaries. Jerry
Re: Qt: was Slow scrolling
Am 05.01.2012 um 05:16 schrieb Jerry: > Do the developers monitor this list? I think so. > Or does someone need to file a bug report for the slow scrolling problem? Perhaps. But ATM there is no problem description to reproduce it, AFAICS. Some users have a problem only on Lion - you have it on Snow Leopard (SL) too. I see no problem here on my system (SL) - perhaps I have lower requirements. Stephan
Re: Qt: was Slow scrolling
Am 05.01.2012 um 02:40 schrieb André Pönitz: > On Wed, Jan 04, 2012 at 05:19:02PM -0500, Steve Litt wrote: >> On Tuesday, January 03, 2012 03:36:16 PM Stephan Witt wrote: >>> Am 03.01.2012 um 17:15 schrieb Olivier Ripoll: >> Hi, Check my 2 messages in the "LyX 2.0.2 Released" thread, one dated december 5th (user mailing lists, perhaps devel too) and the other one dated december 16th (devel ML), which contains more details: http://www.mail-archive.com/lyx-users@lists.lyx.org/msg90218.html http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg172462.htm l >>> >>> Hi, >>> >>> I'm almost sure it depends on Qt-Version. >>> >>> With LyX on Mac with Qt4 we have two fundamental problems: >> >> At the risk of sounding like a broken record, if Qt continues to >> produce these types of problems, isn't there different library or >> combination of libraries the developers can use? > > At the risk of sounding like a broken record: Some of the issues in the > past have been caused by wrong usage within LyX (like repaint() instead > of update()), and some by insisting to use Qt versions that have been > released before the other components in the system, like newer versions > of MacOSX. I just run svn up and README says "The Qt4 library, at least > version 4.2.2. For all features newer versions (e.g. Qt 4.6) are > recommended." _Please_? That was state of the art in _2006_? > > That is not to say that Qt is flawless, Enrico(?)'s execvp/exeve > issue for instance. But the thing _is_ open source, too, so if it's > a pain point, fix it. I second that. At the time of the move to Qt-exclusive it was debatable. Now this isn't possible anymore. And Qt is an excellent toolkit. > >> Back when I wrote my "why oh why did you dump xforms" rant, it seemed >> like maybe the compile problems were just growing pains from Qt going >> from version 3 to version 4. But now it's years later, and we're still >> hearing (I paraphrase) "the quality of your LyX program depends on >> your Qt version." >> >> I know, you've told me before, Qt does a lot of busywork and makes >> programming LyX much simpler. It handles all the localization, etc. >> Programming LyX without Qt would be a horrendeous chore. >> >> But is Qt really doing you a favor when certain Qt versions make your >> program perform badly? > > *gosh* > > The main performance problems I have seen so far are due to an abuse of > the toolkit, not caused _by_ the toolkit (except for the remote raster > painter problem perhaps). Just start at RowPainter::paintChars() and > walk down through all the mess _before_ it actually hits Qt's drawText() > It is slow? You bet. Note, I've said: "we have (aka LyX code has) a problem". This isn't easy to change - and we all do it in our spare time. Everything around is a moving target - the OS and the Qt library. And it isn't possible for every move to avoid drawbacks for the late comer. For the painting problems: it started with broken ligature drawing and the (re)action of LyX coders was a hack (split the text drawing at the letter 'f'). As support for kerning for on-screen drawing was added (Qt 4.7 AFAIK) the consequence was to split at every character. Obviously a rework of the painter/cursor movement code is a much better action... but someone (who gets no money for this) has to do the job. I had a look into this and decided I cannot afford that. I have a real live too. All in all André is right: it's not the toolkit Qt, it's the use of it. Stephan
Qt: was Slow scrolling
Do the developers monitor this list? Or does someone need to file a bug report for the slow scrolling problem? Jerry
Re: Slow scrolling
On Jan 4, 2012, at 3:03 PM, Stephan Witt wrote: > I've prepared a LyX-package with Qt-4.8.0 and the upload is here: > > http://dl.dropbox.com/u/27842660/LyX-2.1.0svn%2Bqt4.8.0-cocoa.dmg > http://dl.dropbox.com/u/27842660/LyX-2.1.0svn%2Bqt4.8.0-cocoa.dmg.sig > > The Qt 4.8.0 ChangeLog contains this: > > Qt for Mac OS X > --- > - Alien widgets is now used by default for Qt/Cocoa on Mac OS X. > - Qt/Cocoa on Mac OS X has now full support for the raster paint engine. > - QApplication has now implemented macEventFilter for Qt/Cocoa > - HarfBuzz can now be used as an optional text layout engine on Mac OS X. > [QTBUG-17728] > - Qt shows some love to OS X Lion (10.7). > > Perhaps this is an improvement on Lion? Please, can someone give it a try? > > Stephan 10.6.8, 2.1svn Scrolling User's Guide takes 13 seconds. No misplaced cursor. This scroll rate is between what I measured for 2.0.0 and 2.0.2 using the special preference file line. Subjectively, for me, the somewhat slower difference for 2.1svn puts the experience back into "painful" regime, but it is still better than 2.0.2 without the special preference file line. Jerry
Re: Qt: was Slow scrolling
On Wed, Jan 04, 2012 at 05:19:02PM -0500, Steve Litt wrote: > On Tuesday, January 03, 2012 03:36:16 PM Stephan Witt wrote: > > Am 03.01.2012 um 17:15 schrieb Olivier Ripoll: > > > > Hi, > > > > > > Check my 2 messages in the "LyX 2.0.2 Released" thread, one dated > > > december 5th (user mailing lists, perhaps devel too) and the > > > other one dated december 16th (devel ML), which contains more > > > details: > > > > > > http://www.mail-archive.com/lyx-users@lists.lyx.org/msg90218.html > > > http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg172462.htm > > > l > > > > Hi, > > > > I'm almost sure it depends on Qt-Version. > > > > With LyX on Mac with Qt4 we have two fundamental problems: > > At the risk of sounding like a broken record, if Qt continues to > produce these types of problems, isn't there different library or > combination of libraries the developers can use? At the risk of sounding like a broken record: Some of the issues in the past have been caused by wrong usage within LyX (like repaint() instead of update()), and some by insisting to use Qt versions that have been released before the other components in the system, like newer versions of MacOSX. I just run svn up and README says "The Qt4 library, at least version 4.2.2. For all features newer versions (e.g. Qt 4.6) are recommended." _Please_? That was state of the art in _2006_? That is not to say that Qt is flawless, Enrico(?)'s execvp/exeve issue for instance. But the thing _is_ open source, too, so if it's a pain point, fix it. > Back when I wrote my "why oh why did you dump xforms" rant, it seemed > like maybe the compile problems were just growing pains from Qt going > from version 3 to version 4. But now it's years later, and we're still > hearing (I paraphrase) "the quality of your LyX program depends on > your Qt version." > > I know, you've told me before, Qt does a lot of busywork and makes > programming LyX much simpler. It handles all the localization, etc. > Programming LyX without Qt would be a horrendeous chore. > > But is Qt really doing you a favor when certain Qt versions make your > program perform badly? *gosh* The main performance problems I have seesn so far are due to an abuse of the toolkit, not caused _by_ the toolkit (except for the remote raster painter problem perhaps). Just start at RowPainter::paintChars() and walk down through all the mess _before_ it actually hits Qt's drawText() It is slow? You bet. > The LyX developers work so hard to create a > robust, high productivity program, only to have a tool vendor snatch > defeat from the jaws of victory. Isn't there another localization > library you can use, and another GUI library, and whatever? Which one do you think would do the trick for Window, Mac _and_ Linux? > Thanks Please backport LyX to xforms. There was even a new release 1.0.93 in May 2010. If you have done it, and it loads the UserGuide I'll shut up for eternity on that topic. Andre'
Re: Slow scrolling
On Jan 4, 2012, at 10:14 AM, Murat Yildizoglu wrote: > Ok, this was exactly what I have done on my system (10.7.2, see my previous > mail for full configuration). > > If I use the scroll bars on the left, I can go to the end of the User guide > immediately (2 seconds, since I have some difficulty to click on the iPhone's > chronometer with the left hand, and start to scroll in Lyx with the right > hand). > I do not see any lag at all. > But you don't see _many_ skipped screenfuls, right? In order to get from top to bottom of the UG so fast and _appear_ to be scrolling fast, it skips _many_ screenfuls. This is because text rendering is so slow (or not buffered) that it skips many screenfuls and gives the appearance that it has scrolled rapidly. Try scrolling on any native program such as TextEdit or Preview and you will see vastly more useful scrolling. Jerry
biblatex options in the preamble
Hello: The biblatex users guide (Version 1.7, November 13, 2011) on page 44, section 3.1.2.1 says: "The following options may be used in the optional argument to \usepackage as well as in the configuration file and the document preamble." How can I set an option in the preamble? What would be the exact code for example for the option maxbibnames=10 if I don't want to put it as an "optional argument to \usepackage"? Thanks, bcsikos
Re: Slow scrolling
On Jan 4, 2012, at 2:53 AM, Stephan Witt wrote: >> >> With 2.0.1, there is no cursor placement error. >> >> Oddly, it no longer matters if the line >> \force_paint_single_char false >> is in the Preferences file--the behavior is now the same (faster scrolling, >> misplaced cursor) with or without that line. > > That's correct. The default for this (internal) preference depends on the > Qt-Version. > > Currently I'm looking for the optimal solution... including trying out the > Qt-4.8.0 library... > > Stephan I think that this was a bogus statement by me. I later noticed that the line "\force_paint_single_char false" had accidentally been inserted into the preferences file in a place that I had not noticed, so when I thought I had deleted it or commented it out, the spurious entry was still in the file. My tests done later showed that its presence or absence had a factor of 2 on scrolling speed in 2.0.2. (See detailed post of scroll tests by me.) Jerry
Re: Slow scrolling
On Jan 4, 2012, at 4:44 AM, Stephan Witt wrote: > > And this is the result: > I've opened the users guide and started to page down unto the end once. > > * 2.0.0, 4.6.3 Carbon, 22 Sekunden > * 2.0.0, 4.6.3 Cocoa, 23 Sekunden > * 2.0.2, 4.7.2 Cocoa, 20 Sekunden > * 2.1svn, 4.8.0 Cocoa, 23 Sekunden > * 2.1svn, 4.8.0 Carbon, 23 Sekunden > * 2.1svn, 4.6.3 Carbon, 22 Sekunden > > All tests I've made with \force_paint_single_char true and false. > No real difference. > > You can see it yourself - there is no performance gain or loss on my system > (Macbook Pro OS X 10.6.8). > > Jerry, may I ask you to provide some numbers for your use case and for the > users guide? > > Stephan All tests conducted on a MacBook Pro running 10.6.8, with the LyX window taking half of the width and the entire height of the screen. Toolbars displayed are Standard, View/Update, and Extra. Scrolling was done by clicking and holding in the elevator(?) area of the scrolling control area, not on the scroll arrows. Scrolling results by Function-downarrow or Function-arrow are the same. All LyX were binaries downloaded from lyx.org as of today. As I noted in an earlier post to this thread, my attempt to compile 2.1 from SVN failed. Under Energy Saver Preferences, the Graphics hardware choice was set to "Better battery life." Preference line "\force_paint_single_char false" out 2.0.2 No cursor misplacement Scroll User's Guide: 20 seconds 2.0.1 No cursor misplacement Scroll User's Guide: 10 seconds 2.0.0 No cursor misplacement Scroll User's Guide: 10 seconds Preference line "\force_paint_single_char false" in 2.0.2 Cursor misplaced Scroll User's Guide: 10 seconds 2.0.1 No cursor misplacement Scroll User's Guide: 10 seconds 2.0.0 No cursor misplacement Scroll User's Guide: 10 seconds In all cases where I have indicated UG scrolling in 10 seconds, subsequent scrollings of the User's Guide were about 10% faster, presumably because of certain objects already being rendered on the first scrolling. However, in the 20-second UG case, I did not notice any such speed-up. If the 20-second UG case sounds OK, it isn't—scrolling under thoses conditions, whether in UG or a short document, are still excruciatingly slow especially in text-heavy parts. (It gets noticeably better in areas of less text.) In 2.0.2 with the preference line out (the mode related to my complaint), under situations of even moderately vigorous two-finger-swipe trackpad scrolling, large pieces are skipped in order to make the scrolling happen in a "reasonable" time. This makes trying to spot a feature as it speeds by useless, as the feature that you are looking for might not be displayed at all. On a small file that prints out to a little over two (rather dense—IEEEtrans) pages, it is not hard to make the screen jump from the beginning to the end without an intervening screenful. (The window width set to 1/2 the screen width, requiring 3-4 screenfuls to display with normal clicking in the elevator bar.) Even in the best cases above, scrolling is still laggy relative to native applications (but not so bad as to be useless). There is a small but noticeable lag from the time two-finger scrolling is initiated and when the screen content moves, and another lag between when scrolling is stopped and when the content stops moving. Also, try two-finger-scrolling on the trackpad in small rapid back-and-forth movements and watch as the screen updates in nearly 180 degree opposition to your finger movements, then repeat with e.g. TextEdit or Preview or Skim and notice how the content movement matches your finger movement. However, I don't want to make that a standard that LyX should meet; the behavior under the "10-second" cases above is good enough to be useful. Jerry
Re: biblatex options in the preamble
Csikos Bela írta:
>Hello:>
>
The biblatex users guide (Version 1.7, November 13, 2011)>
on page 44, section 3.1.2.1 says:>
>
"The following options may be used in the optional argument to \usepackage as
well as in the configuration file and the document preamble.">
>
How can I set an option in the preamble? What would be the exact code for
example for the option maxbibnames=10 if I don't want to put it as an "optional
argument to \usepackage"?>
I found the answer on p. 61, section 3.2.2:
\ExecuteBibliographyOptions[]{}
bcsikos
Qt: was Slow scrolling
On Tuesday, January 03, 2012 03:36:16 PM Stephan Witt wrote: > Am 03.01.2012 um 17:15 schrieb Olivier Ripoll: > > Hi, > > > > Check my 2 messages in the "LyX 2.0.2 Released" thread, one dated > > december 5th (user mailing lists, perhaps devel too) and the > > other one dated december 16th (devel ML), which contains more > > details: > > > > http://www.mail-archive.com/lyx-users@lists.lyx.org/msg90218.html > > http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg172462.htm > > l > > Hi, > > I'm almost sure it depends on Qt-Version. > > With LyX on Mac with Qt4 we have two fundamental problems: At the risk of sounding like a broken record, if Qt continues to produce these types of problems, isn't there different library or combination of libraries the developers can use? Back when I wrote my "why oh why did you dump xforms" rant, it seemed like maybe the compile problems were just growing pains from Qt going from version 3 to version 4. But now it's years later, and we're still hearing (I paraphrase) "the quality of your LyX program depends on your Qt version." I know, you've told me before, Qt does a lot of busywork and makes programming LyX much simpler. It handles all the localization, etc. Programming LyX without Qt would be a horrendeous chore. But is Qt really doing you a favor when certain Qt versions make your program perform badly? The LyX developers work so hard to create a robust, high productivity program, only to have a tool vendor snatch defeat from the jaws of victory. Isn't there another localization library you can use, and another GUI library, and whatever? Thanks SteveT Steve Litt: http://www.troubleshooters.com My new 99 cent Kindle book: http://www.amazon.com/dp/B006QTBLA2
Re: Slow scrolling
Am 04.01.2012 um 18:05 schrieb James Sutherland: > > On Wed, Jan 4, 2012 at 9:57 AM, Murat Yildizoglu wrote: > Strange indeed, > On my MBP(*), there is no visible lag. Using my touchpad's scroll down (two > finger gesture), I can go from start of the Guide de l'utilisateur to its end > in 14 seconds. Lyx 2.0.2, standard binary downloaded from Lyx.org > (LyX-2.0.2+qt4-cocoa.dmg). > > Maybe I have not correctly understood your test? > > (*) 15" screen, 8GB RAM, 2.4GHz Core i7, OSX 10.7.2. > > > 1. Open a document (e.g. the User Manual). > 2. Either scroll with trackpad or scroll with the scroll bar on the right > side of the window. > > There is a significant lag when scrolling. If you scroll back and forth, the > screen does not follow well at all. Again, I only observe this on OSX 10.7.2 > - not on 10.6.8. > > 2.3 GHz i7 with 8 GB RAM. I've prepared a LyX-package with Qt-4.8.0 and the upload is here: http://dl.dropbox.com/u/27842660/LyX-2.1.0svn%2Bqt4.8.0-cocoa.dmg http://dl.dropbox.com/u/27842660/LyX-2.1.0svn%2Bqt4.8.0-cocoa.dmg.sig The Qt 4.8.0 ChangeLog contains this: Qt for Mac OS X --- - Alien widgets is now used by default for Qt/Cocoa on Mac OS X. - Qt/Cocoa on Mac OS X has now full support for the raster paint engine. - QApplication has now implemented macEventFilter for Qt/Cocoa - HarfBuzz can now be used as an optional text layout engine on Mac OS X. [QTBUG-17728] - Qt shows some love to OS X Lion (10.7). Perhaps this is an improvement on Lion? Please, can someone give it a try? Stephan
Re: Slow scrolling
On Jan 4, 2012, at 8:46 AM, James Sutherland wrote: > On Tue, Jan 3, 2012 at 5:08 PM, Jerry wrote: > > On Jan 3, 2012, at 4:51 PM, Steve Litt wrote: > > > On Monday, January 02, 2012 10:12:47 PM Jerry wrote: > >> I'm evaluating LyX for a major project and am mightily impressed. > >> > >> However, there is one problem that stands out: Scrolling the main > >> LyX window is excruciatingly slow. I'm using LyX 2.0.2 and OS X > >> 10.6.8. It doesn't seem to matter how I scroll--two-finger swipe > >> on MacBook Pro trackpad or using the thumb bar or clicking on the > >> normal scrolling arrows. When scrolling rather fast or using the > >> two-finger "ballistic scrolling", there are large jumps between > >> screen updates; sometimes the jump is more than an entire > >> screenful so there is little hope of reliably spotting things as > >> they go by. While scrolling, processor usage goes to 100% > >> > > Hmmm. I suspect that the problem is worse on my machine because even > scrolling small amounts (a few lines or a couple of pages) is so laggy/jumpy > that it is easily noticeable/annoying--hard to track features as they go by. > > Scrolling large distances in a short time pretty much takes place as fast as > scrolling a native application; it's just that to get the job done in roughly > the same amount of time, there are huge jumps. > > In an earlier post in this thread I noted that 2.0.1 was much better in this > regard (I just tried 2.0.1 a couple hours ago), so at least in part, this is > looks like a recent development. > > Jerry > > > FWIW, I have been noticing this issue on my Mac as well with LyX 2.0.2 > (binary installation) and Mac OSX 10.7.2. It has occurred for me with small > documents as well as large ones. Mouse-scrolling lags substantially. > > I just tried it on another Mac system running OSX 10.6.8 and LyX 2.0.0. No > problems there. I then updated to LyX 2.0.2 on 10.6.8 and there were no > problems with that either. > > So it appears that this issue is unique to LyX on OSX 10.7.x? No—I'm on OS X 10.6.8. Jerry > > James >
Strange biblatex error on a different machine
Hello,
I'm working on a book with a coauthor. I copied all my files (including
preamble and .bib database) to his machine. We are calling biblatex with the
following options:
\usepackage[style=authoryear-icomp,natbib=true,block=space,hyperref=true,abb
reviate=true,sorting=nyt,backend=bibtex8,isbn=false]{biblatex}
Compiling it generates two errors:
(1)
(/usr/local/texlive/2011/texmf-dist/tex/latex/biblatex/cbx/authoryear-icomp.
cbx
File: authoryear-icomp.cbx 2011/06/08 v1.5 biblatex citation style
! Package xkeyval Error: `uniquelist' undefined in families `blx@opt@pre'.
See the xkeyval package documentation for explanation.
2)
(/usr/local/texlive/2011/../texmf-local/tex/latex/biblatex/biblatex.cfg
File: biblatex.cfg
)
! Package xkeyval Error: `isbn' undefined in families `blx@opt@pre'.
See the xkeyval package documentation for explanation.
But if I delete "isbn=false" and change to style=authoryear than compiling
goes fine and no error occurs.
So with the following call we get no error:
\usepackage[style=authoryear,natbib=true,block=space,hyperref=true,abbreviat
e=true,sorting=nyt,backend=bibtex8]{biblatex}
As far as I can say we have exactly the same the same files. We both have
the TexLive 2011 and we are both working with LyX 2.0.2. The only difference
seems to be the machine: He is working on a MacBook4.1 with OS X 10.5.8 and
I have a MacBookPro5,1 with OS X 10.6.8 running.
What could be the reason for this weir error?
Peter
Re: Slow scrolling
Am 04.01.2012 um 16:30 schrieb Jean-Marc Lasgouttes: > Le 04/01/2012 12:44, Stephan Witt a écrit : >> And this is the result: >> I've opened the users guide and started to page down unto the end once. >> >> * 2.0.0, 4.6.3 Carbon, 22 Sekunden >> * 2.0.0, 4.6.3 Cocoa, 23 Sekunden >> * 2.0.2, 4.7.2 Cocoa, 20 Sekunden >> * 2.1svn, 4.8.0 Cocoa, 23 Sekunden >> * 2.1svn, 4.8.0 Carbon, 23 Sekunden >> * 2.1svn, 4.6.3 Carbon, 22 Sekunden > > Is this with autorepeat? Many repeated events get removed in this case. > Therefore, I suspect that the result depends on the autorepeat setting in the > system. Yes, this is with autorepeat. With scrollbar LyX's work area follows the mouse at will immediately. This I've tested with 2.0.2 Cocoa, 2.1svn - 4.8.0 Cocoa and 4.6.3 Carbon. Stephan
Re: Problem with emf to eps convertor metafile2eps
On Wed, Jan 4, 2012 at 1:13 PM, NsK wrote: > a nedunuri cs.utexas.edu> writes: > >> >> Hello, I am running Lyx 2.0.0 on Windows 7. When I import a figure created in >> Visio but saved as an emf file, it converts and appears ok in the Lyx editor. >> However, if I try to view the generated pdf file, adobe reader sits and >> thinks >> for a very long time before it is able to display the page containing the >> graphis. When it finally does, the figure appears vastly blown up in size. I >> need to scale it down in Lyx to about 20% of the original size to get it to >> fit, and even then reader will labor for a very long time beofre displaying >> the page (and sometimes omits the figure entirely). I never noticed this >> problem before b/c I used to give Lyx the eps file, converted from emf by a >> 3rd party tool which is unf. no longer free so i am reliant on the built- >> in convertor now. Any ideas? >> >> cheers >> PS my current workaround is to get visio to save it as a jpg which I import >> into Lyx. This works ok but doesn't produce as sharp an image >> >> > > > I know it's an old thread but just in case someone has the same issue: > > It looks like the new metafile2eps.exe (version 2.1) is the problem. > By rolling back to version 1.5 > (http://wiki.lyx.org/Windows/MetafileToEPSConverter) the issue was solved for > me. > Thanks for resurrecting this--it actually looks very similar to the problem I described in this post: http://www.mail-archive.com/lyx-users@lists.lyx.org/msg90560.html I wonder if it is really Windows-specific or more general. Maria
Re: Problem with emf to eps convertor metafile2eps
a nedunuri cs.utexas.edu> writes: > > Hello, I am running Lyx 2.0.0 on Windows 7. When I import a figure created in > Visio but saved as an emf file, it converts and appears ok in the Lyx editor. > However, if I try to view the generated pdf file, adobe reader sits and > thinks > for a very long time before it is able to display the page containing the > graphis. When it finally does, the figure appears vastly blown up in size. I > need to scale it down in Lyx to about 20% of the original size to get it to > fit, and even then reader will labor for a very long time beofre displaying > the page (and sometimes omits the figure entirely). I never noticed this > problem before b/c I used to give Lyx the eps file, converted from emf by a > 3rd party tool which is unf. no longer free so i am reliant on the built- > in convertor now. Any ideas? > > cheers > PS my current workaround is to get visio to save it as a jpg which I import > into Lyx. This works ok but doesn't produce as sharp an image > > I know it's an old thread but just in case someone has the same issue: It looks like the new metafile2eps.exe (version 2.1) is the problem. By rolling back to version 1.5 (http://wiki.lyx.org/Windows/MetafileToEPSConverter) the issue was solved for me. Cheers
Re: Slow scrolling
Ok, this was exactly what I have done on my system (10.7.2, see my previous mail for full configuration). If I use the scroll bars on the left, I can go to the end of the User guide *immediately* (2 seconds, since I have some difficulty to click on the iPhone's chronometer with the left hand, and start to scroll in Lyx with the right hand). I do not see any lag at all. 2012/1/4 James Sutherland > > On Wed, Jan 4, 2012 at 9:57 AM, Murat Yildizoglu wrote: > >> Strange indeed, >> On my MBP(*), there is no visible lag. Using my touchpad's scroll down >> (two finger gesture), I can go from start of the Guide de l'utilisateur to >> its end in 14 seconds. Lyx 2.0.2, standard binary downloaded from Lyx.org >> (LyX-2.0.2+qt4-cocoa.dmg). >> >> Maybe I have not correctly understood your test? >> >> (*) 15" screen, 8GB RAM, 2.4GHz Core i7, OSX 10.7.2. >> >> > 1. Open a document (e.g. the User Manual). > 2. Either scroll with trackpad or scroll with the scroll bar on the right > side of the window. > > There is a significant lag when scrolling. If you scroll back and forth, > the screen does not follow well at all. Again, I only observe this on OSX > 10.7.2 - not on 10.6.8. > > 2.3 GHz i7 with 8 GB RAM. > -- Prof. Murat Yildizoglu Université Montesquieu Bordeaux IV GREThA (UMR CNRS 5113) Avenue Léon Duguit 33608 Pessac cedex France Bureau : F-331 yi...@u-bordeaux4.fr http://yildizoglu.info http://www.twitter.com/yildizoglu
Re: Slow scrolling
On Wed, Jan 4, 2012 at 9:57 AM, Murat Yildizoglu wrote: > Strange indeed, > On my MBP(*), there is no visible lag. Using my touchpad's scroll down > (two finger gesture), I can go from start of the Guide de l'utilisateur to > its end in 14 seconds. Lyx 2.0.2, standard binary downloaded from Lyx.org > (LyX-2.0.2+qt4-cocoa.dmg). > > Maybe I have not correctly understood your test? > > (*) 15" screen, 8GB RAM, 2.4GHz Core i7, OSX 10.7.2. > > 1. Open a document (e.g. the User Manual). 2. Either scroll with trackpad or scroll with the scroll bar on the right side of the window. There is a significant lag when scrolling. If you scroll back and forth, the screen does not follow well at all. Again, I only observe this on OSX 10.7.2 - not on 10.6.8. 2.3 GHz i7 with 8 GB RAM.
Fwd: Biblography not compatible with author year citations
Sorry, I have forgotten to include the list in the address list. -- Forwarded message -- From: Murat Yildizoglu Date: 2012/1/4 Subject: Re: Biblography not compatible with author year citations To: Dhriti Sundar Ghosh Which bibliography style have you chosen in the bibligraphy field that you have inserted in your document? If You have choses natbib author-year in Menu Document/properties/Bibliography, you should choose one of the author-yearx (I use x=3) formats when you insert the bibliography field in your document (through the menu Insert/List and TOC/Bibliography). 2012/1/4 Dhriti Sundar Ghosh > Hi all, > > I just started using LYX for my doctoral thesis for the last few days. I > installed the latest version of Miktex (2.9) and LYX (2.0.2). > > I am facing a problem regarding the bibliography. Every time I run it it > says : B*ibliography not compatible with author year citations.* > > Please help me in getting rid of this problm. > > Thanks > > -- > ICFO - The Institute of Photonic Sciences > Nanophotonics Group (Optoelectronics) > Mediterranean Technology Park > Castelldefels (Barcelona), Spain > Tel : +34 935534127 > Fax : +34 935534000 > web : www.icfo.es > -- Prof. Murat Yildizoglu Université Montesquieu Bordeaux IV GREThA (UMR CNRS 5113) Avenue Léon Duguit 33608 Pessac cedex France Bureau : F-331 yi...@u-bordeaux4.fr http://yildizoglu.info http://www.twitter.com/yildizoglu -- Prof. Murat Yildizoglu Université Montesquieu Bordeaux IV GREThA (UMR CNRS 5113) Avenue Léon Duguit 33608 Pessac cedex France Bureau : F-331 yi...@u-bordeaux4.fr http://yildizoglu.info http://www.twitter.com/yildizoglu
Re: Slow scrolling
Strange indeed, On my MBP(*), there is no visible lag. Using my touchpad's scroll down (two finger gesture), I can go from start of the Guide de l'utilisateur to its end in 14 seconds. Lyx 2.0.2, standard binary downloaded from Lyx.org (LyX-2.0.2+qt4-cocoa.dmg). Maybe I have not correctly understood your test? (*) 15" screen, 8GB RAM, 2.4GHz Core i7, OSX 10.7.2. 2012/1/4 James Sutherland > On Tue, Jan 3, 2012 at 5:08 PM, Jerry wrote: > >> >> On Jan 3, 2012, at 4:51 PM, Steve Litt wrote: >> >> > On Monday, January 02, 2012 10:12:47 PM Jerry wrote: >> >> I'm evaluating LyX for a major project and am mightily impressed. >> >> >> >> However, there is one problem that stands out: Scrolling the main >> >> LyX window is excruciatingly slow. I'm using LyX 2.0.2 and OS X >> >> 10.6.8. It doesn't seem to matter how I scroll--two-finger swipe >> >> on MacBook Pro trackpad or using the thumb bar or clicking on the >> >> normal scrolling arrows. When scrolling rather fast or using the >> >> two-finger "ballistic scrolling", there are large jumps between >> >> screen updates; sometimes the jump is more than an entire >> >> screenful so there is little hope of reliably spotting things as >> >> they go by. While scrolling, processor usage goes to 100% >> >> >> >> Hmmm. I suspect that the problem is worse on my machine because even >> scrolling small amounts (a few lines or a couple of pages) is so >> laggy/jumpy that it is easily noticeable/annoying--hard to track features >> as they go by. >> >> Scrolling large distances in a short time pretty much takes place as fast >> as scrolling a native application; it's just that to get the job done in >> roughly the same amount of time, there are huge jumps. >> >> In an earlier post in this thread I noted that 2.0.1 was much better in >> this regard (I just tried 2.0.1 a couple hours ago), so at least in part, >> this is looks like a recent development. >> >> Jerry > > > > FWIW, I have been noticing this issue on my Mac as well with LyX 2.0.2 > (binary installation) and Mac OSX 10.7.2. It has occurred for me with > small documents as well as large ones. Mouse-scrolling lags > substantially. > > I just tried it on another Mac system running OSX 10.6.8 and LyX 2.0.0. > No problems there. I then updated to LyX 2.0.2 on 10.6.8 and there were > no problems with that either. > > So it appears that this issue is unique to LyX on OSX 10.7.x? > > James > > -- Prof. Murat Yildizoglu Université Montesquieu Bordeaux IV GREThA (UMR CNRS 5113) Avenue Léon Duguit 33608 Pessac cedex France Bureau : F-331 yi...@u-bordeaux4.fr http://yildizoglu.info http://www.twitter.com/yildizoglu
Re: Lyx function allowing selection of layouts from minibuffer?
On Wed, Jan 4, 2012 at 10:16 AM, stefano franchi wrote: > Dear All, > > I lost all my bindings while trying to figure out why my local > toolbars parameters are not followed and now I can't remember which > function allows you to select an environment (layout) from the > minibuffer. I had it bound to M-p, so that the selection of the > standard env would be M-p s, of the itemize M-P i, etc. I looked both > in the wiki and in the docs, but cannot figure out the proper > function. Most popular advice suggests to use the drop down list (with > shortcuts), which I don't particularly like. > Well, my bad. There is no such function. The behavior I was expecting is due to the explicit and quite extensive list of layout bindings found in LYXDIR/bind/menus.bind Sorry for the noise. Stefano -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA
Lyx function allowing selection of layouts from minibuffer?
Dear All, I lost all my bindings while trying to figure out why my local toolbars parameters are not followed and now I can't remember which function allows you to select an environment (layout) from the minibuffer. I had it bound to M-p, so that the selection of the standard env would be M-p s, of the itemize M-P i, etc. I looked both in the wiki and in the docs, but cannot figure out the proper function. Most popular advice suggests to use the drop down list (with shortcuts), which I don't particularly like. Help is appreciated. Best, Stefano -- __ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA
Biblography not compatible with author year citations
Hi all, I just started using LYX for my doctoral thesis for the last few days. I installed the latest version of Miktex (2.9) and LYX (2.0.2). I am facing a problem regarding the bibliography. Every time I run it it says : B*ibliography not compatible with author year citations.* Please help me in getting rid of this problm. Thanks -- ICFO - The Institute of Photonic Sciences Nanophotonics Group (Optoelectronics) Mediterranean Technology Park Castelldefels (Barcelona), Spain Tel : +34 935534127 Fax : +34 935534000 web : www.icfo.es
Re: Slow scrolling
On Tue, Jan 3, 2012 at 5:08 PM, Jerry wrote: > > On Jan 3, 2012, at 4:51 PM, Steve Litt wrote: > > > On Monday, January 02, 2012 10:12:47 PM Jerry wrote: > >> I'm evaluating LyX for a major project and am mightily impressed. > >> > >> However, there is one problem that stands out: Scrolling the main > >> LyX window is excruciatingly slow. I'm using LyX 2.0.2 and OS X > >> 10.6.8. It doesn't seem to matter how I scroll--two-finger swipe > >> on MacBook Pro trackpad or using the thumb bar or clicking on the > >> normal scrolling arrows. When scrolling rather fast or using the > >> two-finger "ballistic scrolling", there are large jumps between > >> screen updates; sometimes the jump is more than an entire > >> screenful so there is little hope of reliably spotting things as > >> they go by. While scrolling, processor usage goes to 100% > >> > > Hmmm. I suspect that the problem is worse on my machine because even > scrolling small amounts (a few lines or a couple of pages) is so > laggy/jumpy that it is easily noticeable/annoying--hard to track features > as they go by. > > Scrolling large distances in a short time pretty much takes place as fast > as scrolling a native application; it's just that to get the job done in > roughly the same amount of time, there are huge jumps. > > In an earlier post in this thread I noted that 2.0.1 was much better in > this regard (I just tried 2.0.1 a couple hours ago), so at least in part, > this is looks like a recent development. > > Jerry FWIW, I have been noticing this issue on my Mac as well with LyX 2.0.2 (binary installation) and Mac OSX 10.7.2. It has occurred for me with small documents as well as large ones. Mouse-scrolling lags substantially. I just tried it on another Mac system running OSX 10.6.8 and LyX 2.0.0. No problems there. I then updated to LyX 2.0.2 on 10.6.8 and there were no problems with that either. So it appears that this issue is unique to LyX on OSX 10.7.x? James
Re: Slow scrolling
Le 04/01/2012 12:44, Stephan Witt a écrit : And this is the result: I've opened the users guide and started to page down unto the end once. * 2.0.0, 4.6.3 Carbon, 22 Sekunden * 2.0.0, 4.6.3 Cocoa, 23 Sekunden * 2.0.2, 4.7.2 Cocoa, 20 Sekunden * 2.1svn, 4.8.0 Cocoa, 23 Sekunden * 2.1svn, 4.8.0 Carbon, 23 Sekunden * 2.1svn, 4.6.3 Carbon, 22 Sekunden Is this with autorepeat? Many repeated events get removed in this case. Therefore, I suspect that the result depends on the autorepeat setting in the system. JMarc
Re: Slow scrolling
On 01/04/2012 07:34 AM, Rainer M Krug wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/01/12 12:44, Stephan Witt wrote: Am 04.01.2012 um 07:36 schrieb Stephan Witt: Am 04.01.2012 um 01:28 schrieb Jerry: To check if this is the culprit one may add the following line to your preferences file: \force_paint_single_char false On a Mac this is the file "~/Library/Application Support/LyX-2.0/preferences". (Broken cursor placement for long lines should be one consequence.) I've added the line that you suggest and the scrolling is improved--much like or exactly like 2.0.1 scrolling that I commented on earlier in this thread. And I see no problem with an incorrectly placed cursor. Please, try it with a line of many "m" letters. Is the cursor placement at the end of the "m"-text correct? Stephan PS. Currently I'm working on a mini statistics with different settings on my Mac. This takes a significant amount of time because of the many builds I have to try. And this is the result: I've opened the users guide and started to page down unto the end once. * 2.0.0, 4.6.3 Carbon, 22 Sekunden * 2.0.0, 4.6.3 Cocoa, 23 Sekunden * 2.0.2, 4.7.2 Cocoa, 20 Sekunden * 2.1svn, 4.8.0 Cocoa, 23 Sekunden * 2.1svn, 4.8.0 Carbon, 23 Sekunden * 2.1svn, 4.6.3 Carbon, 22 Sekunden Just to add a non-mac number (Ubuntu Oneiric, all updates, LyX self compiled from source, no tweaks, oldish laptop): 2.0.2, qt 4.8.5 25 seconds I get there in about twelve seconds, but this is on a very fast machine. There are noticeable pauses as one hits the graphics, but otherwise it feels responsive. Richard
Re: Slow scrolling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/01/12 12:44, Stephan Witt wrote: > Am 04.01.2012 um 07:36 schrieb Stephan Witt: > >> Am 04.01.2012 um 01:28 schrieb Jerry: To check if this is the culprit one may add the following line to your preferences file: \force_paint_single_char false On a Mac this is the file "~/Library/Application Support/LyX-2.0/preferences". (Broken cursor placement for long lines should be one consequence.) >>> >>> I've added the line that you suggest and the scrolling is >>> improved--much like or exactly like 2.0.1 scrolling that I >>> commented on earlier in this thread. And I see no problem with >>> an incorrectly placed cursor. >> >> Please, try it with a line of many "m" letters. Is the cursor >> placement at the end of the "m"-text correct? >> >> Stephan >> >> PS. Currently I'm working on a mini statistics with different >> settings on my Mac. This takes a significant amount of time >> because of the many builds I have to try. > > And this is the result: I've opened the users guide and started to > page down unto the end once. > > * 2.0.0, 4.6.3 Carbon, 22 Sekunden * 2.0.0, 4.6.3 Cocoa, 23 > Sekunden * 2.0.2, 4.7.2 Cocoa, 20 Sekunden * 2.1svn, 4.8.0 Cocoa, > 23 Sekunden * 2.1svn, 4.8.0 Carbon, 23 Sekunden * 2.1svn, 4.6.3 > Carbon, 22 Sekunden Just to add a non-mac number (Ubuntu Oneiric, all updates, LyX self compiled from source, no tweaks, oldish laptop): 2.0.2, qt 4.8.5 25 seconds Rainer > > All tests I've made with \force_paint_single_char true and false. > No real difference. > > You can see it yourself - there is no performance gain or loss on > my system (Macbook Pro OS X 10.6.8). > > Jerry, may I ask you to provide some numbers for your use case and > for the users guide? > > Stephan - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8ER0MACgkQoYgNqgF2egoCgQCdGMm9GkIdVyWdG8kvp9dgxNa9 O1IAn3qQGxsZjA3L2OQ8Ih0U2TYW4mCS =7Ooh -END PGP SIGNATURE-
Re: Slow scrolling
Am 04.01.2012 um 07:36 schrieb Stephan Witt: > Am 04.01.2012 um 01:28 schrieb Jerry: >>> >>> To check if this is the culprit one may add the following line to your >>> preferences file: >>> \force_paint_single_char false >>> On a Mac this is the file "~/Library/Application >>> Support/LyX-2.0/preferences". >>> (Broken cursor placement for long lines should be one consequence.) >> >> I've added the line that you suggest and the scrolling is improved--much >> like or exactly like 2.0.1 scrolling that I commented on earlier in this >> thread. And I see no problem with an incorrectly placed cursor. > > Please, try it with a line of many "m" letters. Is the cursor placement at > the end of the "m"-text correct? > > Stephan > > PS. Currently I'm working on a mini statistics with different settings on my > Mac. > This takes a significant amount of time because of the many builds I have to > try. And this is the result: I've opened the users guide and started to page down unto the end once. * 2.0.0, 4.6.3 Carbon, 22 Sekunden * 2.0.0, 4.6.3 Cocoa, 23 Sekunden * 2.0.2, 4.7.2 Cocoa, 20 Sekunden * 2.1svn, 4.8.0 Cocoa, 23 Sekunden * 2.1svn, 4.8.0 Carbon, 23 Sekunden * 2.1svn, 4.6.3 Carbon, 22 Sekunden All tests I've made with \force_paint_single_char true and false. No real difference. You can see it yourself - there is no performance gain or loss on my system (Macbook Pro OS X 10.6.8). Jerry, may I ask you to provide some numbers for your use case and for the users guide? Stephan
Re: Slow scrolling
Am 04.01.2012 um 09:41 schrieb Jerry: > > On Jan 3, 2012, at 11:36 PM, Stephan Witt wrote: > >> Am 04.01.2012 um 01:28 schrieb Jerry: To check if this is the culprit one may add the following line to your preferences file: \force_paint_single_char false On a Mac this is the file "~/Library/Application Support/LyX-2.0/preferences". (Broken cursor placement for long lines should be one consequence.) >>> >>> I've added the line that you suggest and the scrolling is improved--much >>> like or exactly like 2.0.1 scrolling that I commented on earlier in this >>> thread. And I see no problem with an incorrectly placed cursor. >> >> Please, try it with a line of many "m" letters. Is the cursor placement at >> the end of the "m"-text correct? > > Uh-oh. With 2.0.2 on my 15 inch MacBook Pro screen, using Cambria font, > screen zoom set to 140%, the cursor gets ahead of (to the right of) a > screenful of m's by about 1.5 cm as measured with an on-screen ruler. If I > then make the window smaller so that the line wraps, forcing the cursor to > near the left edge of the window, the error is quite small or none at all, > but as I continue to make the window even narrower, the error increases until > another line wrap, etc. This is what I've expected. > With 2.0.1, there is no cursor placement error. > > Oddly, it no longer matters if the line > \force_paint_single_char false > is in the Preferences file--the behavior is now the same (faster scrolling, > misplaced cursor) with or without that line. That's correct. The default for this (internal) preference depends on the Qt-Version. Currently I'm looking for the optimal solution... including trying out the Qt-4.8.0 library... Stephan
Re: Slow scrolling
On 03.01.2012 21:36, Stephan Witt wrote: Am 03.01.2012 um 17:15 schrieb Olivier Ripoll: [...] Hi, I'm almost sure it depends on Qt-Version. IIRC, I checked the file properties of QtCore4 and QtGUI4 dlls and both files were version 4.7.4.0 in LyX 2.0.1 and 2.0.2. But perhaps my memories are confused there. With LyX on Mac with Qt4 we have two fundamental problems: 1. Qt4 with Carbon crashes when interacting with some desktop tools like Divvy or SizeUp http://www.lyx.org/trac/ticket/7365 and http://www.lyx.org/trac/ticket/7519 2. Qt4 with Cocoa is painting text with kerning hints This doesn't match with the drawing engine of LyX and LyX's cursor movement. See the discussion here: http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg169152.html I've build 2.0.2 on Mac with Qt4.7 where Cocoa is the default to avoid (1). The drawback is we have to deal with (2) - the current solution is to draw text just char by char, the text fragments are only one character long. To check if this is the culprit one may add the following line to your preferences file: \force_paint_single_char false On a Mac this is the file "~/Library/Application Support/LyX-2.0/preferences". (Broken cursor placement for long lines should be one consequence.) Will try this when I have some time. Best regards, Olivier Stephan
Re: Slow scrolling
On Jan 3, 2012, at 11:36 PM, Stephan Witt wrote: > Am 04.01.2012 um 01:28 schrieb Jerry: >>> >>> To check if this is the culprit one may add the following line to your >>> preferences file: >>> \force_paint_single_char false >>> On a Mac this is the file "~/Library/Application >>> Support/LyX-2.0/preferences". >>> (Broken cursor placement for long lines should be one consequence.) >> >> I've added the line that you suggest and the scrolling is improved--much >> like or exactly like 2.0.1 scrolling that I commented on earlier in this >> thread. And I see no problem with an incorrectly placed cursor. > > Please, try it with a line of many "m" letters. Is the cursor placement at > the end of the "m"-text correct? Uh-oh. With 2.0.2 on my 15 inch MacBook Pro screen, using Cambria font, screen zoom set to 140%, the cursor gets ahead of (to the right of) a screenful of m's by about 1.5 cm as measured with an on-screen ruler. If I then make the window smaller so that the line wraps, forcing the cursor to near the left edge of the window, the error is quite small or none at all, but as I continue to make the window even narrower, the error increases until another line wrap, etc. With 2.0.1, there is no cursor placement error. Oddly, it no longer matters if the line \force_paint_single_char false is in the Preferences file--the behavior is now the same (faster scrolling, misplaced cursor) with or without that line. Jerry > > Stephan > > PS. Currently I'm working on a mini statistics with different settings on my > Mac. > This takes a significant amount of time because of the many builds I have to > try. >
Re: svn update po/xxx conflict
Am Dienstag, 3. Januar 2012, 18:02:14 schrieb Jürgen Spitzmüller: > Wolfgang Engelmann wrote: > > Thanks again, Juergen and Richard, > > sorry that I forgot to configure make > > > > when doing make and make check, I get this error: > > > > make[3]: Entering directory `/mnt/sda/home/wolfgang/lyx-devel/src' > > make[3]: *** Keine Regel vorhanden, um das Target > > »graphics/Previews.cpp«, > > > > benötigt von »Previews.o«, zu erstellen. Schluss. > > > > make[3]: Leaving directory `/mnt/sda/home/wolfgang/lyx-devel/src' > > make[2]: *** [check-recursive] Fehler 1 > > make[2]: Leaving directory `/mnt/sda/home/wolfgang/lyx-devel/src' > > make[1]: *** [check] Fehler 2 > > make[1]: Leaving directory `/mnt/sda/home/wolfgang/lyx-devel/src' > > make: *** [check-recursive] Fehler 1 > > > > does it mean, I have to make clean and run first ./autogen.sh ? > > try it. > > > and make install prefix=/usr/local/stow/lyx202 > > might be wise, to have the old 2.0.1 available if something goes wrong > > ? > > I think a prefix for different branch versions is overkill, the changes > should be bearable. And you can always just reinstall 2.0.1 if things > go wrong. > > Jürgen All done, worked alright, thanks a lot Wolfgang
