Re: UTF-8 and layouts - bugs
Abdelrazak Younes a écrit : Philippe Charpentier wrote: During my tests I found the three bugs below, I did not found in bugzilla: * About layouts: the tag DependsOn does not works when it calls a Style whose name contains special characters. I cannot test everything, but I suspect that it does not works when the name of called Style contains an underscore ( _ ) What does that mean does not work? Is it a crash? Or just the LateX that does not compile? Abdel. The Preamble of the Style called by the tag is not put in the Preamble of the document and LaTeX does not compile. PhC
Re: UTF-8 and layouts - bugs
Philippe Charpentier wrote: The Preamble of the Style called by the tag is not put in the Preamble of the document and LaTeX does not compile. So bug 3521? http://bugzilla.lyx.org/show_bug.cgi?id=3521 Jürgen
Re: Open Patches
Alfredo Braunstein wrote: 1) leave as it is and fix the thing correctly in 1.5.1. (too risky to do that now methinks). Seems the most reasonable to me as well. I targetted bug 3600 to 1.5.1. Jürgen
Re: Exception when opening Document-settings on Solaris
Enrico Forestieri [EMAIL PROTECTED] writes: Yes, this is r18988 striking again :( I don't think that this is related to the platform but rather to the compiler version. I think that gcc 3.x is missing some locale facets. Jean-Pierre, does the attached patch solve the bug for you? Solved, thanks a lot. -- Jean-Pierre
Re: UTF-8 and layouts - bugs
Jürgen Spitzmüller a écrit : Philippe Charpentier wrote: The Preamble of the Style called by the tag is not put in the Preamble of the document and LaTeX does not compile. So bug 3521? http://bugzilla.lyx.org/show_bug.cgi?id=3521 Jürgen I don't think so. If I understand well, bug 3521 is related to non ascii characters in layouts which is solved now. I will try to get time to create simple Styles with the same problem and I will post the result in the list. PhC
Re: Exception when opening Document-settings on Solaris
Pavel == Pavel Sanda [EMAIL PROTECTED] writes: Anyway, after r18988 LyX is not so much forgiving about wrong locales. On Linux, try for example: $ env LC_ALL=foo ./src/lyx-qt4 and you will get that exception, too. Pavel Ouch. What if we instead of using multiple #ifs catch the Pavel exception and decide what kind sorter would be used ? Or maybe revert the locale sorting patch for 1.5.0 and take the time to get it right. JMarc
Re: Slow motion while editing
On Wed, 2007-07-11 at 14:06 +0200, Pavel Sanda wrote: Hello, I haven't closely followed the debates concerning the cursor motion speed and don't know what is the current status (some patches pending?) but as I started work 1.5rc2 the typing speed is slow and to wait when moving with cursor in text is very painful (this applies to situation when i start new document, havent experimentated more up to this moment). But what I accidentally found is, that the whole problem simply disappears in the moment I copy and paste some text. Is this known ? Does it resemble this? http://bugzilla.lyx.org/show_bug.cgi?id=3700 Try resizing the window and then resizing it back. If that clears it as well it's the same problem. Have fun, Darren
Re: Slow motion while editing
On Wed, 2007-07-11 at 09:29 -0500, Bo Peng wrote: Must be an X11 selection problem cause I can't reproduce under Windows. The report lacks some details but I can not reproduce anything here either. (Linux). I have a fast machine though. If it's the problem I reported (see a recent reply by me), then I think it's still happening in SVN. I am running OpenSUSE 10.2 on an Athlon XP 3000+. I think I might have learnt to tune it out of my mind but it's frustrating as hell. Have fun, Darren
Re: UTF-8 and layouts - bugs
Philippe Charpentier a écrit :
Jürgen Spitzmüller a écrit :
Philippe Charpentier wrote:
The Preamble of the Style called by the tag is not put in the Preamble
of the document and LaTeX
does not compile.
So bug 3521?
http://bugzilla.lyx.org/show_bug.cgi?id=3521
Jürgen
I don't think so. If I understand well, bug 3521 is related to non
ascii characters in layouts which is solved now.
I will try to get time to create simple Styles with the same problem
and I will post the result in the list.
PhC
I made the test and my first impression was wright:
Create the following Styles:
Style Test_A
Margin Static
LatexType Command
LatexName TestA
ParIndentMM
ParSkip 0.4
Align Block
AlignPossible Block, Left, Right, Center
LabelType No_Label
Preamble
\def\TestA#1{\textcolor{blue}{#1}}
EndPreamble
End
Style TestA
CopyStyleTest_A
DependsOnTest_A
Preamble
EndPreamble
End
Style TestB
Margin Static
LatexType Command
LatexName TestB
ParIndentMM
ParSkip 0.4
Align Block
AlignPossible Block, Left, Right, Center
LabelType No_Label
Preamble
\def\TestB#1{\textcolor{red}{#1}}
EndPreamble
End
Style Test_B
CopyStyleTestB
DependsOnTestB
Preamble
EndPreamble
End
Then:
Test_B works : the Preamble of TestB is put in the Preamble of the document
TestA does not works : the Preamble of Test_A is not put in the Preamble
of the document
PhC
Re: Need for Mac and RTL beta testers for screen painting performance boost
Hi, On 05.07.2007, at 10:28, Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: some testing would surely be good (that would speak for putting it in soon after a minor 1.5.x release). Please test it then. Dov already tested it with RTL language and didn't see any problem at all. I repeat myself but the only side effect that could happen is that some characters are cropped to the left or to the right. But I am pretty sure now that I took all possible cases into account. I don't have much time for testing, but the more important is if it improves the Mac situation. So let's wait what the testing there results in, and then José will have to decide on this anyway (if it is scheduled for 1.5.0). I have sent the results directly to Abdel, I had a closer look at them now: The function QFontEngineMac::draw uses 8.4% (of overall runtime) in the unpatched version and almost nothing in the patched version. This seems to provide more runtime for QCoreGraphicsPaintEngine::drawPixmap(unpatched: 7.9%, patched: 18.4%). (This is confirmend by two individual measurements.) Andi
Re: UTF-8 and layouts - bugs
Philippe == Philippe Charpentier [EMAIL PROTECTED] writes:
Philippe I made the test and my first impression was wright:
Does the following patch help?
JMarc
Index: src/Layout.cpp
===
--- src/Layout.cpp (révision 19050)
+++ src/Layout.cpp (copie de travail)
@@ -241,7 +241,8 @@ bool Layout::read(Lexer lexrc, TextCla
case LT_OBSOLETEDBY: // replace with a known style
if (lexrc.next()) {
-docstring const style = lexrc.getDocString();
+docstring const style =
+ subst(lexrc.getDocString(), '_', ' ');
if (tclass.hasLayout(style)) {
docstring const tmpname = name_;
@@ -262,7 +263,7 @@ bool Layout::read(Lexer lexrc, TextCla
case LT_DEPENDSON:
if (lexrc.next())
-depends_on_ = lexrc.getDocString();
+ depends_on_ = subst(lexrc.getDocString(), '_', ' ');
break;
case LT_MARGIN: // margin style definition.
Re: Open Patches
On Wed, 11 Jul 2007, Dov Feldstern wrote: Jürgen Spitzmüller wrote: Michael Gerz wrote: there are three more patches which may be subject to discussion: [patch] bug 1820 --- footnotes in different language (by Dov) As I just posted in a separate message, it turns out that (I'm pretty sure) this will require a format change in order to fix correctly; and also, now that I understand what's going on, I see that bug 3613, which is a similar issue, is actually due to a format change which happened way back when, but did not have an accompanying lyx2lyx... If possible, both these should be fixed before 1.5.0, but I don't think I can do it within a day or two :( ... So how long time would it take to do properly? If it's important enough, maybe you can get an extension from Jose'. /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: [Patch] Release notes
On Wed, 11 Jul 2007, José Matos wrote: On Wednesday 11 July 2007 17:16:47 [EMAIL PROTECTED] wrote: The text refers to LyX 1.4.4 in the beginning, should that be 1.4.5 instead? /C Yes. Feel free to fix issues like this. :-) Done. I hope you didn't mean that I should have sent a patch to this lis first (I just did it). Here's the difference: ssh-01:lyx-develsvn diff -r 19050 RELEASE-NOTES Index: RELEASE-NOTES === --- RELEASE-NOTES (revision 19050) +++ RELEASE-NOTES (arbetskopia) @@ -1,6 +1,6 @@ This file lists interface changes that might affect users in 1.5.0 and also some known problems in LyX 1.5.0 that did not occur in -1.4.4. Note that fixes are available for many of these, but they have +1.4.5. Note that fixes are available for many of these, but they have not yet been applied because of incomplete testing. /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: [Patch] Release notes
On Thursday 12 July 2007 09:16:18 [EMAIL PROTECTED] wrote: Done. I hope you didn't mean that I should have sent a patch to this lis first (I just did it). Here's the difference: Small changes to documentation are OK. It does not hurt to give an warning in advance but there is no need to wait for an explicit approval, unless the number of changes is huge and/or potentially controversial. :-) -- José Abílio
Re: Exception when opening Document-settings on Solaris
On Wednesday 11 July 2007 20:36:25 Enrico Forestieri wrote: Yes, this is r18988 striking again :( I don't think that this is related to the platform but rather to the compiler version. I think that gcc 3.x is missing some locale facets. Jean-Pierre, does the attached patch solve the bug for you? Anyway, after r18988 LyX is not so much forgiving about wrong locales. On Linux, try for example: $ env LC_ALL=foo ./src/lyx-qt4 and you will get that exception, too. Is this (!defined(USE_WCHAR_T) still required? As far as I understood you argument this would be enough: #if defined(__GNUC__) __GNUC__ 4) Or at least the other way around: #if defined(__GNUC__) __GNUC__ 4) || (!defined(USE_WCHAR_T) -- José Abílio
Re: UTF-8 and layouts - bugs
On Thursday 12 July 2007 09:03:41 Jean-Marc Lasgouttes wrote: Does the following patch help? If it works put it in as it is the right fix. JMarc -- José Abílio
Re: UTF-8 and layouts - bugs
Jean-Marc Lasgouttes a écrit : Philippe == Philippe Charpentier [EMAIL PROTECTED] writes: Philippe I made the test and my first impression was wright: Does the following patch help? JMarc I just test it on the latest svn : it works fine PhC
Re: UTF-8 and layouts - bugs
José == José Matos [EMAIL PROTECTED] writes: José On Thursday 12 July 2007 09:03:41 Jean-Marc Lasgouttes wrote: Does the following patch help? José If it works put it in as it is the right fix. Done. JMarc
Re: UTF-8 and layouts - bugs
Philippe == Philippe Charpentier [EMAIL PROTECTED] writes: Philippe I just test it on the latest svn : it works fine OK, put it in. This issue existed also with 1.3.x and 1.4.x, right? JMarc
Re: Exception when opening Document-settings on Solaris
On Thu, Jul 12, 2007 at 10:05:09AM +0100, José Matos wrote: On Wednesday 11 July 2007 20:36:25 Enrico Forestieri wrote: Yes, this is r18988 striking again :( I don't think that this is related to the platform but rather to the compiler version. I think that gcc 3.x is missing some locale facets. Jean-Pierre, does the attached patch solve the bug for you? Anyway, after r18988 LyX is not so much forgiving about wrong locales. On Linux, try for example: $ env LC_ALL=foo ./src/lyx-qt4 and you will get that exception, too. Is this (!defined(USE_WCHAR_T) still required? I think so, see below. As far as I understood you argument this would be enough: #if defined(__GNUC__) __GNUC__ 4) No, because it doesn't catch systems where sizeof(wchar_t) == 2 and gcc = 4.0. Or at least the other way around: #if defined(__GNUC__) __GNUC__ 4) || (!defined(USE_WCHAR_T) This one would also catch MSVC, which AFAIK has no problem with the locale sorting. -- Enrico
[patch] Re: UTF-8 and layouts - bugs
Jürgen Spitzmüller wrote:
* In a new document write: a word
Then change the size of the two words to small; then change the color
of a (to red for example).
Then lyx traduce it as : \textcolor{red}{\small a}{\small word} and
the space between a and
word disappear.
this is
http://bugzilla.lyx.org/show_bug.cgi?id=3382
Here's an alternative patch for this issue. The problem is that blanks are
swallowed if they follow another blank that is ending a command, such as in
\small word
We need to care about that, notwithstanding whether we manage to improve the
LaTeX output (as Uwe suggests rightly in the bug report), because this case
can nevertheless occur, so the two attempts are orthogonal.
The attached patch is a bit more complicated than my first attempt on bugzilla
that just ends every font size command by '{}' instead of a blank, but it
results in better LaTeX output. It checks whether a font switch command with
a trailing blank has occured, and if so, it outputs a normal space (\ )
instead of a blank, i.e. in the case above:
\textcolor{red}{\small a}{\small \ word}
Even better would be \small\ word, but I don't see how I could get that.
So I think this is the best we can do for now, however I'm not entirely sure
about the implementation details. So please have a look if it strikes you
correct.
Jürgen
Index: src/Paragraph.cpp
===
--- src/Paragraph.cpp (Revision 19033)
+++ src/Paragraph.cpp (Arbeitskopie)
@@ -66,6 +66,7 @@
namespace lyx {
using support::contains;
+using support::suffixIs;
using support::rsplit;
@@ -2065,24 +2066,38 @@
}
}
+ bool trailing_blank = false;
// Do we need to change font?
if ((font != running_font ||
font.language() != running_font.language())
i != body_pos - 1)
{
- column += font.latexWriteStartChanges(os, bparams,
+ odocstringstream ods;
+ column += font.latexWriteStartChanges(ods, bparams,
runparams, basefont,
last_font);
running_font = font;
open_font = true;
+ docstring fontchange = ods.str();
+ // check if the fontchange ends with a trailing blank
+ if (suffixIs(fontchange, 0x0020))
+trailing_blank = true;
+ os fontchange;
}
if (c == ' ') {
+ // If a blank follows a font change that is itself finished
+ // by a blank (e.g. {\Huge ), we need a normal space
+ // in order to prevent the blank from being swallowed.
+ if (trailing_blank) {
+os \\ ;
+column += 2;
+ }
// Do not print the separation of the optional argument
// if style-pass_thru is false. This works because
// simpleTeXSpecialChars ignores spaces if
// style-pass_thru is false.
- if (i != body_pos - 1) {
+ else if (i != body_pos - 1) {
if (pimpl_-simpleTeXBlanks(
*(runparams.encoding), os, texrow,
i, column, font, *style))
Re: Exception when opening Document-settings on Solaris
On Thu, Jul 12, 2007 at 09:26:55AM +0200, Jean-Marc Lasgouttes wrote: Pavel == Pavel Sanda [EMAIL PROTECTED] writes: Anyway, after r18988 LyX is not so much forgiving about wrong locales. On Linux, try for example: $ env LC_ALL=foo ./src/lyx-qt4 and you will get that exception, too. Pavel Ouch. What if we instead of using multiple #ifs catch the Pavel exception and decide what kind sorter would be used ? Or maybe revert the locale sorting patch for 1.5.0 and take the time to get it right. This one may be the best option. -- Enrico
[PATCH] some build improvements for the mac (was Re: compliation problems on mac osx with 1.5rc2)
Roger == Roger Mc Murtrie [EMAIL PROTECTED] writes: Roger svn version built successfully with your latest patch iconv-2 Roger but needs export LDFLAGS/ OK, then here is the patch that I propose to apply. What it does: - check earlier for -liconv and -lz, since Qt4 needs them - put LIBICONV in LIBS, and update the Makefiles accordingly. - do not try to run pkg-config tests when pkg-config is not installed. - update and simplify INSTALL.MacOSX: * advise to use pkg-config * remove -lz from LDFLAGS * remove --with-frontend=qt4 from configure line * in the svn case, remove also --disable-stdlib-debug --disable-concept-checks (and explain why --disable-stdlib-debug may be needed). Roger, I'd appreciate if you could test this latest patch (in particular without pkg-config). Bennett, could you check that what I did makes sense (you probably know things I do not know). Jose', can I apply? JMarc Index: src/Makefile.am === --- src/Makefile.am (révision 19050) +++ src/Makefile.am (copie de travail) @@ -27,7 +27,7 @@ LYX_POST_LIBS = frontends/controllers/li BOOST_LIBS = $(BOOST_REGEX) $(BOOST_SIGNALS) $(BOOST_FILESYSTEM) $(BOOST_IOSTREAMS) -OTHERLIBS = $(BOOST_LIBS) $(LIBICONV) $(INTLLIBS) $(AIKSAURUS_LIBS) @LIBS@ $(SOCKET_LIBS) +OTHERLIBS = $(BOOST_LIBS) $(INTLLIBS) $(AIKSAURUS_LIBS) @LIBS@ $(SOCKET_LIBS) bin_PROGRAMS = lyx noinst_PROGRAMS = $(FRONTENDS_PROGS) Index: src/client/Makefile.am === --- src/client/Makefile.am (révision 19050) +++ src/client/Makefile.am (copie de travail) @@ -16,7 +16,7 @@ BOOST_LIBS = $(BOOST_REGEX) $(BOOST_FILE lyxclient_LDADD = \ $(top_builddir)/src/support/libsupport.la \ - $(BOOST_LIBS) $(LIBICONV) $(INTLLIBS) @LIBS@ $(SOCKET_LIBS) + $(BOOST_LIBS) $(INTLLIBS) @LIBS@ $(SOCKET_LIBS) lyxclient_SOURCES = \ boost.cpp \ Index: INSTALL.MacOSX === --- INSTALL.MacOSX (révision 19050) +++ INSTALL.MacOSX (copie de travail) @@ -1,7 +1,7 @@ Building LyX/Mac-1.5 Ronald Florence [EMAIL PROTECTED] -Modified by Bennett Helm [EMAIL PROTECTED] and by Anders -Ekberg [EMAIL PROTECTED]. +Modified by Bennett Helm [EMAIL PROTECTED], Anders +Ekberg [EMAIL PROTECTED] and Jean-Marc Lasgouttes [EMAIL PROTECTED]. LyX/Mac is built from the LyX source, the GPL-licensed Trolltech Qt/Mac library, and a custom application bundle. @@ -50,6 +50,11 @@ using: sudo port install gettext +4. [Useful to simplify detection of Qt:] pkg-config = 0.9.0. Again, +the simplest way is through MacPorts: + + sudo port install pkgconfig + BUILD INSTRUCTIONS @@ -60,10 +65,13 @@ where you installed Qt for /path/to/QT4 (a) Official Releases -cd to the top of the LyX source hierarchy, and enter: +If you did not install pkg-config, first set the LDFLAGS variable: + + export LDFLAGS=-framework Carbon -framework OpenGL -framework AGL -framework QuickTime -framework Cocoa - export LDFLAGS=-framework Carbon -framework OpenGL -framework AGL -framework QuickTime -lz -framework Cocoa - ./configure --prefix=/path/to/LyX.app --with-version-suffix=-1.5 --without-x --with-frontend=qt4 --with-qt4-dir=/path/to/QT4 --with-included-gettext --enable-optimization=-Os +Then, cd to the top of the LyX source hierarchy, and enter: + + ./configure --prefix=/path/to/LyX.app --with-version-suffix=-1.5 --without-x --with-qt4-dir=/path/to/QT4 --with-included-gettext --enable-optimization=-Os make make install-strip @@ -76,14 +84,20 @@ user's directory being located at ~/Libr Building LyX from developmental sources requires a few more steps. Instead of the instructions above, do the following: -cd to the top of the LyX source hierarchy, and enter: +If you did not install pkg-config, first set the LDFLAGS variable: + + export LDFLAGS=-framework Carbon -framework OpenGL -framework AGL -framework QuickTime -framework Cocoa + +Then, cd to the top of the LyX source hierarchy, and enter: - export LDFLAGS=-framework Carbon -framework OpenGL -framework AGL -framework QuickTime -lz -framework Cocoa ./autogen.sh - ./configure --prefix=/path/to/LyX.app --with-version-suffix=-1.5 --without-x --with-frontend=qt4 --with-qt4-dir=/path/to/QT4 --with-included-gettext --enable-optimization=-Os --disable-stdlib-debug --disable-concept-checks + ./configure --prefix=/path/to/LyX.app --with-version-suffix=-1.5 --without-x --with-qt4-dir=/path/to/QT4 --with-included-gettext --enable-optimization=-Os make make install-strip +Note that by default svn versions use some extra debugging code that +somewhat slows LyX down. If it is a real problem, you can pass the +option --disable-stdlib-debug to configure. The information on this page is believed to be accurate, has been used successfully on many systems and sites, and has benefited from the Index:
Re: Exception when opening Document-settings on Solaris
On Thursday 12 July 2007 10:41:25 Enrico Forestieri wrote: This one would also catch MSVC, which AFAIK has no problem with the locale sorting. OK. You can commit the change. -- Enrico -- José Abílio
Re: Need for Mac and RTL beta testers for screen painting performance boost
Andreas Neustifter wrote: Hi, On 05.07.2007, at 10:28, Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: some testing would surely be good (that would speak for putting it in soon after a minor 1.5.x release). Please test it then. Dov already tested it with RTL language and didn't see any problem at all. I repeat myself but the only side effect that could happen is that some characters are cropped to the left or to the right. But I am pretty sure now that I took all possible cases into account. I don't have much time for testing, but the more important is if it improves the Mac situation. So let's wait what the testing there results in, and then José will have to decide on this anyway (if it is scheduled for 1.5.0). I have sent the results directly to Abdel, Here is my summary of the relevant bits: Patched version: + 26.0% QCoreGraphicsPaintEngine::drawPixmap(QRectF const, QPixmap | | + 17.4% lyx::frontend::GuiWorkArea::paintEvent(QPaintEvent*) (lyx) | | + 8.4% lyx::frontend::QLPainter::text(int, int, | + 0.2% lyx::frontend::QLPainter::text(int, int, + 5.2% QCoreGraphicsPaintEnginePrivate::drawPath(unsigned char, CGPath*) | | | | | + 5.1% lyx::frontend::QLPainter::fillRectangle(int, int, int, + 7.6% QCoreGraphicsPaintEngine::drawTiledPixmap(QRectF const, QPixmap | + 7.6% QPainter::drawTiledPixmap(QRectF const, QPixmap const, | | + 7.6% QWidgetPrivate::paintBackground(QPainter*, QRect const, 4.4% ml_restore (mach_kernel) - 2.6% ml_set_interrupts_enabled (mach_kernel) - 2.4% szone_free (libSystem.B.dylib) Unpatched: + 16.5% QCoreGraphicsPaintEngine::drawPixmap(QRectF const, QPixmap | | + 16.5% lyx::frontend::GuiWorkArea::paintEvent(QPaintEvent*) (lyx) + 7.4% QFontEngineMac::draw(CGContext*, double, double, QTextItemInt | | | | + 7.0% lyx::frontend::QLPainter::text(int, int, + 5.2% QCoreGraphicsPaintEnginePrivate::drawPath(unsigned char, CGPath*) | | | | | + 5.1% lyx::frontend::QLPainter::fillRectangle(int, int, int, + 7.6% QCoreGraphicsPaintEngine::drawTiledPixmap(QRectF const, QPixmap | + 7.6% QPainter::drawTiledPixmap(QRectF const, QPixmap const, | | + 7.6% QWidgetPrivate::paintBackground(QPainter*, QRect const, 4.5% ml_restore (mach_kernel) - 2.6% ml_set_interrupts_enabled (mach_kernel) - 2.1% szone_free (libSystem.B.dylib) So, on Andreas' system the gain is not very sensible in this profile. Basically, the 7.4% saved in QFontEngineMac::draw() are replaced by an additional 8.4% in QCoreGraphicsPaintEngine::drawPixmap() in the patched version. What seems weird to me is that I remember quite well that the font engine in old profiles from Bennett and Christian took more than 35% of the CPU, now, with the unpatched version, it is only 7.4%. The only reason I can think of for this big difference is that the font engine for the modern font is fast. So, Andreas, could you please repeat the test in text mode within a caption for example? There two other interesting results that are common to the two profiles: 1) QWidgetPrivate::paintBackground() takes up to 7.6%! Background painting was something I thought we disabled... weird. 2) rectangle filling is not cheap: 5.2% I attach to this mail a more complete summary of the two profiles. Abdel. # Report 0 - LyX latest patched typing in eqaution.mshark - Time Profile of lyx [apfelbaum.local] SharkProfileViewer # Generated from the visible portion of the outline view + 26.0% QCoreGraphicsPaintEngine::drawPixmap(QRectF const, QPixmap const, QRectF const) (lyx) | + 25.7% QPainter::drawPixmap(QRectF const, QPixmap const, QRectF const) (lyx) | | + 17.4% lyx::frontend::GuiWorkArea::paintEvent(QPaintEvent*) (lyx) | | | + 17.4% QWidget::event(QEvent*) (lyx) | | | | + 17.4% QApplicationPrivate::notify_helper(QObject*, QEvent*) (lyx) | | | | | + 17.4% QApplication::notify(QObject*, QEvent*) (lyx) | | | | | | + 17.4% lyx::frontend::GuiApplication::notify(QObject*, QEvent*) (lyx) | | | | | | | + 17.4% QCoreApplication::notifyInternal(QObject*, QEvent*) (lyx) | | | | | | | | + 17.4% QWidgetPrivate::qt_widget_event(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) (lyx) | | | | | | | | | + 17.4% __CFRunLoopDoObservers (CoreFoundation) | | | | | | | | | | + 17.4% CFRunLoopRunSpecific (CoreFoundation) | | | | | | | | | | | + 17.4% QEventDispatcherMac::processEvents(QFlagsQEventLoop::ProcessEventsFlag) (lyx) | | | | | | | | | | | | + 17.4% QEventLoop::processEvents(QFlagsQEventLoop::ProcessEventsFlag) (lyx) | | | | | | | | | | | | | + 17.4% QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) (lyx) | | | | | | | | | | | | | | + 17.4% QCoreApplication::exec() (lyx) | | | | | | | | | | | | | | | + 17.4% lyx::LyX::exec(int, char**) (lyx) | | | | | | | | | | | | | | | | + 17.4% main (lyx) | | | | | | | | | | | | | | | | | + 17.4% _start (lyx) | | | | | | | | | | | | | | | | | | 17.4% start (lyx) | | + 8.4% lyx::frontend::QLPainter::text(int, int, std::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t const,
Re: Slow motion while editing
Must be an X11 selection problem cause I can't reproduce under Windows. The report lacks some details but I can not reproduce anything here which details you want to provide ? either. (Linux). I have a fast machine though. here pentium-4 3GHz. dont know whether gkrellm is reliable enough but this slowness probably has nothing to do with computation demands, cpu-usage remains very very low - it seems like there is some lock or sleep involved. pavel
Re: UTF-8 and layouts - bugs
Jean-Marc Lasgouttes a écrit : Philippe == Philippe Charpentier [EMAIL PROTECTED] writes: Philippe I just test it on the latest svn : it works fine OK, put it in. This issue existed also with 1.3.x and 1.4.x, right? JMarc Yes PhC
Re: [patch] Re: UTF-8 and layouts - bugs
Jürgen == Jürgen Spitzmüller [EMAIL PROTECTED] writes:
Jürgen The attached patch is a bit more complicated than my first
Jürgen attempt on bugzilla that just ends every font size command by
Jürgen '{}' instead of a blank, but it results in better LaTeX
Jürgen output. It checks whether a font switch command with a
Jürgen trailing blank has occured, and if so, it outputs a normal
Jürgen space (\ ) instead of a blank, i.e. in the case above:
Jürgen \textcolor{red}{\small a}{\small \ word}
What about replacing the final blank by {} instead , and output
\textcolor{red}{\small a}{\small{} word}
It should be easy with what you have already done.
JMarc
Re: [PATCH] some build improvements for the mac (was Re: compliation problems on mac osx with 1.5rc2)
On Thursday 12 July 2007 10:52:11 Jean-Marc Lasgouttes wrote: Jose', can I apply? Yes. JMarc -- José Abílio
Re: [patch] Re: UTF-8 and layouts - bugs
Jean-Marc Lasgouttes wrote:
What about replacing the final blank by {} instead , and output
\textcolor{red}{\small a}{\small{} word}
It should be easy with what you have already done.
This is what I proposed first, but Uwe doesn't like it ;-)
It is of course much easier, but it's less elegant LaTeX code, even more so as
the {} is always output, whereas the \ in my recent patch is only output
if there are really two subsequent blanks.
Jürgen
Re: Slow motion while editing
Pavel Sanda wrote: Must be an X11 selection problem cause I can't reproduce under Windows. The report lacks some details but I can not reproduce anything here which details you want to provide ? either. (Linux). I have a fast machine though. here pentium-4 3GHz. dont know whether gkrellm is reliable enough but this slowness probably has nothing to do with computation demands, cpu-usage remains very very low - it seems like there is some lock or sleep involved. Which sytem is that? If it is KDE or GNOME based, maybe there's some global Clipboard or X11 Selection issue... could you please try to launch a bare X11 session with a minimalist window manager (i.e. without KDE nor Gnome) and report back? Abdel.
Re: [patch] Re: UTF-8 and layouts - bugs
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes:
This is what I proposed first, but Uwe doesn't like it ;-)
It is of course much easier, but it's less elegant LaTeX code, even more so
as
the {} is always output, whereas the \ in my recent patch is only output
if there are really two subsequent blanks.
No, I meant output rhe {} only when there are two consecutive blanks.
JMarc
Re: [patch] Re: UTF-8 and layouts - bugs
Jean-Marc Lasgouttes wrote:
No, I meant output rhe {} only when there are two consecutive blanks.
You mean, pass information to Font::latexWriteStartChanges that the character
following the font change will be a blank? That could be doable.
Jürgen
Re: [PATCH] Important Change Tracking Patch
On Wednesday 11 July 2007 18:13:26 Michael Gerz wrote: Hi, once again, I would like to draw your attention to the attached patch. It fixes a serious problem with change-tracked output (text inside deleted insets appears as unchanged text). Could someone please have a look at the code and do some testing? As I will not be able to do any LyX work before tomorrow evening (i.e., before the release of LyX 1.5.0), could someone please commit the patch if the feedback is positive? Michael I am not sure about this patch. I agree that the bug is annoying (I have noticed it before myself) but it is neither an easy fix nor a data loss type of bug. I propose to leave this for 1.5.1 A thousand thanks in advance! Michael PS: LyX 1.5.0 will be great! I agree. :-) -- José Abílio
Re: Slow motion while editing
But what I accidentally found is, that the whole problem simply disappears in the moment I copy and paste some text. Is this known ? Does it resemble this? does copying text by Ctrl+C helps for you ? http://bugzilla.lyx.org/show_bug.cgi?id=3700 Try resizing the window and then resizing it back. If that clears it as well it's the same problem. i was trying to resize the window in many ways but havent succeeded, the problem remains. seems to be different issue. moreover that while i was playing few minutes only with resizing i came to new displaying problem which resembles http://bugzilla.lyx.org/show_bug.cgi?id=3231 sometimes only paragraph of cursor is visible - but in this case even the current paragraph was not visible and you have to move cursor to make it appear. it does not happen always but usually when you resize the window to some very small area - say one word width, three lines height and then you resize it back (or maximize). more - the slider on the right side is often in a position, which cannot be reached again and its size is different after you move with cursor and screen gets repainted. pavel
Re: Slow motion while editing
Which sytem is that? If it is KDE or GNOME based, maybe there's some global Clipboard or X11 Selection issue... could you please try to launch a bare X11 session with a minimalist window manager (i.e. without KDE nor Gnome) and report back? i use only enlightenment 0.16. is it minimalistic enough ? pavel
Re: Open Patches
On Wednesday 11 July 2007 17:51:44 Michael Gerz wrote: IIRC only Alfredo's patch #3600 This fix was delayed for 1.5.1 and the Windows font patch are not committed. Any news on this from Joost or Uwe? Michael -- José Abílio
Re: Exception when opening Document-settings on Solaris
On Thu, Jul 12, 2007 at 10:53:54AM +0100, José Matos wrote: On Thursday 12 July 2007 10:41:25 Enrico Forestieri wrote: This one would also catch MSVC, which AFAIK has no problem with the locale sorting. OK. You can commit the change. I did it. -- Enrico
Re: [PATCH] Important Change Tracking Patch
José Matos [EMAIL PROTECTED] writes: I agree that the bug is annoying (I have noticed it before myself) but it is neither an easy fix nor a data loss type of bug. I propose to leave this for 1.5.1 I agree with you José. In particular I do not like chnaging RunParams to be non-const (this need serious testing). JMarc
Re: Slow motion while editing
Pavel Sanda wrote: Which sytem is that? If it is KDE or GNOME based, maybe there's some global Clipboard or X11 Selection issue... could you please try to launch a bare X11 session with a minimalist window manager (i.e. without KDE nor Gnome) and report back? i use only enlightenment 0.16. is it minimalistic enough ? I don't know... enlightenment is a kind of desktop too, isn't it? Maybe there's some bad interactions with the clipboard... I've been using Windows for the last 6 years so I am probably talking nonsense here. Abdel.
Re: Open Patches
José Matos wrote: On Wednesday 11 July 2007 17:51:44 Michael Gerz wrote: and the Windows font patch are not committed. Any news on this from Joost or Uwe? Author: forenr Date: Wed Jul 11 13:57:58 2007 New Revision: 19038 URL: http://www.lyx.org/trac/changeset/19038 Log: Fix bug 3962 (by me, Peter, and Joost) * src/support/os_cygwin.cpp * src/support/os_win32.cpp (addFontResources): use AddFontResourceEx on Windows version supporting this API in order to mark our fonts as private. (restoreFontResources): ditto with RemoveFontResourceEx.
Re: Exception when opening Document-settings on Solaris
On Thursday 12 July 2007 10:41:25 Enrico Forestieri wrote: This one would also catch MSVC, which AFAIK has no problem with the locale sorting. OK. You can commit the change. even if this change helps for solaris i fear many crashes on systems with strangely set locales. the changeset should be reverted back until we know how safely detect the error. btw have anybody better solution than handling the exception ? pavel
Re: Exception when opening Document-settings on Solaris
Pavel Sanda wrote: even if this change helps for solaris i fear many crashes on systems with strangely set locales. the changeset should be reverted back until we know how safely detect the error. FWIW, I agree. Jürgen
Re: Exception when opening Document-settings on Solaris
Pavel Sanda wrote: On Thursday 12 July 2007 10:41:25 Enrico Forestieri wrote: This one would also catch MSVC, which AFAIK has no problem with the locale sorting. OK. You can commit the change. even if this change helps for solaris i fear many crashes on systems with strangely set locales. the changeset should be reverted back until we know how safely detect the error. btw have anybody better solution than handling the exception ? What do you mean by handling the exception? Fallback to the non wchar_t solution if an exception is caught? For this to work the choice of using wchar_t or not must be done at run-time; unfortunately the source code is really not ready to do that now (lots of #ifdef). Abdel.
Re: Open Patches
On Thursday 12 July 2007 11:30:29 Abdelrazak Younes wrote: José Matos wrote: On Wednesday 11 July 2007 17:51:44 Michael Gerz wrote: and the Windows font patch are not committed. Any news on this from Joost or Uwe? Author: forenr Date: Wed Jul 11 13:57:58 2007 New Revision: 19038 URL: http://www.lyx.org/trac/changeset/19038 Log: Fix bug 3962 (by me, Peter, and Joost) * src/support/os_cygwin.cpp * src/support/os_win32.cpp (addFontResources): use AddFontResourceEx on Windows version supporting this API in order to mark our fonts as private. (restoreFontResources): ditto with RemoveFontResourceEx. Good. :-) Now my only concerns are lyx2lyx bugs and Dov 1820's. :-) -- José Abílio
Re: [patch] Re: UTF-8 and layouts - bugs
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes:
You mean, pass information to Font::latexWriteStartChanges that the character
following the font change will be a blank? That could be doable.
It is even simpler than that.
JMarc
Index: src/Paragraph.cpp
===
--- src/Paragraph.cpp (révision 19050)
+++ src/Paragraph.cpp (copie de travail)
@@ -67,6 +67,7 @@ using std::ostream;
namespace lyx {
using support::contains;
+using support::suffixIs;
using support::rsplit;
@@ -2076,11 +2077,19 @@ bool Paragraph::simpleTeXOnePar(Buffer c
font.language() != running_font.language())
i != body_pos - 1)
{
- column += font.latexWriteStartChanges(os, bparams,
+ odocstringstream ods;
+ column += font.latexWriteStartChanges(ods, bparams,
runparams, basefont,
last_font);
running_font = font;
open_font = true;
+ docstring fontchange = ods.str();
+ // check if the fontchange ends with a trailing blank
+ if (suffixIs(fontchange, 0x0020) c == ' ')
+os fontchange.substr(0, fontchange.size() - 1)
+from_ascii({});
+ else
+os fontchange;
}
if (c == ' ') {
Re: Slow motion while editing
but I cannot reproduce it. can you try this ? 1. launch lyx 2. new file + some typing + mark text + copy 3. launch new instance (let the old one running) + new + type some text + try motion just one more addition: - the slow motion is only in one of those two windows - the other one, than the one where Ctrl+C was done. i can even play with switching which window will be the slow one by Ctrl+C. pavel
Re: [patch] Re: UTF-8 and layouts - bugs
Jürgen Spitzmüller wrote:
No, I meant output rhe {} only when there are two consecutive blanks.
You mean, pass information to Font::latexWriteStartChanges that the
character following the font change will be a blank? That could be doable.
As in the attached? This looks like a pretty safe approach to me.
Jürgen
Index: src/Font.cpp
===
--- src/Font.cpp (Revision 19033)
+++ src/Font.cpp (Arbeitskopie)
@@ -743,7 +743,7 @@
int Font::latexWriteStartChanges(odocstream os, BufferParams const bparams,
OutputParams const runparams,
Font const base,
-Font const prev) const
+Font const prev, bool blank_follows) const
{
bool env = false;
@@ -803,8 +803,13 @@
if (number() == ON prev.number() != ON
(language()-lang() == hebrew
|| language()-lang() == farsi)) {
- os {\\beginL ;
- count += 9;
+ if (blank_follows) {
+ os {\\beginL{};
+ count += 10;
+ } else {
+ os {\\beginL ;
+ count += 9;
+ }
}
Font f = *this;
@@ -861,9 +866,14 @@
++count;
}
os '\\'
- LaTeXSizeNames[f.size()]
- ' ';
- count += strlen(LaTeXSizeNames[f.size()]) + 2;
+ LaTeXSizeNames[f.size()];
+ if (blank_follows) {
+ os {};
+ count += strlen(LaTeXSizeNames[f.size()]) + 3;
+ } else {
+ os ' ';
+ count += strlen(LaTeXSizeNames[f.size()]) + 2;
+ }
}
return count;
}
Index: src/Font.h
===
--- src/Font.h (Revision 19033)
+++ src/Font.h (Arbeitskopie)
@@ -300,7 +300,8 @@
int latexWriteStartChanges(odocstream , BufferParams const bparams,
OutputParams const runparams,
Font const base,
- Font const prev) const;
+ Font const prev,
+ bool blank_follows) const;
/** Writes the tail of the LaTeX needed to change to this font.
Returns number of chars written. Base is the font state we want
Index: src/Paragraph.cpp
===
--- src/Paragraph.cpp (Revision 19033)
+++ src/Paragraph.cpp (Arbeitskopie)
@@ -2070,9 +2070,12 @@
font.language() != running_font.language())
i != body_pos - 1)
{
+ bool blank_follows = false;
+ if (c == ' ')
+blank_follows = true;
column += font.latexWriteStartChanges(os, bparams,
runparams, basefont,
- last_font);
+ last_font, blank_follows);
running_font = font;
open_font = true;
}
Re: [patch] Re: UTF-8 and layouts - bugs
Jean-Marc Lasgouttes wrote: It is even simpler than that. Sight. So which one should we take? I think either one is ok. Yours is probably simpler. I'll let you and José decide. Jürgen
Re: Exception when opening Document-settings on Solaris
What do you mean by handling the exception? Fallback to the non wchar_t yes solution if an exception is caught? For this to work the choice of using wchar_t or not must be done at run-time; unfortunately the source code is really not ready to do that now (lots of #ifdef). wont be possible to avoid any ifdefs by doing something like : try locale stuff (init+sort); catch any_error: do non_locale stuff ? (i'm not much familiar with exceptions, maybe just talking nonsense.) pavel
Re: [patch] Re: UTF-8 and layouts - bugs
On Thursday 12 July 2007 11:54:39 Jürgen Spitzmüller wrote: Sight. So which one should we take? I think either one is ok. Yours is probably simpler. I'll let you and José decide. If you agree on one of the versions you have my OK. As you see I am learning. Now instead of throwing a coin I expect you to do so. ;-) Jürgen -- José Abílio
Re: [patch] Re: UTF-8 and layouts - bugs
Jürgen Spitzmüller wrote: So which one should we take? I think either one is ok. Yours is probably simpler. I'll let you and José decide. On a second thought, I think you should just commit yours. José? Jürgen
Re: Exception when opening Document-settings on Solaris
On Thu, Jul 12, 2007 at 12:54:39PM +0200, Pavel Sanda wrote: wont be possible to avoid any ifdefs by doing something like : try locale stuff (init+sort); catch any_error: do non_locale stuff Note that this is used in a sorting context, so the comparison should be as fast as possible. I don't think that the try/catch game fits the bill here. -- Enrico
Re: [patch] Re: UTF-8 and layouts - bugs
Jürgen Spitzmüller wrote: On a second thought, I think you should just commit yours I also think this should be ported back to 1.4. Jürgen
Re: listings improvement
Bo Peng wrote: Make external file an option under listings insert would be more intuitive. Do you mean menu items insert - program listing program file listing or something in the listings - right click dialog? The latter is difficult because file listings is not an option of a normal listing (which contains code, caption etc) and you can not somehow convert a listings inset to file listing. Bo Yes, I do mean the latter. It's just like a printer dialog: choose print to device or print to file. If this is hard to implement, then in the interim can we just put some text on this dialog that points the user to the insert child doc?
Re: [patch] Re: UTF-8 and layouts - bugs
On Thursday 12 July 2007 12:00:14 Jürgen Spitzmüller wrote: On a second thought, I think you should just commit yours. José? Jürgen As I said before if you agree on one version, as it seems to be case, you have my OK. -- José Abílio
Re: Exception when opening Document-settings on Solaris
Note that this is used in a sorting context, so the comparison should be as fast as possible. I don't think that the try/catch we are sorting some ~50 items. anyway it can be written that try block is entered only once per one sorting. pavel
Re: Slow motion while editing
On Thu, 2007-07-12 at 12:18 +0200, Pavel Sanda wrote: But what I accidentally found is, that the whole problem simply disappears in the moment I copy and paste some text. Is this known ? Does it resemble this? does copying text by Ctrl+C helps for you ? Not that I know of. i was trying to resize the window in many ways but havent succeeded, the problem remains. seems to be different issue. Then maybe it's time to file a bug report. moreover that while i was playing few minutes only with resizing i came to new displaying problem which resembles http://bugzilla.lyx.org/show_bug.cgi?id=3231 sometimes only paragraph of cursor is visible - but in this case even the current paragraph was not visible and you have to move cursor to make That's a common part of the bug. The current paragraph sometimes isn't visible either. it appear. it does not happen always but usually when you resize the window to some very small area - say one word width, three lines height and then you resize it back (or maximize). more - the slider on the right side is often in a position, which cannot be reached again and its size is different after you move with cursor and screen gets repainted. This bug was supposed to be fixed, so perhaps it's time to re-open it. Please add your comments to the bug. Have fun, Darren
Re: Slow motion while editing
Pavel Sanda wrote: but I cannot reproduce it. can you try this ? 1. launch lyx 2. new file + some typing + mark text + copy 3. launch new instance (let the old one running) + new + type some text + try motion just one more addition: - the slow motion is only in one of those two windows - the other one, than the one where Ctrl+C was done. i can even play with switching which window will be the slow one by Ctrl+C. By the way, you know that LyX now can do multiple views, don't you? Can you reproduce the slow motion with two windows of the same instance? Abdel.
Re: Slow motion while editing
By the way, you know that LyX now can do multiple views, don't you? Can you reproduce the slow motion with two windows of the same instance? no, i can not reproduce it on the same instance. pavel
Re: [patch] Re: UTF-8 and layouts - bugs
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: On a second thought, I think you should just commit yours. Yes, it is IMO simpler. Note that this would be moot if we had the latexstream I've been dreaming about for ages :) JMarc
Re: [patch] Re: UTF-8 and layouts - bugs
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: I also think this should be ported back to 1.4. No, the bug does not exist in 1.4, where spaces are kept outside of font changes. JMarc
Re: [patch] Re: UTF-8 and layouts - bugs
Jean-Marc Lasgouttes wrote: Yes, it is IMO simpler. Note that this would be moot if we had the latexstream I've been dreaming about for ages :) Like the one you'll give us in Bromarv? ;-) A/
Re: Slow motion while editing
Pavel Sanda wrote: By the way, you know that LyX now can do multiple views, don't you? Can you reproduce the slow motion with two windows of the same instance? no, i can not reproduce it on the same instance. At last a good news :-) Maybe it is a problem of Qt then. I don't know how Qt handle the clipboard but as two instance of LyX uses the same instance of Qt (unless you compiled statically) there might be some interaction problem between the two instances. This is just wild guessing... Anyway, at least you have a work-around for your problem now ;-) Abdel.
Re: Slow motion while editing
By the way, you know that LyX now can do multiple views, don't you? Can you reproduce the slow motion with two windows of the same instance? Abdel. btw abdel, if you want i can provide you ssh account on the machine to fathom this. pavel
Re: Slow motion while editing
Pavel Sanda wrote: Which sytem is that? If it is KDE or GNOME based, maybe there's some global Clipboard or X11 Selection issue... could you please try to launch a bare X11 session with a minimalist window manager (i.e. without KDE nor Gnome) and report back? i use only enlightenment 0.16. is it minimalistic enough ? I don't know... enlightenment is a kind of desktop too, isn't it? Maybe there's some bad interactions with the clipboard... I've been using Windows for the last 6 years so I am probably talking nonsense here. ok, i run X without any WM or desktop and came to this - it _seems_ (its difficult to test extensively as you cant switch between windows without WM :) that motion itself is much better, but what remains is extremely slow motion when selecting text with shift+arrows - previously i considered that this slowness is just consequence of the motion itself but now it seems to be issue itself. pavel
Re: [patch] Re: UTF-8 and layouts - bugs
Alfredo Braunstein [EMAIL PROTECTED] writes: Jean-Marc Lasgouttes wrote: Yes, it is IMO simpler. Note that this would be moot if we had the latexstream I've been dreaming about for ages :) Like the one you'll give us in Bromarv? ;-) I have other plans, but we'll see :) JMarc
[patch] bug 4011: Import of CJK-LyX files leads to crash if they have extension .lyx
http://bugzilla.lyx.org/show_bug.cgi?id=4011
The crash is due to an invalid pointer: when importing with indentical input
and output file names, Converter tries to create a temporary output file in
the temp dir, but since no buffer exists yet, buffer-tempdir() is invalid.
So the patch uses the directory dir in this case.
OK?
Jürgen
Index: src/Converter.cpp
===
--- src/Converter.cpp (Revision 19033)
+++ src/Converter.cpp (Arbeitskopie)
@@ -379,7 +379,11 @@
FileName real_outfile;
if (outfile == infile) {
real_outfile = infile;
- outfile = FileName(addName(buffer-temppath(), tmpfile.out));
+ // when importing, a buffer does not necessarily exist
+ if (buffer)
+outfile = FileName(addName(buffer-temppath(), tmpfile.out));
+ else
+outfile = FileName(addName(path, tmpfile.out));
}
if (conv.latex) {
Re: [patch] Re: UTF-8 and layouts - bugs
Jean-Marc Lasgouttes wrote: I have other plans, but we'll see :) Break some eggs perhaps? ;-) Jürgen
Re: [patch] bug 4011: Import of CJK-LyX files leads to crash if they have extension .lyx
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: http://bugzilla.lyx.org/show_bug.cgi?id=4011 The crash is due to an invalid pointer: when importing with indentical input and output file names, Converter tries to create a temporary output file in the temp dir, but since no buffer exists yet, buffer-tempdir() is invalid. So the patch uses the directory dir in this case. Why not use package().temp_dir().absFilename() instead? (Just asking) JMarc
Re: [patch] bug 4011: Import of CJK-LyX files leads to crash if they have extension .lyx
Jean-Marc Lasgouttes wrote: So the patch uses the directory dir in this case. Why not use package().temp_dir().absFilename() instead? It didn't came to my mind. I can do that, if you prefer. Jürgen
Re: Slow motion while editing
Pavel Sanda wrote: By the way, you know that LyX now can do multiple views, don't you? Can you reproduce the slow motion with two windows of the same instance? Abdel. btw abdel, if you want i can provide you ssh account on the machine to fathom this. I would need an X11 server to do that and more time to setup everything and debug it than I can really afford. So, thanks but no, I think your problem is not worth it, no offense ;-) Abdel.
Re: Slow motion while editing
Pavel Sanda wrote: Pavel Sanda wrote: Which sytem is that? If it is KDE or GNOME based, maybe there's some global Clipboard or X11 Selection issue... could you please try to launch a bare X11 session with a minimalist window manager (i.e. without KDE nor Gnome) and report back? i use only enlightenment 0.16. is it minimalistic enough ? I don't know... enlightenment is a kind of desktop too, isn't it? Maybe there's some bad interactions with the clipboard... I've been using Windows for the last 6 years so I am probably talking nonsense here. ok, i run X without any WM or desktop and came to this - it _seems_ (its difficult to test extensively as you cant switch between windows without WM :) that motion itself is much better, but what remains is extremely slow motion when selecting text with shift+arrows Even with a single instance? Following our recent cleanup in this area, there should not be any buffering done at selection time, only at clearing selection time. Still, LyX request the X11 selection handle upon each selection operation (such as selecting text with shift+arrows); requesting the X11 selection is not supposed to be costly at all so I am tending to think that maybe you X server is buggy. You could try to upgrade it and see how it goes. - previously i considered that this slowness is just consequence of the motion itself but now it seems to be issue itself. Looks like yes. Abdel.
Re: Slow motion while editing
ok, i run X without any WM or desktop and came to this - it _seems_ (its difficult to test extensively as you cant switch between windows without WM :) that motion itself is much better, but what remains is extremely slow motion when selecting text with shift+arrows Even with a single instance? no. i run first instance, copy text. then the second - and in this second slowness happens. i just cant switch to the previous one to make more experiments. pavel
Re: Slow motion while editing
On Thu, 12 Jul 2007 14:11:33 +0200 Pavel Sanda [EMAIL PROTECTED] wrote: Pavel Sanda wrote: Which sytem is that? If it is KDE or GNOME based, maybe there's some global Clipboard or X11 Selection issue... could you please try to launch a bare X11 session with a minimalist window manager (i.e. without KDE nor Gnome) and report back? i use only enlightenment 0.16. is it minimalistic enough ? I don't know... enlightenment is a kind of desktop too, isn't it? Maybe there's some bad interactions with the clipboard... I've been using Windows for the last 6 years so I am probably talking nonsense here. ok, i run X without any WM or desktop and came to this - it _seems_ (its difficult to test extensively as you cant switch between windows without WM :) that motion itself is much better, but what remains is extremely slow motion when selecting text with shift+arrows - previously i considered that this slowness is just consequence of the motion itself but now it seems to be issue itself. This rings a bell... some of the SinglePar optimizations are not used when selecting. (Is my old work on this stuff still in the code? If not, ignore me.) - Martin
Re: [patch] Re: UTF-8 and layouts - bugs
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: Jean-Marc Lasgouttes wrote: I have other plans, but we'll see :) Break some eggs perhaps? ;-) Yes. It is not fair to see always the same people having fun (what about replacing qt4 with Xaw?) JMarc
Re: [patch] bug 4011: Import of CJK-LyX files leads to crash if they have extension .lyx
Jürgen Spitzmüller wrote: Jean-Marc Lasgouttes wrote: So the patch uses the directory dir in this case. Why not use package().temp_dir().absFilename() instead? It didn't came to my mind. I can do that, if you prefer. Would be better IMHO. Abdel.
Re: [patch] Re: UTF-8 and layouts - bugs
Jean-Marc Lasgouttes wrote: Yes. It is not fair to see always the same people having fun (what about replacing qt4 with Xaw?) Or just ditch Unix and use the Windows API. Jürgen
Re: [patch] bug 4011: Import of CJK-LyX files leads to crash if they have extension .lyx
Abdelrazak Younes wrote:
It didn't came to my mind.
I can do that, if you prefer.
Would be better IMHO.
OK. Attached.
José, OK to go in?
Jürgen
Index: src/Converter.cpp
===
--- src/Converter.cpp (Revision 19055)
+++ src/Converter.cpp (Arbeitskopie)
@@ -29,6 +29,7 @@
#include support/filetools.h
#include support/lyxlib.h
#include support/os.h
+#include support/Package.h
#include support/Path.h
#include support/Systemcall.h
@@ -50,6 +51,7 @@
using support::makeRelPath;
using support::onlyFilename;
using support::onlyPath;
+using support::package;
using support::prefixIs;
using support::quoteName;
using support::removeExtension;
@@ -379,7 +381,12 @@
FileName real_outfile;
if (outfile == infile) {
real_outfile = infile;
- outfile = FileName(addName(buffer-temppath(), tmpfile.out));
+ // when importing, a buffer does not necessarily exist
+ if (buffer)
+outfile = FileName(addName(buffer-temppath(), tmpfile.out));
+ else
+outfile = FileName(addName(package().temp_dir().absFilename(),
+ tmpfile.out));
}
if (conv.latex) {
Re: [patch] bug 4011: Import of CJK-LyX files leads to crash if they have extension .lyx
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: Jean-Marc Lasgouttes wrote: So the patch uses the directory dir in this case. Why not use package().temp_dir().absFilename() instead? It didn't came to my mind. I can do that, if you prefer. It looks better. JMarc
Re: [patch] Re: UTF-8 and layouts - bugs
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: Jean-Marc Lasgouttes wrote: Yes. It is not fair to see always the same people having fun (what about replacing qt4 with Xaw?) Or just ditch Unix and use the Windows API. Java? JMarc
Re: Slow motion while editing
it appear. it does not happen always but usually when you resize the window to some very small area - say one word width, three lines height and then you resize it back (or maximize). more - the slider on the right side is often in a position, which cannot be reached again and its size is different after you move with cursor and screen gets repainted. This bug was supposed to be fixed, so perhaps it's time to re-open it. Please add your comments to the bug. please do you know the number ? i remember there was also some bug about positioning view to the last half-line of text after opening a file, which also happened when resizing now, but was not able to find it in bugz. pavel
Re: [patch] Re: UTF-8 and layouts - bugs
Jean-Marc Lasgouttes wrote: [EMAIL PROTECTED] (Jürgen Spitzmüller) writes: Jean-Marc Lasgouttes wrote: Yes. It is not fair to see always the same people having fun (what about replacing qt4 with Xaw?) Or just ditch Unix and use the Windows API. Java? Ajax Abdel.
Re: [patch] Re: UTF-8 and layouts - bugs
Abdelrazak Younes [EMAIL PROTECTED] writes: Ajax Basix (http://www.tex.ac.uk/tex-archive/help/Catalogue/entries/basix.html) JMarc
Re: Slow motion while editing
On Thu, 2007-07-12 at 15:01 +0200, Pavel Sanda wrote: This bug was supposed to be fixed, so perhaps it's time to re-open it. Please add your comments to the bug. please do you know the number ? i remember there was also some bug about positioning view to the last half-line of text after opening a file, which also happened when resizing now, but was not able to find it in bugz. It was sitting right in front of you in the message you were replying to :) In the part which you wrote yourself :P moreover that while i was playing few minutes only with resizing i came to new displaying problem which resembles http://bugzilla.lyx.org/show_bug.cgi?id=3231 sometimes only paragraph of cursor is visible - but in this case even the current paragraph was not visible and you have to move cursor to make Have fun, Darren
Re: [patch] bug 4011: Import of CJK-LyX files leads to crash if they have extension .lyx
Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: It didn't came to my mind. I can do that, if you prefer. Would be better IMHO. OK. Attached. José, OK to go in? Jürgen Is it possible to change Files of type: in UI from *.cjklyx to *.lyx? CJK-LyX's files have extension *.lyx, so it may be better for existing users. Koji --- lib/configure.py.orig Thu Jul 12 22:14:54 2007 +++ lib/configure.pyThu Jul 12 22:14:54 2007 @@ -301,9 +301,9 @@ \Format lyxlyx LyX \Format lyx13x lyx13 LyX 1.3.x document \Format lyx14x lyx14 LyX 1.4.x document -\Format clyx cjklyx CJK LyX 1.4.x (big5) document -\Format jlyx cjklyx CJK LyX 1.4.x (euc-jp) document -\Format klyx cjklyx CJK LyX 1.4.x (euc-kr) document +\Format clyx lyx CJK LyX 1.4.x (big5)document +\Format jlyx lyx CJK LyX 1.4.x (euc-jp) document +\Format klyx lyx CJK LyX 1.4.x (euc-kr) document \Format lyxpreview lyxpreview LyX Preview \Format pdftex pdftex_t PDFTEX \Format program Program
Re: Slow motion while editing
On Thu, 2007-07-12 at 15:01 +0200, Pavel Sanda wrote: This bug was supposed to be fixed, so perhaps it's time to re-open it. Please add your comments to the bug. please do you know the number ? i remember there was also some bug about positioning view to the last half-line of text after opening a file, which also happened when resizing now, but was not able to find it in bugz. It was sitting right in front of you in the message you were replying to :) In the part which you wrote yourself :P i thought you point to some bug which address the wrong scrollbar (i wrongly spelled it slider). pavel
Re: [patch] Re: UTF-8 and layouts - bugs
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Jürgen Spitzmüller) writes: You mean, pass information to Font::latexWriteStartChanges that the character following the font change will be a blank? That could be doable. It is even simpler than that. I appled this patch. JMarc
Re: [PATCH] some build improvements for the mac
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: OK, then here is the patch that I propose to apply. What it does: I applied this patch. JMarc
Re: Towards LyX 1.4.5 [status update #1]
Jean-Pierre Chrétien [EMAIL PROTECTED] writes: beamer.layout is not up do date compared to 1.5.version (see attachment http://bugzilla.lyx.org/attachment.cgi?id=1626action=view to bug 3141). I applied the patch. JMarc
Re: [patch] bug 4011: Import of CJK-LyX files leads to crash if they have extension .lyx
Koji Yokota wrote: Is it possible to change Files of type: in UI from *.cjklyx to *.lyx? CJK-LyX's files have extension *.lyx, so it may be better for existing users. The problem, I think, is that this will overwrite existing files on export. It's similar to bug 3934 and should be fixed in line with that: http://bugzilla.lyx.org/show_bug.cgi?id=3934 Jürgen
Re: Towards LyX 1.4.5 [status update #1]
On Thu, Jul 12, 2007 at 03:50:40PM +0200, Jean-Marc Lasgouttes wrote:
Jean-Pierre Chrétien [EMAIL PROTECTED] writes:
beamer.layout is not up do date compared to 1.5.version
(see attachment http://bugzilla.lyx.org/attachment.cgi?id=1626action=view
to bug 3141).
I applied the patch.
What about the \overset patch by André? It is needed in 1.4, too.
Try \overset{s_1}{=} and you will see it.
--
Enrico
Index: src/mathed/math_oversetinset.C
===
--- src/mathed/math_oversetinset.C (revisione 19058)
+++ src/mathed/math_oversetinset.C (copia locale)
@@ -43,7 +43,7 @@
void MathOversetInset::draw(PainterInfo pi, int x, int y) const
{
int m = x + width() / 2;
- int yo = y - cell(1).ascent() + cell(0).descent() - 1;
+ int yo = y - cell(1).ascent() - cell(0).descent() - 1;
cell(1).draw(pi, m - cell(1).width() / 2, y);
FracChanger dummy(pi.base);
cell(0).draw(pi, m - cell(0).width() / 2, yo);
Re: Arrival/departure dates for Bromarv?
Andre Poenitz [EMAIL PROTECTED] writes: All on thursday 9th? Then perhaps we should just pick you up by car. I'll talk to the CEO about it ;-) Would be nice. Or even great! We have bedlinen and towels and all... but do bring as many laptops as you can, with ethernet cables / wireless cards, and a spare hub or ADSL modem if you have one. In theory I have a ADSL modem, but not exactly a 'spare' one. I can bring a hub, and of course my laptop. JMarc
Re: Towards LyX 1.4.5 [status update #2]
Jean-Marc Lasgouttes wrote: This means that either Jose or Juergen will have to do it (they have all the information to put things on our ftp sites now). Actually, I do not have any information about the release procedure yet. But with a little help from José, it might be doable. Jürgen
Re: Towards LyX 1.4.5 [status update #1]
Enrico Forestieri wrote:
On Thu, Jul 12, 2007 at 03:50:40PM +0200, Jean-Marc Lasgouttes wrote:
Jean-Pierre Chrétien [EMAIL PROTECTED] writes:
beamer.layout is not up do date compared to 1.5.version
(see attachment http://bugzilla.lyx.org/attachment.cgi?id=1626action=view
to bug 3141).
I applied the patch.
What about the \overset patch by André? It is needed in 1.4, too.
Try \overset{s_1}{=} and you will see it.
It has been OKed by Jose already (on the user list :0)). Could you
commit it please?
Abdel.
Re: Towards LyX 1.4.5 [status update #1]
Enrico Forestieri [EMAIL PROTECTED] writes:
What about the \overset patch by André? It is needed in 1.4, too.
Try \overset{s_1}{=} and you will see it.
I did not realize that it is needed. I just applied it.
JMarc
Re: Towards LyX 1.4.5 [status update #2]
Jean-Marc Lasgouttes wrote: Hello, It transpires that, since I am leaving for vacation this evening, I will not be able to release LyX 1.4.5 (I come back on 31/07). This means that either Jose or Juergen will have to do it (they have all the information to put things on our ftp sites now). The only remaining bugs are: 2958Backport lyx2lyx from trunk to the last 1.4.x version waiting for Jose :) Isn't it just a matter of copying the lyx2lyx directory from trunk to 1.4? At least that's what Jose said about this on the user list. In which case, you can probably do it yourself and release 1.4.5 now as there won't be any format change before 1.5.0. Just MHO, Abdel.
Re: Towards LyX 1.4.5 [status update #2]
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: Actually, I do not have any information about the release procedure yet. But with a little help from José, it might be doable. I trust it will be :) JMarc
Re: Towards LyX 1.4.5 [status update #2]
Abdelrazak Younes [EMAIL PROTECTED] writes: Isn't it just a matter of copying the lyx2lyx directory from trunk to 1.4? At least that's what Jose said about this on the user list. In which case, you can probably do it yourself and release 1.4.5 now as there won't be any format change before 1.5.0. I guess there are a few things to tweak (so that lyx2lyx produces the right format by default, for example?), and I have to leave in one hour. Morever there are still some bugs to fix in lyx2lyx (this is why 1.5.0 is not out actually). JMarc
Re: Towards LyX 1.4.5 [status update #1]
Abdelrazak Younes [EMAIL PROTECTED] writes: It has been OKed by Jose already (on the user list :0)). Could you commit it please? I thought it was already in 1.5. I committed it there too. JMarc
