Re: How to make Lyx DRAMATICALLY better.
On Tue, Jun 05, 2007 at 04:46:56PM -0500, Bo Peng wrote: Please, no changing colours, no special effects, no eye candies... These things may be easier to implement but are very annoying. Please test the patch I proposed (the newer version), along with the problems I described. Actually, I tested it. As I had changed the background colours, I saw flashing colours all around when I moved the cursor over a math inset. I also don't like having the markers highlighted. There are better methods to achieve the wanted result, only they are not cheap, maybe. But this makes the difference between an excellent software and a passable one... -- Enrico
Re: How to make Lyx DRAMATICALLY better.
On Tue, Jun 05, 2007 at 05:05:05PM -0500, Bo Peng wrote: Actually, I tested it. As I had changed the background colours, I saw flashing colours all around when I moved the cursor over a math inset. mathbg and mathhoverbg are the same as background. If you set them to flashing colors, that is your problem. No, you are making my problems ;-) When I want to change background I have to take into account mathhoverbg, too. Please, remove that. The only change to the default behavior is the showing of corners, which can hardly be called flashing. Yes, if you remove mathhoverbg, that would be true. -- Enrico
Re: [PATCH] Change default mathbg and add mathhoverbg.
On Wed, Jun 06, 2007 at 12:07:05AM +0200, Jean-Marc Lasgouttes wrote: Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico On Tue, Jun 05, 2007 at 11:37:48PM +0200, Jean-Marc Lasgouttes Enrico wrote: Bo == Bo Peng [EMAIL PROTECTED] writes: Bo I can not imagine anything else you might want to experiment in Bo 1.6.0. Get rid of the corners and use background instead in order to avoid those extra blank pixels? Enrico What when insets are nested? Are you proposing to use a Enrico different colour for each nested inset? Nah... Only change the color of the deepest inset. So, there would be no difference in simply showing the corners of the deepest inset. Enrico What about my suggestion in the other thread? I'd have to install texmacs to understand it. You don't need to. Simply draw the corners of the active inset without reserving space for them. If you are leaving an inset using arrow left or right and this inset is nested in another inset, show the corners of the new inset but don't move the cursor. When leaving an inset with arrow left/right, you actually move the cursor only if there is no containing inset. Even if the cursor is not moved, it logically belongs to an inset or another. Which one you can tell by looking at the status line. -- Enrico
Re: How to make Lyx DRAMATICALLY better.
On Tue, Jun 05, 2007 at 05:17:20PM -0500, Bo Peng wrote: No, you are making my problems ;-) When I want to change background I have to take into account mathhoverbg, too. Please, remove that. This part is true, but the same goes to buttonbg and buttonhoverbg. Seems that you are making me a lot of problems ;-) Yes, if you remove mathhoverbg, that would be true. So the defaults should fit your taste. None so deaf as those that will not hear ;-) -- Enrico
Re: [PATCH] Change default mathbg and add mathhoverbg.
On Wed, Jun 06, 2007 at 12:28:54AM +0200, Andre Poenitz wrote: On Tue, Jun 05, 2007 at 11:48:25PM +0200, Enrico Forestieri wrote: On Tue, Jun 05, 2007 at 11:37:48PM +0200, Jean-Marc Lasgouttes wrote: Bo == Bo Peng [EMAIL PROTECTED] writes: Bo I can not imagine anything else you might want to experiment in Bo 1.6.0. Get rid of the corners and use background instead in order to avoid those extra blank pixels? What when insets are nested? Are you proposing to use a different colour for each nested inset? Nah... I think it might be sufficient do color the innermost inset still containing the cursor. As I already said, what is the difference with respect to simply showing the corners without reserving space for them? Nevertheless we'd lose visual information this way, as right now we also see the nesting leading to the cursor position which _I_ find rather helpful (otherwise there weren't these cure l'll corners anyway...) You can get that info by looking at the status line. -- Enrico
Re: [PATCH] Change default mathbg and add mathhoverbg.
On Wed, Jun 06, 2007 at 12:38:08AM +0200, Andre Poenitz wrote: On Wed, Jun 06, 2007 at 12:23:27AM +0200, Enrico Forestieri wrote: On Wed, Jun 06, 2007 at 12:07:05AM +0200, Jean-Marc Lasgouttes wrote: Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico On Tue, Jun 05, 2007 at 11:37:48PM +0200, Jean-Marc Lasgouttes Enrico wrote: Bo == Bo Peng [EMAIL PROTECTED] writes: Bo I can not imagine anything else you might want to experiment in Bo 1.6.0. Get rid of the corners and use background instead in order to avoid those extra blank pixels? Enrico What when insets are nested? Are you proposing to use a Enrico different colour for each nested inset? Nah... Only change the color of the deepest inset. So, there would be no difference in simply showing the corners of the deepest inset. Enrico What about my suggestion in the other thread? I'd have to install texmacs to understand it. You don't need to. Simply draw the corners of the active inset without reserving space for them. I tried that a while ago and this is no good as the corners cover part of the content, especially if you have a small font. Well, you can't eat your cake and still have it... We have to decide what is worse. The current behavior has been there for ages, and the only problem is that one could miss a missing space after a math inset. I think that I can live with this limitation, but suddenly it becomes something so vital that it is preferable turning the LyX screen into a Christmas tree (thanks for this definition meant for effect, Edwin :) If you are leaving an inset using arrow left or right and this inset is nested in another inset, show the corners of the new inset but don't move the cursor. When leaving an inset with arrow left/right, you actually move the cursor only if there is no containing inset. Even if the cursor is not moved, it logically belongs to an inset or another. Which one you can tell by looking at the status line. Status line is good for exact information, but when entering a complex formula one does not want to look on the formula, at the status line, at the formula, at the status line etc. Actually, this works quite well in texmacs, but I prefer the LyX way, too. However, if I have to decide between a Christmas tree and this last behavior, I don't have any doubt... I don't know if there's a bug open on this issue, but if there is one, I think that this one of those WONTFIX cases. -- Enrico
Re: [PATCH] Bug 3823 -- bad color output for LyXNotes
On Wed, Jun 06, 2007 at 08:53:36PM +0200, Juergen Spitzmueller wrote:
Herbert Voss wrote:
\providecolor{LyXshadecolor}{RGB}{...} to be save
BTW, Herbert, which definition is to be preferred to fix bug 3817:
http://bugzilla.lyx.org/show_bug.cgi?id=3817
\newcommand{\lyxadded}[3]{{\color{lyxadded}#3}}
\newcommand{\lyxdeleted}[3]{{\color{lyxdeleted}\st{#3}}}
or
\newcommand{\lyxadded}[3]{\bgroup\color{lyxadded}#3\egroup}
\newcommand{\lyxdeleted}[3]{\bgroup\color{lyxdeleted}\st{#3}\egroup}
I'm not Herbert, but I think I am able to answer this ;-)
Both forms are equivalent, indeed \bgroup and \egroup are defined
as \let\bgroup={ \let\egroup=} by TeX. The macro forms are useful
because you can include them in a definition without worrying
about how they nest. I mean that you can do something like:
\def\beginlarge{\bgroup\large}
\def\endlarge{\egroup}
after which you can use
xxx \beginlarge yyy \endlarge zzz
to typeset yyy in large size.
--
Enrico
Re: [PATCH] Hover over mathed show mathed corners.
On Wed, Jun 06, 2007 at 09:38:39AM -0500, Bo Peng wrote: I deem that this will be more acceptable than my previous patch. I was wrong so this is now http://bugzilla.lyx.org/show_bug.cgi?id=3825 . Maybe you will have more luck if you remove mathhoverbg from the patch ;-) -- Enrico
Re: Remembering settings in PS/PDF viewer
On Fri, Jun 08, 2007 at 12:39:54AM +1000, Darren Freeman wrote: I originally dropped generating DVI because it wouldn't print (xdvi sucks!). I disagree. Try compiling xdvi using --with-xdvi-x-toolkit=motif I attach here a screenshot I took on Solaris. -- Enrico attachment: xdvi.png
Re: [patch] bug 3510: make IEEEtran template compilable
On Sat, Jun 09, 2007 at 08:41:52AM +0200, Jürgen Spitzmüller wrote:
http://bugzilla.lyx.org/show_bug.cgi?id=3510
The problem is an interference of newer babel bundles with the way \markboth
is defined (if \markboth is defined after babel, babel somehow gets the
language in uppercase and complains about an unknown language ENGLISH).
The only solution I know (besides not calling babel) is to define \markboth
before babel, i.e. do not use the MarkBoth paragraph style (which is somewhat
awkward anyway) but define \markboth in preamble.
I did this in the template, which compiles again here. Looks like the
IEEEtran layout would need some overhaul in general, but I won't do that.
Sorry for stepping in so late, but I think that it is useful to directly
see on screen the info provided by MarkBoth. I had already solved the
bug but forgot to share the solution. Shame on me.
I propose to add the following to the preamble:
% Note: the following fixes a bug with older versions of babel
% http://www.latex-project.org/cgi-bin/ltxbugs2html?pr=babel/3238
\DeclareRobustCommand{\FOREIGNLANGUAGE}[1]{\lowercase{\foreignlanguage{#1}}}
% More recent babel versions already have the above definition, but introduce
% yet another related bug. Using these versions, when you change the language,
% you have to accordingly substitute both 'ENGLISH' and 'english' below.
[EMAIL PROTECTED]@english
See the attached sample .lyx file. A drawback is that when changing the
document language to something else than english, say american, one
has to update the above line to read
[EMAIL PROTECTED]@american
but maybe it is better than having to write the \markboth command
in the preamble.
I didn't try hard to find an automatic solution along the lines of the
\DeclareRobustCommand above, but I really don't have time to go
through the babel code. Maybe someone else could do it.
Josè, let me know if you prefer the solution above to having \markboth
in the preamble.
--
Enrico
#LyX 1.4.4 created this file. For more info see http://www.lyx.org/
\lyxformat 245
\begin_document
\begin_header
\textclass IEEEtran
\begin_preamble
% Note: the following fixes a bug with older versions of babel
% http://www.latex-project.org/cgi-bin/ltxbugs2html?pr=babel/3238
\DeclareRobustCommand{\FOREIGNLANGUAGE}[1]{\lowercase{\foreignlanguage{#1}}}
% More recent babel versions already have the above definition, but introduce
% yet another related bug. Using these versions, when you change the language,
% you have to accordingly substitute both 'ENGLISH' and 'english' below.
[EMAIL PROTECTED]@english
\end_preamble
\language english
\inputencoding default
\fontscheme default
\graphics default
\float_placement tbh
\paperfontsize default
\spacing single
\papersize default
\use_geometry false
\use_amsmath 0
\cite_engine basic
\use_bibtopic false
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\papercolumns 2
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\end_header
\begin_body
\begin_layout Title
Your Title: And maybe a bit extra
\end_layout
\begin_layout Author
\begin_inset Note Note
status collapsed
\begin_layout Standard
Remember that initial submissions don't show the authors
\end_layout
\begin_layout Standard
names so you'll need to make this a 'Comment'.
\end_layout
\end_inset
Your Name, Your Co-Author
\begin_inset Foot
status collapsed
\begin_layout Standard
Your name is with xyz Department\SpecialChar \ldots{}
\end_layout
\end_inset
\end_layout
\begin_layout Abstract
This paper presents a simple template for IEEEtran documents.
\end_layout
\begin_layout Keywords
simplicity, beauty, elegance
\end_layout
\begin_layout MarkBoth
This is for left pages
\begin_inset ERT
status collapsed
\begin_layout Standard
}{
\end_layout
\end_inset
and this is for right pages
\end_layout
\begin_layout Section
Introduction
\begin_inset Note Note
status collapsed
\begin_layout Standard
Don't panic the section numbering may look different in
\end_layout
\begin_layout Standard
LyX but LaTeX uses the correct Roman numerals and
\end_layout
\begin_layout Standard
Alpha for section counters.
\end_layout
\begin_layout Standard
It's just that LyX doesn't handle counters other than arabic
\end_layout
\begin_layout Standard
numerals.
\end_layout
\end_inset
\end_layout
\begin_layout Standard
\begin_inset ERT
status collapsed
\begin_layout Standard
\backslash
PARstart{T}{here}
\end_layout
\end_inset
is a need for a little Evil Red Text in the first paragraph.
Refer to the IEEEtran documentation (sample document) for more details.
\end_layout
\begin_layout Section
Previous Work
\end_layout
\begin_layout Standard
This is only a template remember.
\end_layout
\begin_layout Section
Methodology
\end_layout
\begin_layout Theorem
\begin_inset ERT
status collapsed
\begin_layout Standard
[
\end_layout
\end_inset
Theorem name
Re: [PATCH] Change default mathbg and add mathhoverbg.
On Mon, Jun 11, 2007 at 11:56:42AM -0500, Bo Peng wrote: Bo This feature does help the $x^2$is case. But if people really want to know what is happening, they have instant preview. With this on, there is no confusion IMO. I agree with you here. There is no additional pixels around previewed formulas. BTW, mouse hovering does not work for previewed formulas so it can not help the $\ $ cases. I can draw lyx formulas (instead of previewed ones) for mathed under mouse, if people are positive about this. Yes, please. I would also like to have red Sections, blue Subsections and everything else rapidly flashing when hovering. -- Enrico
Re: [patch] bug 3510: make IEEEtran template compilable
On Mon, Jun 11, 2007 at 06:57:07PM +0200, Jürgen Spitzmüller wrote: A general problem I see is the following: I assume (but I'm not sure) IEEETran.cls is mostly used by people who actually want to submit a LaTeX file to an IEEE journal. In this case it might be relevant that your solution produces a significantly uglier LaTeX file just for the sake of displaying MakeBoth on screen. I'm not sure if this is worth it. On second thoughts, I think I agree with you, even if one have nonetheless to edit the latex file in order to trim other things lyx puts in the preamble. If you think it is, then I suggest to add the preamble definitions to the MarkBoth definition in the layout file, so that it is only inserted if MarkBoth is actually used. And then document the pros and cons of both solutions, especially for people who want to submit their file to a journal. Well, either we remove the MarkBoth environment or actually add code to the preamble in order to avoid a latex failure when someone uses MarkBoth in the document without disabling babel. Also take into account the fact that one may have old files using the IEEEtran class with MarkBoth, and it is a real nuisance having to disable babel. I don't think removing MarkBoth is feasible without breaking those old documents (without a format change?), so maybe your solution could be complemented with mine but modified as you suggest, i.e., adding the preamble stuff to the MarkBoth definition in the layout file. In this way, using \markboth in the preamble is encouraged, but MarkBoth in the document is still possible. -- Enrico
Re: [patch] bug 3510: make IEEEtran template compilable
On Tue, Jun 12, 2007 at 06:29:03AM +0200, Jürgen Spitzmüller wrote:
Enrico Forestieri wrote:
Well, either we remove the MarkBoth environment or actually add code
to the preamble in order to avoid a latex failure when someone uses
MarkBoth in the document without disabling babel. Also take into account
the fact that one may have old files using the IEEEtran class with
MarkBoth, and it is a real nuisance having to disable babel.
I don't think removing MarkBoth is feasible without breaking those old
documents (without a format change?), so maybe your solution could be
complemented with mine but modified as you suggest, i.e., adding the
preamble stuff to the MarkBoth definition in the layout file.
I agree with all of this.
In this way, using \markboth in the preamble is encouraged, but MarkBoth
in the document is still possible.
Yes. Xo could you prepare a patch for the layout file? While you are at it,
you could add some OptArgs where needed.
Here is what I came up with. Given that the needed definitions for the
MarkBoth environment are in the layout file (so they are not accessible
by the user), I had to go through the babel code to find an automatic
workaround (luckily I found it almost immediately :).
Now no adjustments are needed when changing the language.
Note that if you use the MarkBoth environment and change the language
after a first View-DVI, you will get an error afterwards, due to the
.aux file still in effect. Simply do another View-DVI to get rid of it.
As regards the OptArgs, do you have something specific in mind?
--
Enrico
Index: lib/templates/IEEEtran.lyx
===
--- lib/templates/IEEEtran.lyx (revision 18750)
+++ lib/templates/IEEEtran.lyx (working copy)
@@ -44,25 +44,6 @@
\begin_body
-\begin_layout Standard
-\begin_inset Note Note
-status open
-
-\begin_layout Standard
-To specify the left and right header, go to
-\family sans
-Document\SpecialChar \menuseparator
-Settings\SpecialChar \menuseparator
-Preamble
-\family default
- and change the definition there.
-\end_layout
-
-\end_inset
-
-
-\end_layout
-
\begin_layout Title
Your Title: And maybe a bit extra
\end_layout
@@ -104,6 +85,66 @@ This paper presents a simple template fo
simplicity, beauty, elegance
\end_layout
+\begin_layout Standard
+\begin_inset Note Note
+status open
+
+\begin_layout Standard
+To specify the left and right header, go to
+\family sans
+Document\SpecialChar \menuseparator
+Settings\SpecialChar \menuseparator
+LaTeX Preamble
+\family default
+ and change the definition there.
+ You could also use the MarkBoth environment as shown in the note below,
+ but be warned that in this case the preamble will be cluttered by further
+ definitions, needed to workaround a babel bug.
+\end_layout
+
+\end_inset
+
+
+\end_layout
+
+\begin_layout Standard
+\begin_inset Note Note
+status collapsed
+
+\begin_layout Standard
+In order to use the MarkBoth environment, you have to separate left and
+ right pages material through
+\begin_inset Quotes eld
+\end_inset
+
+}{
+\begin_inset Quotes erd
+\end_inset
+
+ in ERT as follows:
+\end_layout
+
+\begin_layout Standard
+\align center
+This is for left pages
+\begin_inset ERT
+status collapsed
+
+\begin_layout Standard
+
+}{
+\end_layout
+
+\end_inset
+
+and this is for right pages
+\end_layout
+
+\end_inset
+
+
+\end_layout
+
\begin_layout Section
Introduction
\begin_inset Note Note
Index: lib/layouts/IEEEtran.layout
===
--- lib/layouts/IEEEtran.layout (revision 18750)
+++ lib/layouts/IEEEtran.layout (working copy)
@@ -466,6 +466,18 @@ Style MarkBoth
LaTeXName markboth
Align Center
AlignPossible Center
+ Preamble
+ % Note: the following fixes a bug with older versions of babel
+ % http://www.latex-project.org/cgi-bin/ltxbugs2html?pr=babel/3238
+ \DeclareRobustCommand{\FOREIGNLANGUAGE}[1]{%
+ \lowercase{\foreignlanguage{#1}}}
+ % More recent babel versions already have the above definition, but
+ % introduce yet another related bug, cured by the following workaround
+ [EMAIL PROTECTED]@language
+ [EMAIL PROTECTED]
+ [EMAIL PROTECTED]
+
+ EndPreamble
End
Re: [patch] bug 3510: make IEEEtran template compilable
On Tue, Jun 12, 2007 at 10:55:41PM +0200, Juergen Spitzmueller wrote:
Enrico Forestieri wrote:
As regards the OptArgs, do you have something specific in mind?
I just noticed an [ERT] OptArg in the template (author or something). There
might be others.
Yes, you're right. All theorem like environments accept an optional
argument. Updated patch attached.
--
Enrico
Index: lib/templates/IEEEtran.lyx
===
--- lib/templates/IEEEtran.lyx (revision 18750)
+++ lib/templates/IEEEtran.lyx (working copy)
@@ -44,25 +44,6 @@
\begin_body
-\begin_layout Standard
-\begin_inset Note Note
-status open
-
-\begin_layout Standard
-To specify the left and right header, go to
-\family sans
-Document\SpecialChar \menuseparator
-Settings\SpecialChar \menuseparator
-Preamble
-\family default
- and change the definition there.
-\end_layout
-
-\end_inset
-
-
-\end_layout
-
\begin_layout Title
Your Title: And maybe a bit extra
\end_layout
@@ -104,6 +85,66 @@ This paper presents a simple template fo
simplicity, beauty, elegance
\end_layout
+\begin_layout Standard
+\begin_inset Note Note
+status open
+
+\begin_layout Standard
+To specify the left and right header, go to
+\family sans
+Document\SpecialChar \menuseparator
+Settings\SpecialChar \menuseparator
+LaTeX Preamble
+\family default
+ and change the definition there.
+ You could also use the MarkBoth environment as shown in the note below,
+ but be warned that in this case the preamble will be cluttered by further
+ definitions, needed to workaround a babel bug.
+\end_layout
+
+\end_inset
+
+
+\end_layout
+
+\begin_layout Standard
+\begin_inset Note Note
+status collapsed
+
+\begin_layout Standard
+In order to use the MarkBoth environment, you have to separate left and
+ right pages material through
+\begin_inset Quotes eld
+\end_inset
+
+}{
+\begin_inset Quotes erd
+\end_inset
+
+ in ERT as follows:
+\end_layout
+
+\begin_layout Standard
+\align center
+This is for left pages
+\begin_inset ERT
+status collapsed
+
+\begin_layout Standard
+
+}{
+\end_layout
+
+\end_inset
+
+and this is for right pages
+\end_layout
+
+\end_inset
+
+
+\end_layout
+
\begin_layout Section
Introduction
\begin_inset Note Note
@@ -164,29 +205,22 @@ Methodology
\end_layout
\begin_layout Theorem
-\begin_inset ERT
+\begin_inset OptArg
status collapsed
\begin_layout Standard
-
-[
-\end_layout
-
-\end_inset
-
Theorem name
-\begin_inset ERT
-status collapsed
-
-\begin_layout Standard
-
-]
\end_layout
\end_inset
- For a named theorem or theorem-like environment you need to use a little
- evil red text (LaTeX mode) around the name.
+For a named theorem or theorem-like environment you need to insert the name
+ through
+\family sans
+Insert\SpecialChar \menuseparator
+Short Title
+\family default
+, as done here.
\end_layout
\begin_layout Lemma
Index: lib/layouts/IEEEtran.layout
===
--- lib/layouts/IEEEtran.layout (revision 18750)
+++ lib/layouts/IEEEtran.layout (working copy)
@@ -57,6 +57,7 @@ Style TheoremTemplate
LabelFont
Shape Italic
EndFont
+ OptionalArgs 1
End
@@ -466,6 +467,18 @@ Style MarkBoth
LaTeXName markboth
Align Center
AlignPossible Center
+ Preamble
+ % Note: the following fixes a bug with older versions of babel
+ % http://www.latex-project.org/cgi-bin/ltxbugs2html?pr=babel/3238
+ \DeclareRobustCommand{\FOREIGNLANGUAGE}[1]{%
+ \lowercase{\foreignlanguage{#1}}}
+ % More recent babel versions already have the above definition, but
+ % introduce yet another related bug, cured by the following workaround
+ [EMAIL PROTECTED]@language
+ [EMAIL PROTECTED]
+ [EMAIL PROTECTED]
+
+ EndPreamble
End
Re: [patch] bug 3510: make IEEEtran template compilable
On Wed, Jun 13, 2007 at 07:41:46AM +0200, Juergen Spitzmueller wrote: Enrico Forestieri wrote: Yes, you're right. All theorem like environments accept an optional argument. Updated patch attached. You should also probably update the Format of the layout (or put in the Format parameter, if it's not yet there). Apart from this, it looks good. A Format parameter is already there. It's Format 4 as everything else with the exception of simplecv.layout, which has Format 2. Is the Format parameter tagging a LyX release or the layout file itself? -- Enrico
Re: [patch] bug 3510: make IEEEtran template compilable
On Wed, Jun 13, 2007 at 09:47:44AM +0200, Jean-Marc Lasgouttes wrote:
Concerning the \markboth problem, what about the following simpler
approach? The only problem I could see is that hyphenation could be
incorrect in headings, but this looks like a useless feature to me.
Elementary, my dear Watson!
I think that you found the cleanest solution, Jean-Marc.
So, what about the attached?
--
Enrico
Index: lib/templates/IEEEtran.lyx
===
--- lib/templates/IEEEtran.lyx (revision 18756)
+++ lib/templates/IEEEtran.lyx (working copy)
@@ -3,11 +3,6 @@
\begin_document
\begin_header
\textclass IEEEtran
-\begin_preamble
-% The following definition specifies the text on the headers:
-% Use this instead of the MarkBoth paragraph style
-\markboth{This is for left pages}{and this is for right pages}
-\end_preamble
\language english
\inputencoding default
\font_roman default
@@ -44,25 +39,6 @@
\begin_body
-\begin_layout Standard
-\begin_inset Note Note
-status open
-
-\begin_layout Standard
-To specify the left and right header, go to
-\family sans
-Document\SpecialChar \menuseparator
-Settings\SpecialChar \menuseparator
-Preamble
-\family default
- and change the definition there.
-\end_layout
-
-\end_inset
-
-
-\end_layout
-
\begin_layout Title
Your Title: And maybe a bit extra
\end_layout
@@ -104,6 +80,21 @@ This paper presents a simple template fo
simplicity, beauty, elegance
\end_layout
+\begin_layout MarkBoth
+This is for left pages
+\begin_inset ERT
+status collapsed
+
+\begin_layout Standard
+
+}{
+\end_layout
+
+\end_inset
+
+and this is for right pages
+\end_layout
+
\begin_layout Section
Introduction
\begin_inset Note Note
@@ -164,29 +155,22 @@ Methodology
\end_layout
\begin_layout Theorem
-\begin_inset ERT
+\begin_inset OptArg
status collapsed
\begin_layout Standard
-
-[
-\end_layout
-
-\end_inset
-
Theorem name
-\begin_inset ERT
-status collapsed
-
-\begin_layout Standard
-
-]
\end_layout
\end_inset
- For a named theorem or theorem-like environment you need to use a little
- evil red text (LaTeX mode) around the name.
+For a named theorem or theorem-like environment you need to insert the name
+ through
+\family sans
+Insert\SpecialChar \menuseparator
+Short Title
+\family default
+, as done here.
\end_layout
\begin_layout Lemma
Index: lib/layouts/IEEEtran.layout
===
--- lib/layouts/IEEEtran.layout (revision 18756)
+++ lib/layouts/IEEEtran.layout (working copy)
@@ -57,6 +57,7 @@ Style TheoremTemplate
LabelFont
Shape Italic
EndFont
+ OptionalArgs 1
End
@@ -73,7 +74,7 @@ Style Theorem
LatexName thm
LabelString Theorem #:
Preamble
- \newtheorem{thm}{Theorem}
+ \newtheorem{thm}{Theorem}
EndPreamble
End
@@ -83,7 +84,7 @@ Style Lemma
LatexName lemma
LabelString Lemma #:
Preamble
- \newtheorem{lemma}{Lemma}
+ \newtheorem{lemma}{Lemma}
EndPreamble
End
@@ -93,7 +94,7 @@ Style Corollary
LatexName cor
LabelString Corollary #:
Preamble
- \newtheorem{cor}{Corollary}
+ \newtheorem{cor}{Corollary}
EndPreamble
End
@@ -103,7 +104,7 @@ Style Proposition
LatexName prop
LabelString Proposition #:
Preamble
- \newtheorem{prop}{Proposition}
+ \newtheorem{prop}{Proposition}
EndPreamble
End
@@ -113,7 +114,7 @@ Style Conjecture
LatexName conject
LabelString Conjecture #:
Preamble
- \newtheorem{conject}{Conjecture}
+ \newtheorem{conject}{Conjecture}
EndPreamble
End
@@ -123,7 +124,7 @@ Style Criterion
LatexName criter
LabelString Criterion #:
Preamble
- \newtheorem{criter}{Criterion}
+ \newtheorem{criter}{Criterion}
EndPreamble
End
@@ -133,7 +134,7 @@ Style Fact
LatexName fact
LabelString Fact #:
Preamble
- \newtheorem{fact}{Fact}
+ \newtheorem{fact}{Fact}
EndPreamble
End
@@ -143,7 +144,7 @@ Style Axiom
LatexName axi
LabelString Axiom #:
Preamble
- \newtheorem{axi}{Axiom}
+ \newtheorem{axi}{Axiom}
EndPreamble
End
@@ -153,7 +154,7 @@ Style Definition
LatexName definitn
LabelString Definition #:
Preamble
- \newtheorem{definitn}{Definition}
+ \newtheorem{definitn}{Definition}
EndPreamble
End
@@ -163,7 +164,7 @@ Style Example
LatexName example
LabelString Example #:
Preamble
- \newtheorem{example}{Example}
+
Re: [PATCH] 2697: SplitLayout environment.
On Wed, Jun 13, 2007 at 06:26:45PM +0200, Juergen Spitzmueller wrote: Bo Peng wrote: Patch submitted, please test or read user's guide, section 3.4.4. Enrico, you might use this Split environment instead of the clumsy ERT in the IEEEtran template (last section). Yes, I think so. Please, let me know what you think about the updated patch using the brilliant solution by JMarc. -- Enrico
Re: [patch] bug 3510: make IEEEtran template compilable
On Wed, Jun 13, 2007 at 11:19:22PM +0100, José Matos wrote: On Wednesday 13 June 2007 19:11:41 Jean-Marc Lasgouttes wrote: Looks OK to me. JMarc OK. Committed: http://www.lyx.org/trac/changeset/18767. JMarc, what about 1.4.x? -- Enrico
Re: [patch] bug 3510: make IEEEtran template compilable
On Thu, Jun 14, 2007 at 10:41:05AM +0200, Jean-Marc Lasgouttes wrote: Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico On Wed, Jun 13, 2007 at 11:19:22PM +0100, José Matos wrote: On Wednesday 13 June 2007 19:11:41 Jean-Marc Lasgouttes wrote: Looks OK to me. JMarc OK. Enrico Committed: http://www.lyx.org/trac/changeset/18767. Enrico JMarc, what about 1.4.x? OK, but note that OptionalArgs for environments do not exist there. Yes, I know. I've only modified the MarkBoth environment and removed the white space at the beginning of line in preamble stuff, which has always bothered me. http://www.lyx.org/trac/changeset/18769 -- Enrico
Re: [patch] bug 3510: make IEEEtran template compilable
On Thu, Jun 14, 2007 at 04:26:18PM +0200, Jean-Marc Lasgouttes wrote: Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico Yes, I know. I've only modified the MarkBoth environment and Enrico removed the white space at the beginning of line in preamble Enrico stuff, which has always bothered me. I liked this white space in front of preamble... It shows the nesting (and does not appear in the LaTeX file). Sorry, didn't know that. However, any white space beyond the indentation of the Preamble keyword appears in the latex file, at least for me (this is what was bothering me...) -- Enrico
Re: [PATCH] Make HTML Export Work (Bugs 3090, 3047, etc)
On Thu, Jun 14, 2007 at 04:06:16PM -0400, Richard Heck wrote: I've added two scripts: a dir_copy.py script, that simply copies the entire temporary directory over to a subdirectory of the intended output directory, and a tex4html_copy.py script that copies only .png, .html, and .css files, these (I'm pretty sure) being the only kinds of files generated by htlatex. What happens, in the end, then, is that if you open /path/to/file/LyXFile.lyx and do FileExportHTML, then you end up with a (possibly new) directory /path/to/file/LyXFile.html.LyXconv/ and all the relevant files are in there. Rather, say, than scattered across /path/to/file/, which would make it a hassle then to move them to a webserver. When the html converter is not htlatex, why don't you simply take a snapshot of the files that are in the temp dir just before calling the converter, put their names in a file, say FilesToNotBeCopied, and then use a html_copy.py script that copies only those files that are not listed in FilesToNotBeCopied? You may also want to check if one of the `files' created by the converter is instead a directory and properly copy that, too. And then remove the `files' that gets copied, of course. -- Enrico
Re: [PATCH] Make HTML Export Work (Bugs 3090, 3047, etc)
On Thu, Jun 14, 2007 at 06:49:17PM -0400, Richard Heck wrote: Enrico Forestieri wrote: On Thu, Jun 14, 2007 at 04:06:16PM -0400, Richard Heck wrote: I've added two scripts: a dir_copy.py script, that simply copies the entire temporary directory over to a subdirectory of the intended output directory, and a tex4html_copy.py script that copies only .png, .html, and .css files, these (I'm pretty sure) being the only kinds of files generated by htlatex. What happens, in the end, then, is that if you open /path/to/file/LyXFile.lyx and do FileExportHTML, then you end up with a (possibly new) directory /path/to/file/LyXFile.html.LyXconv/ and all the relevant files are in there. Rather, say, than scattered across /path/to/file/, which would make it a hassle then to move them to a webserver. When the html converter is not htlatex, why don't you simply take a snapshot of the files that are in the temp dir just before calling the converter, put their names in a file, say FilesToNotBeCopied, and then use a html_copy.py script that copies only those files that are not listed in FilesToNotBeCopied? Yes, we discussed this before, and I thought about that, but there are two problems. One is that we don't know that none of the files that are generated by the HTML converter over-write files that are already present. I don't know that this would be a common problem, but it's possible. I had proposed trying to check the timestamps to avoid this problem, but that turned out to be useless, because of the granularity of the timestamps. On POSIX systems the granularity is 1 second, on Windows with FAT it is 2 seconds. So, what about creating a file, taking its timestamp, waiting for 2 seconds and then calling the converter? The other is that it involves messing with Converters.cpp, which is what I was kind of trying not to do. And we don't want to check there what the converter is, so we'd have to generate this file all the time. I guess there could be a special flag for that, but that just seems so messy. The better solution would be for me to find out what latex2html generates, then write a special script for it. This is wrong, as you also have to take into account tth, hevea and I am sure that an user could use some other converter that you don't know about. You may also want to check if one of the `files' created by the converter is instead a directory and properly copy that, too. I'll add that to the dir_copy.py program. It actually means I can just use copytree(), so everything gets simpler. Yes, simpler, but this way you are going to copy a lot of trash and I am not sure that a casual user is able to sort out the mess. -- Enrico
Re: [PATCH-updated] Make HTML Export Work
On Fri, Jun 15, 2007 at 12:39:01AM -0400, Richard Heck wrote: This patch is now slightly updated. In place of the two scripts tex4html_copy.py and dir_copy.py, there is now just one, ext_copy.py. Without any optional arguments, this script acts like dir_copy.py did: It copies all files in LyX's temporary directory to a subdirectory of the target directory. But now the script takes two optional arguments: -e: a list of extensions to copy, by default all -t: an extension to add to the name of the generated target directory, by default LyXconv The idea with the default in the latter case is simply to avoid conflicting filenames. But if, like Uwe, you feel like being reckless ;-), you can do define your HTML copier as: python ext_copy.py -e html,css,png -t . $$i $$o and you'll export to /path/to/filename.html/. Note the use of the dot here. This new patch will allow easy handling of other converters, such as hevea (and if anyone knows what kinds of files it generates, let me know, and I'll add the definition to configure.py). You just have to say what kinds of files to copy. Of course, in some cases, you may end up copying more than you really needed to copy, but avoiding this is complicated and, to my mind, not entirely necessary, as this remains an exceptional case. The patch also includes some associated updates to the documentation. This issue has proven to be difficult, so I think that your solution is the less intrusive and workable one. I think that we should support more actively the converters we look for, i.e., provide a -e switch for latex2html and hevea, but this could be done by others who know the kind of output they generate. Now seeking an OK to commit. I think you got enough of them. Only a suggestion: Please name the script html_copy.py as this is what it is intended for. If you think that it can be used for a more general purpose, such that ext_copy.py is more correct, then avoid adding .html to the directory it creates. Thanks for having solved this long standing problem. -- Enrico
Re: [Cvslog] r18692 - /lyx-devel/trunk/src/LaTeXFeatures.cpp
On Sat, Jun 16, 2007 at 12:29:55PM +0200, Michael Gerz wrote: [EMAIL PROTECTED] schrieb: Author: rgheck Date: Wed Jun 6 21:33:57 2007 New Revision: 18692 URL: http://www.lyx.org/trac/changeset/18692 Log: Fix bug 3823: Division needs not to return an integer. Also added some comments about a different possible fix. Two things: - Why do we divide by 255 and not by 256? If the range [0, 255] is to be translated to the range [0.0, 1.0], you must divide by 255 and not 256. -- Enrico
Re: [Fwd: Re: [Cvslog] r18692 - /lyx-devel/trunk/src/LaTeXFeatures.cpp]
On Sat, Jun 16, 2007 at 11:08:19AM -0400, Richard Heck wrote: - There are two more places where a floating point division may be useful. Yes. Surprising no bug reports about that one, as it'll give the same problem. But anyway, we should just have: Yes. Possibly, limiting the precision to two decimal digits, as in the other case. -- Enrico
Re: Shaded note = Colored Note???
On Sun, Jun 17, 2007 at 11:19:37AM +0200, Michael Gerz wrote: Here comes a first proposal that cleans up the code. Personally, I think that we call too many things a note. At least, we are supposed to be consistent (internally externally) with this patch. What is missing is a lyx2lyx converter that converts the two former note types (Note Shaded) to \begin_inset Note LyXInternal and \begin_inset Note Colored Any volunteer? Any comments? Just a comment. With this patch you are going to break compatibility with existing preferences and lyxrc.dist files. Please, don't do that. -1 -- Enrico
Re: tear-off math panels
On Tue, Jun 12, 2007 at 11:28:37PM +0200, Edwin Leuven wrote:
+// FIXME: this can go when we move to Qt 4.3
+#define QT_VERSION_CHECK(major, minor, patch)
((major16)|(minor8)|(patch))
+
+#if QT_VERSION = QT_VERSION_CHECK(4, 2, 0)
Wouldn't that give a 'redefine macro' ith 4.3?
Why not simply using 0x40200?
because my compiler doesn't like it?
Erm... seems that the Qt4.1 moc wants 0x040200 and don't understand
QT_VERSION_CHECK(4, 2, 0). I have to use the attached patch in order
to avoid the following compile error:
g++ -DHAVE_CONFIG_H -I. -I../../../../src/frontends/qt4 -I../../../src
-DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS
-DQ_CYGWIN_WIN -I../../../../src -I../../../../src/frontends
-I../../../../images -I/usr/local/qt4-cygwin/include
-I/usr/local/qt4-cygwin/include/QtCore -I/usr/local/qt4-cygwin/include/QtGui
-I../../../../boost -I../../../../src/frontends/controllers -Wno-uninitialized
-O2 -MT IconPalette.lo -MD -MP -MF .deps/IconPalette.Tpo -c
../../../../src/frontends/qt4/IconPalette.cpp -o IconPalette.o
In file included from ../../../../src/frontends/qt4/IconPalette.cpp:269:
./IconPalette_moc.cpp:46: error: `QWidgetAction' has not been declared
./IconPalette_moc.cpp: In member function `virtual void*
lyx::frontend::IconPalette::qt_metacast(const char*)':
./IconPalette_moc.cpp:60: error: `QWidgetAction' has not been declared
./IconPalette_moc.cpp: In member function `virtual int
lyx::frontend::IconPalette::qt_metacall(QMetaObject::Call, int, void**)':
./IconPalette_moc.cpp:65: error: `QWidgetAction' has not been declared
./IconPalette_moc.cpp:70: error: `enabled' undeclared (first use this function)
./IconPalette_moc.cpp:70: error: (Each undeclared identifier is reported only
once for each function it appears in.)
./IconPalette_moc.cpp:71: error: `iconSizeChanged' undeclared (first use this
function)
./IconPalette_moc.cpp:73: error: `setIconSize' undeclared (first use this
function)
./IconPalette_moc.cpp: At global scope:
./IconPalette_moc.cpp:82: error: no `void
lyx::frontend::IconPalette::enabled(bool)' member function declared in class
`lyx::frontend::IconPalette'
./IconPalette_moc.cpp:89: error: no `void
lyx::frontend::IconPalette::iconSizeChanged(const QSize)' member function
declared in class `lyx::frontend::IconPalette'
make[7]: *** [IconPalette.lo] Error 1
--
Enrico
Index: src/frontends/qt4/IconPalette.h
===
--- src/frontends/qt4/IconPalette.h (revision 18815)
+++ src/frontends/qt4/IconPalette.h (working copy)
@@ -20,7 +20,7 @@
// FIXME: this can go when we move to Qt 4.3
#define QT_VERSION_CHECK(major, minor, patch) ((major16)|(minor8)|(patch))
-#if QT_VERSION = QT_VERSION_CHECK(4, 2, 0)
+#if QT_VERSION = 0x040200
#include QWidgetAction
#endif
@@ -30,7 +30,7 @@ namespace frontend {
/**
* For holding an arbitrary set of icons.
*/
-#if QT_VERSION = QT_VERSION_CHECK(4, 2, 0)
+#if QT_VERSION = 0x040200
class IconPalette : public QWidgetAction {
Q_OBJECT
Re: tear-off math panels
On Mon, Jun 18, 2007 at 08:03:21AM +0200, Andre Poenitz wrote:
On Mon, Jun 18, 2007 at 04:20:13AM +0200, Enrico Forestieri wrote:
On Tue, Jun 12, 2007 at 11:28:37PM +0200, Edwin Leuven wrote:
+// FIXME: this can go when we move to Qt 4.3
+#define QT_VERSION_CHECK(major, minor, patch)
((major16)|(minor8)|(patch))
+
+#if QT_VERSION = QT_VERSION_CHECK(4, 2, 0)
Wouldn't that give a 'redefine macro' ith 4.3?
Why not simply using 0x40200?
because my compiler doesn't like it?
Erm... seems that the Qt4.1 moc wants 0x040200 and don't understand
QT_VERSION_CHECK(4, 2, 0). I have to use the attached patch in order
to avoid the following compile error:
It looks like either moc doesn't care much about the actual condition
but decides whether to use the 'if' or the 'else' branch solely
depending on the structure of the line (macro with parameters vs macro
without).
Definitely. I think that the problem is that moc doesn't parse #include'd
files, such that QT_VERSION is really undefined. Moreover, it doesn't seem
to perform like the preprocessor, such that the QT_VERSION_CHECK macro
is useless.
Using the attached patch I was able to compile using Qt 4.2.2 and,
after changing the definition for QT_VERSION to 0x040100, compilation
went fine for Qt 4.1.4, too.
How can this be solved?
--
Enrico
Index: src/frontends/qt4/IconPalette.h
===
--- src/frontends/qt4/IconPalette.h (revision 18815)
+++ src/frontends/qt4/IconPalette.h (working copy)
@@ -17,10 +17,11 @@
#include QLayout
#include Action.h
-// FIXME: this can go when we move to Qt 4.3
-#define QT_VERSION_CHECK(major, minor, patch) ((major16)|(minor8)|(patch))
+#ifndef QT_VERSION
+#define QT_VERSION 0x040200
+#endif
-#if QT_VERSION = QT_VERSION_CHECK(4, 2, 0)
+#if QT_VERSION = 0x040200
#include QWidgetAction
#endif
@@ -30,7 +31,7 @@ namespace frontend {
/**
* For holding an arbitrary set of icons.
*/
-#if QT_VERSION = QT_VERSION_CHECK(4, 2, 0)
+#if QT_VERSION = 0x040200
class IconPalette : public QWidgetAction {
Q_OBJECT
Re: Empty Math Panel Popups
On Mon, Jun 18, 2007 at 12:06:50PM +0200, Leuven, E. wrote: --- src/frontends/qt4/IconPalette.h (revision 18812) +++ src/frontends/qt4/IconPalette.h (working copy) @@ -20,7 +20,7 @@ // FIXME: this can go when we move to Qt 4.3 #define QT_VERSION_CHECK(major, minor, patch) ((major16)|(minor8)|(patch)) -#if QT_VERSION = QT_VERSION_CHECK(4, 2, 0) +#if QT_VERSION = QT_VERSION_CHECK(4, 2, 0) !Q_WS_MACX #include QWidgetAction #endif Edwin, moc doesn't perform like the preprocessor. It doesn't parse included files, such that QT_VERSION is undefined, and doesn't understand macros. In the check above, moc chooses randomly one branch or another. See what I wrote in the thread tear-off math panel. -- Enrico
Re: Empty Math Panel Popups
On Mon, Jun 18, 2007 at 02:09:34PM +0200, Abdelrazak Younes wrote:
Enrico Forestieri wrote:
On Mon, Jun 18, 2007 at 12:06:50PM +0200, Leuven, E. wrote:
--- src/frontends/qt4/IconPalette.h(revision 18812)
+++ src/frontends/qt4/IconPalette.h(working copy)
@@ -20,7 +20,7 @@
// FIXME: this can go when we move to Qt 4.3
#define QT_VERSION_CHECK(major, minor, patch)
((major16)|(minor8)|(patch))
-#if QT_VERSION = QT_VERSION_CHECK(4, 2, 0)
+#if QT_VERSION = QT_VERSION_CHECK(4, 2, 0) !Q_WS_MACX
#include QWidgetAction
#endif
Edwin, moc doesn't perform like the preprocessor. It doesn't parse
included files, such that QT_VERSION is undefined, and doesn't
understand macros. In the check above, moc chooses randomly one
branch or another. See what I wrote in the thread tear-off math panel.
I think there are two solutions:
1) require Qt4.2
While tearing away math panels maybe a nice feature, it is not essential,
so requiring Qt4.2 only for that is a lame excuse, IMHO. This is so also
for the requirement of Qt4.1 minimum, as it is only dictated by the
syntax highlighting thing. This is only mitigated by the fact that
Qt4.0 was somewhat buggy. On the contrary, Qt4.1 is a quite good version.
2) Modify the build system(s) to selectively compile
IconPalette_42.{h,cpp} when Qt = 4.2 is detected and
IconPalette.{h,cpp} otherwise.
As 1) is not an option for some of us the only solution is 2).
Maybe. Let's see what our experts are able to do. Personally, I don't
have any problem with whatever version is required.
--
Enrico
Re: Re: Empty Math Panel Popups
On Mon, Jun 18, 2007 at 04:22:09PM +0200, Leuven, E. wrote: can people try the attached? it is another approach to tear off the panels: simply move the panel this time only using 4.1 stuff ... Works for me with both Qt 4.1.4 and 4.2.2. However, the panel disappears after making a choice, so I think that this behavior is not different with respect to the preious one. -- Enrico
Re: RE: Re: Empty Math Panel Popups
On Mon, Jun 18, 2007 at 06:20:07PM +0200, Leuven, E. wrote:
Tried it (qt 4.2.3 here). Doesn't seem to work well:
the panel gets a decoration like normal windows when opened (so it's
already detached)
, and moreover closes itself when clicking on a symbol.
no! no! no! ;-)
the idea is the following:
detaching makes the panel stay on top so that you can enter multple symbols
in a row
so on popup the panel is attached (after clicking it disappears)
to detach it you can *move* the panel. for this you need the title bar. try
it, you will see that now it stays on top.
i hope i am clearer now
What about the attached patch, instead? I tested it with Qt 4.1.4 and 4.2.2.
Something similar can be done with scons.
--
Enrico
Index: src/frontends/qt4/Makefile.am
===
--- src/frontends/qt4/Makefile.am (revision 18815)
+++ src/frontends/qt4/Makefile.am (working copy)
@@ -11,6 +11,11 @@ libqt4_la_DEPENDENCIES = $(MOCEDFILES)
MOCEDFILES = $(MOCFILES:.cpp=_moc.cpp)
+IconPalette_moc.cpp: $(srcdir)/IconPalette.h
+ sed -e s/QT4_VERSION/%%$(QT4_VERSION)%%/ \
+ -e s|%%\(.\)\.\(.\)\.\(.\)%%|0x0\10\20\3| $ IconPalette_moc.h
+ $(MOC4) -o IconPalette_moc.cpp IconPalette_moc.h
+
%_moc.cpp: %.h
$(MOC4) -o $@ $
Index: src/frontends/qt4/IconPalette.h
===
--- src/frontends/qt4/IconPalette.h (revision 18815)
+++ src/frontends/qt4/IconPalette.h (working copy)
@@ -17,10 +17,11 @@
#include QLayout
#include Action.h
-// FIXME: this can go when we move to Qt 4.3
-#define QT_VERSION_CHECK(major, minor, patch) ((major16)|(minor8)|(patch))
+#ifndef QT_VERSION
+#define QT_VERSION QT4_VERSION
+#endif
-#if QT_VERSION = QT_VERSION_CHECK(4, 2, 0)
+#if QT_VERSION = 0x040200
#include QWidgetAction
#endif
@@ -30,7 +31,7 @@ namespace frontend {
/**
* For holding an arbitrary set of icons.
*/
-#if QT_VERSION = QT_VERSION_CHECK(4, 2, 0)
+#if QT_VERSION = 0x040200
class IconPalette : public QWidgetAction {
Q_OBJECT
@@ -77,7 +78,7 @@ private:
QListQAction * actions_;
};
-#endif // QT_VERSION = QT_VERSION_CHECK(4, 2, 0)
+#endif // QT_VERSION = 0x040200
/**
* Popup menu for a toolbutton.
Re: Empty Math Panel Popups
On Mon, Jun 18, 2007 at 06:44:15PM +0200, Andre Poenitz wrote: On Mon, Jun 18, 2007 at 01:14:44PM +0200, Stefan Schimanski wrote: It does not even compile: #if QT_VERSION = 0x040200 !Q_WS_MACX gives operator '!' has no right operand. Maybe !defined(Q_WS_MACX) is better. Nope. Seems that moc doesn't parse included files, so Q_WS_MACX will always be undefined. -- Enrico
Re: Re: Empty Math Panel Popups
On Mon, Jun 18, 2007 at 06:58:32PM +0200, Leuven, E. wrote:
Andre Poenitz wrote:
On Mon, Jun 18, 2007 at 04:22:09PM +0200, Leuven, E. wrote:
+/* i didn't find a smarter way to find out
+ * whether a move was made by the user
+ * because we also move the widget ourselves
+ * to make it popup in the right position...
+ */
+switch (event-type()) {
+case QEvent::WindowActivate:
+active_ = true;
+case QEvent::WindowDeactivate:
+active_ = false;
So active_ == false in both cases? (missing 'break'?)
i changed it to the attached...
I get a compile error. What about my proposed patch which leaves things
as they are now but allows compilation with any Qt version?
g++ -DHAVE_CONFIG_H -I. -I../../../../src/frontends/qt4 -I../../../src
-DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS
-DQ_CYGWIN_WIN -I../../../../src -I../../../../src/frontends
-I../../../../images -I/usr/local/qt4-cygwin/include
-I/usr/local/qt4-cygwin/include/QtCore -I/usr/local/qt4-cygwin/include/QtGui
-I../../../../boost -I../../../../src/frontends/controllers -Wno-uninitialized
-O2 -MT IconPalette.lo -MD -MP -MF .deps/IconPalette.Tpo -c
../../../../src/frontends/qt4/IconPalette.cpp -o IconPalette.o
../../../../src/frontends/qt4/IconPalette.cpp: In member function `virtual void
lyx::frontend::IconPalette::moveEvent(QMoveEvent*)':
../../../../src/frontends/qt4/IconPalette.cpp:49: error: invalid use of
undefined type `struct QMoveEvent'
/usr/local/qt4-cygwin/include/QtGui/qwidget.h:61: error: forward declaration of
`struct QMoveEvent'
make[7]: *** [IconPalette.lo] Error 1
--
Enrico
Re: Empty Math Panel Popups
On Tue, Jun 19, 2007 at 04:14:18PM +0200, Leuven, E. wrote: in summary: - allow panels to tear off using only qt 4.1 functionality - reported to work on windows, linux and mac seeking 2 ok's Edwin, I really appreciate your effort for trying to provide this feature with Qt 4.1. However, I think that we should not jump through hoops if something is hard to obtain with older Qt versions. It suffices to let the thing compile, even with reduced functionality. I tried the patch with Qt 4.1 and it almost works (I am really impressed). There's a quirk, though. After detaching a panel and trying to close it again, LyX freezes. There's no cpu load, LyX simply doesn't respond anymore and after a Ctrl-C an emergency file is created. Taking into account the time and effort you put in this, I am really afraid to suggest leaving things as they are now and simply applying that small patch curing the moc problem. What do you (and others) think? -- Enrico
Re: Empty Math Panel Popups
On Tue, Jun 19, 2007 at 08:40:52PM +0200, Edwin Leuven wrote: the attached patch has the advantage that it also allows tearoff panels on the mac i would be very surprised if this one doesn't work for you You did it! Works like a charm. A big thank you! -- Enrico
Re: problems to show figures in LyX
On Tue, Jun 19, 2007 at 04:22:59PM -0300, Fernando Roig wrote:
Hi developers:
I am running LyX 1.5.0rc1 on Windows XP SP2. When I include an eps
graph, LyX is not able to show it but displays the message Error
converting to loadable format
I run lyxc.exe -dbg graphics and got the output below when including
the graph.
Does anybody knows what is going on?
I can reproduce this bug. It occurs when the temp dir contains nonascii
characters. The attached patch fixes it. José, OK to commit?
--
Enrico
Index: src/graphics/GraphicsConverter.cpp
===
--- src/graphics/GraphicsConverter.cpp (revision 18837)
+++ src/graphics/GraphicsConverter.cpp (working copy)
@@ -226,8 +226,8 @@ static string const move_file(string con
return string();
ostringstream command;
- command fromfile = from_file \n
-tofile = to_file \n\n
+ command fromfile = utf8ToDefaultEncoding( from_file )\n
+tofile = utf8ToDefaultEncoding(to_file )\n\n
try:\n
os.rename(fromfile, tofile)\n
except:\n
@@ -323,7 +323,8 @@ static void build_script(FileName const
script infile = utf8ToDefaultEncoding(
quoteName(from_file.absFilename(), quote_python)
)\n
- outfile = quoteName(outfile, quote_python) \n
+ outfile = utf8ToDefaultEncoding(
+quoteName(outfile, quote_python) )\n
shutil.copy(infile, outfile)\n;
// Some converters (e.g. lilypond) can only output files to the
@@ -331,15 +332,16 @@ static void build_script(FileName const
// This has the added benefit that all other files that may be
// generated by the converter are deleted when LyX closes and do not
// clutter the real working directory.
- script os.chdir( quoteName(onlyPath(outfile)) )\n;
+ script os.chdir(utf8ToDefaultEncoding(
+ quoteName(onlyPath(outfile)) ))\n;
if (edgepath.empty()) {
// Either from_format is unknown or we don't have a
// converter path from from_format to to_format, so we use
// the default converter.
script infile = outfile\n
- outfile = quoteName(to_file, quote_python)
- '\n';
+ outfile = utf8ToDefaultEncoding(
+ quoteName(to_file, quote_python) )\n;
ostringstream os;
os support::os::python() ' '
@@ -379,9 +381,12 @@ static void build_script(FileName const
outfile = addExtension(to_base.absFilename(),
conv.To-extension());
// Store these names in the python script
- script infile =quoteName(infile, quote_python)
\n
- infile_base = quoteName(infile_base,
quote_python) \n
- outfile = quoteName(outfile, quote_python)
'\n';
+ script infile = utf8ToDefaultEncoding(
+quoteName(infile, quote_python) )\n
+ infile_base = utf8ToDefaultEncoding(
+quoteName(infile_base, quote_python) )\n
+ outfile = utf8ToDefaultEncoding(
+quoteName(outfile, quote_python) )\n;
// See comment about extra quotes above (although that
// applies only for the first loop run here).
Re: Can't enter extra whitespace when editing.
On Wed, Jun 20, 2007 at 02:07:25PM +1000, Darren Freeman wrote: On Tue, 2007-06-19 at 17:51 +0200, Jean-Marc Lasgouttes wrote: Darren == Darren Freeman [EMAIL PROTECTED] writes: Darren My point was that in the past you could enter them and they Darren would be removed when you moved away, but now you can't enter Darren them at all. I vote for the older behaviour which feels more Darren natural. Are you sure? What version was that? I doubt that it has changed recently. I went from 1.3 to 1.5svn so sometime in-between. I just checked that LyX 1.1.6fix4 and 1.3.7 didn't allow that. So, I would say that it has always been like that. -- Enrico
Re: problems to show figures in LyX
On Wed, Jun 20, 2007 at 09:44:12AM +0100, José Matos wrote: On Wednesday 20 June 2007 00:00:06 Enrico Forestieri wrote: The attached patch fixes it. José, OK to commit? The patch seems right. If you someone to test this and guarantee that it works (no need to be a developer) it can go in. Testing is quite easy: -) Create a directory with nonascii chars, say /tmp/olà -) Start LyX and in Tools-Preferences-Paths set the temporary directory to /tmp/olà -) Save preferences, quit and then restart LyX -) Try to insert any graphics file. Without the patch, LyX is not able to generate a preview. With it, everything is fine. When testing, be sure that the graphics file is not already cached, as in this case the conversion script will not be run ;-) -- Enrico
Re: problems to show figures in LyX
On Wed, Jun 20, 2007 at 09:44:12AM +0100, José Matos wrote:
On Wednesday 20 June 2007 00:00:06 Enrico Forestieri wrote:
The attached patch fixes it. José, OK to commit?
The patch seems right. If you someone to test this and guarantee that it
works (no need to be a developer) it can go in.
Here is an updated patch that also cures the following startup error
on *nix/cygwin:
Error returned from iconv
EILSEQ An invalid multibyte sequence has been encountered in the input.
When converting from UTF-8 to UCS-4LE.
Input: 0x2f 0x74 0x6d 0x70 0x2f 0x6f 0x6c 0xe0 0x2f 0x6c 0x79 0x78 0x5f 0x74
0x6d 0x70 0x64 0x69 0x72 0x32 0x30 0x30 0x30 0x63 0x77 0x73 0x63 0x54 0x6c 0x2f
0x6c 0x79 0x78 0x73 0x6f 0x63 0x6b 0x65 0x74
and this one on windows:
Error returned from iconv
EINVAL An incomplete multibyte sequence has been encountered in the input.
When converting from UTF-8 to UCS-4LE.
Input: 0x43 0x3a 0x2f 0x63 0x79 0x67 0x77 0x69 0x6e 0x2f 0x74 0x6d 0x70 0x2f
0x6f 0x6c 0xe0
when the temp dir has nonascii chars. These errors are triggered by the
fact that setEnv() and addName() take utf8 strings as input and they are
instead passed local 8bit encoded strings. I doubt that anyone will test it
(see here: http://article.gmane.org/gmane.editors.lyx.general/39630)
so, José, take your responsibility and make a decision ;-)
I tested the patch and guarantee that it is correct ;-)
--
Enrico
Index: src/graphics/GraphicsConverter.cpp
===
--- src/graphics/GraphicsConverter.cpp (revision 18837)
+++ src/graphics/GraphicsConverter.cpp (working copy)
@@ -226,8 +226,8 @@ static string const move_file(string con
return string();
ostringstream command;
- command fromfile = from_file \n
-tofile = to_file \n\n
+ command fromfile = utf8ToDefaultEncoding( from_file )\n
+tofile = utf8ToDefaultEncoding(to_file )\n\n
try:\n
os.rename(fromfile, tofile)\n
except:\n
@@ -323,7 +323,8 @@ static void build_script(FileName const
script infile = utf8ToDefaultEncoding(
quoteName(from_file.absFilename(), quote_python)
)\n
- outfile = quoteName(outfile, quote_python) \n
+ outfile = utf8ToDefaultEncoding(
+quoteName(outfile, quote_python) )\n
shutil.copy(infile, outfile)\n;
// Some converters (e.g. lilypond) can only output files to the
@@ -331,15 +332,16 @@ static void build_script(FileName const
// This has the added benefit that all other files that may be
// generated by the converter are deleted when LyX closes and do not
// clutter the real working directory.
- script os.chdir( quoteName(onlyPath(outfile)) )\n;
+ script os.chdir(utf8ToDefaultEncoding(
+ quoteName(onlyPath(outfile)) ))\n;
if (edgepath.empty()) {
// Either from_format is unknown or we don't have a
// converter path from from_format to to_format, so we use
// the default converter.
script infile = outfile\n
- outfile = quoteName(to_file, quote_python)
- '\n';
+ outfile = utf8ToDefaultEncoding(
+ quoteName(to_file, quote_python) )\n;
ostringstream os;
os support::os::python() ' '
@@ -379,9 +381,12 @@ static void build_script(FileName const
outfile = addExtension(to_base.absFilename(),
conv.To-extension());
// Store these names in the python script
- script infile =quoteName(infile, quote_python)
\n
- infile_base = quoteName(infile_base,
quote_python) \n
- outfile = quoteName(outfile, quote_python)
'\n';
+ script infile = utf8ToDefaultEncoding(
+quoteName(infile, quote_python) )\n
+ infile_base = utf8ToDefaultEncoding(
+quoteName(infile_base, quote_python) )\n
+ outfile = utf8ToDefaultEncoding(
+quoteName(outfile, quote_python) )\n;
// See comment about extra quotes above (although that
// applies only for the first loop run here).
Index: src/support/tempname.cpp
===
--- src/support/tempname.cpp(revision 18837)
+++ src/support/tempname.cpp(working copy)
@@ -81,9 +81,9 @@ int make_tempfile(char * templ)
FileName const tempName(FileName const dir, string const mask)
{
string const tmpdir(dir.empty() ?
- package().temp_dir().toFilesystemEncoding
Re: Create new document dialog: Create and cancel, reverse action.
On Wed, Jun 20, 2007 at 02:42:10PM -0500, Bo Peng wrote: lyx anewfile.lyx Lyx asks: 'The document anewfile.lyx does not yet exist. Do you want to create a new document? Click create. no new document is created. Click cancel: a new document is created. This should be fixed ASAP. The patch is easy. Note that prompt() returns button index so 'create' button returns 0. Index: src/buffer_funcs.cpp === --- src/buffer_funcs.cpp(revision 18837) +++ src/buffer_funcs.cpp(working copy) @@ -214,7 +214,7 @@ docstring text = bformat(_(The document %1$s does not yet exist.\n\nDo you want to create a new document?), from_utf8(filename.absFilename())); - if (Alert::prompt(_(Create new document?), + if (!Alert::prompt(_(Create new document?), text, 0, 1, _(Create), _(Cancel))) return newFile(filename.absFilename(), string(), true); Waiting for 1 OK becuase this is trivial. The patch works for me. -- Enrico
Re: problems to show figures in LyX
On Wed, Jun 20, 2007 at 10:00:54PM +0200, Enrico Forestieri wrote: On Wed, Jun 20, 2007 at 09:44:12AM +0100, José Matos wrote: On Wednesday 20 June 2007 00:00:06 Enrico Forestieri wrote: The attached patch fixes it. José, OK to commit? The patch seems right. If you someone to test this and guarantee that it works (no need to be a developer) it can go in. Here is an updated patch that also cures the following startup error on *nix/cygwin: Error returned from iconv EILSEQ An invalid multibyte sequence has been encountered in the input. When converting from UTF-8 to UCS-4LE. Input: 0x2f 0x74 0x6d 0x70 0x2f 0x6f 0x6c 0xe0 0x2f 0x6c 0x79 0x78 0x5f 0x74 0x6d 0x70 0x64 0x69 0x72 0x32 0x30 0x30 0x30 0x63 0x77 0x73 0x63 0x54 0x6c 0x2f 0x6c 0x79 0x78 0x73 0x6f 0x63 0x6b 0x65 0x74 and this one on windows: Error returned from iconv EINVAL An incomplete multibyte sequence has been encountered in the input. When converting from UTF-8 to UCS-4LE. Input: 0x43 0x3a 0x2f 0x63 0x79 0x67 0x77 0x69 0x6e 0x2f 0x74 0x6d 0x70 0x2f 0x6f 0x6c 0xe0 when the temp dir has nonascii chars. These errors are triggered by the fact that setEnv() and addName() take utf8 strings as input and they are instead passed local 8bit encoded strings. I doubt that anyone will test it (see here: http://article.gmane.org/gmane.editors.lyx.general/39630) so, José, take your responsibility and make a decision ;-) I tested the patch and guarantee that it is correct ;-) This is now bug 3904. http://bugzilla.lyx.org/show_bug.cgi?id=3904 -- Enrico
Re: RC2 coming soon
On Tue, Jun 26, 2007 at 02:18:37PM +0100, José Matos wrote: On Tuesday 26 June 2007 11:07:17 Uwe Stöhr wrote: No, we need an RC2 to test if our fixes to some crash bugs are really fixes. But I also think that RC2 should be released right now (after Jürgen's current fixes are in (bug 3915, 3916, and 2753)). I agree. I have committed the bugfix to 3313. So my list is now empty. :-) Please consider also bug 3904. This is a show stopper on systems whose locale is not utf8 and the tempdir contains non-ascii chars. For sure this affects Windows systems with a Portuguese locale and maybe others. The patch is pretty safe. -- Enrico
Re: Empty Math Panel Popups
On Mon, Jun 18, 2007 at 02:09:34PM +0200, Abdelrazak Younes wrote:
Enrico Forestieri wrote:
On Mon, Jun 18, 2007 at 12:06:50PM +0200, Leuven, E. wrote:
--- src/frontends/qt4/IconPalette.h(revision 18812)
+++ src/frontends/qt4/IconPalette.h(working copy)
@@ -20,7 +20,7 @@
// FIXME: this can go when we move to Qt 4.3
#define QT_VERSION_CHECK(major, minor, patch)
((major16)|(minor8)|(patch))
-#if QT_VERSION = QT_VERSION_CHECK(4, 2, 0)
+#if QT_VERSION = QT_VERSION_CHECK(4, 2, 0) !Q_WS_MACX
#include QWidgetAction
#endif
Edwin, moc doesn't perform like the preprocessor. It doesn't parse
included files, such that QT_VERSION is undefined, and doesn't
understand macros. In the check above, moc chooses randomly one
branch or another. See what I wrote in the thread tear-off math panel.
I think there are two solutions:
1) require Qt4.2
While tearing away math panels maybe a nice feature, it is not essential,
so requiring Qt4.2 only for that is a lame excuse, IMHO. This is so also
for the requirement of Qt4.1 minimum, as it is only dictated by the
syntax highlighting thing. This is only mitigated by the fact that
Qt4.0 was somewhat buggy. On the contrary, Qt4.1 is a quite good version.
2) Modify the build system(s) to selectively compile
IconPalette_42.{h,cpp} when Qt = 4.2 is detected and
IconPalette.{h,cpp} otherwise.
As 1) is not an option for some of us the only solution is 2).
Maybe. Let's see what our experts are able to do. Personally, I don't
have any problem with whatever version is required.
--
Enrico
Re: RC2 coming soon
On Tue, Jun 26, 2007 at 03:04:31PM +0100, José Matos wrote: On Tuesday 26 June 2007 14:59:58 Enrico Forestieri wrote: Please consider also bug 3904. This is a show stopper on systems whose locale is not utf8 and the tempdir contains non-ascii chars. For sure this affects Windows systems with a Portuguese locale and maybe others. The patch is pretty safe. I care about Portuguese, I don't care about Windows. :-) I would have said the same 3 or 4 years ago ;-) I had reviewed the patch. If you think it is safe (and since you have tested it) commit it. Done. -- Enrico
Re: [PATCH] bug 3537: lyx-1.5.0beta2 dumps core on freebsd-6.2 when it tries to handle strings of filenames etc.
On Tue, Jun 26, 2007 at 04:47:25PM +0200, Jean-Marc Lasgouttes wrote: +/* + * the FreeBSD libc uses UCS4, but libstdc++ has no proper wchar_t + * support compiled in: + * http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#3_9 + * And we are not interested at all what libc + * does: What we need is a 32bit wide wchar_t, and a libstdc++ that + * has the needed wchar_t support and uses UCS4. Whether it + * implements this with the help of libc, or whether it has own code + * does not matter for us, because we don't use libc directly (Georg) +*/ +#if defined(HAVE_WCHAR_T) SIZEOF_WCHAR_T == 4 ! defined(__FREEBSD__) +# define USE_WCHAR_T #endif According to http://www.netbsd.org/about/roadmap.html, this is also true for NetBSD, so I would also add !defined(__NetBSD__) there. -- Enrico
Re: [PATCH] bug 3537: lyx-1.5.0beta2 dumps core on freebsd-6.2 when it tries to handle strings of filenames etc.
On Tue, Jun 26, 2007 at 02:19:47PM -0500, Bo Peng wrote: On 6/26/07, Bo Peng [EMAIL PROTECTED] wrote: Are you sure about the name here? Not __NETBSD__? When I google, I see a lot of defined (__FreeBSD__) || defined (__OpenBSD__) || defined(__OpenBSD__) Of course I meant FreeBSD, OpenBSD and NetBSD. I don't know for the others. As regards NetBSD, I have an ancient version and just checked the output of g++ -E -dM -xc++ /dev/null. Looking at the URL provided by Peter, seems that you are right, though. -- Enrico
Re: problems to show figures in LyX
On Tue, Jun 26, 2007 at 09:38:44PM +0200, Michael Gerz wrote: Enrico Forestieri schrieb: On Wed, Jun 20, 2007 at 09:44:12AM +0100, José Matos wrote: On Wednesday 20 June 2007 00:00:06 Enrico Forestieri wrote: The attached patch fixes it. José, OK to commit? The patch seems right. If you someone to test this and guarantee that it works (no need to be a developer) it can go in. Here is an updated patch that also cures the following startup error on *nix/cygwin: Error returned from iconv EILSEQ An invalid multibyte sequence has been encountered in the input. When converting from UTF-8 to UCS-4LE. Input: 0x2f 0x74 0x6d 0x70 0x2f 0x6f 0x6c 0xe0 0x2f 0x6c 0x79 0x78 0x5f 0x74 0x6d 0x70 0x64 0x69 0x72 0x32 0x30 0x30 0x30 0x63 0x77 0x73 0x63 0x54 0x6c 0x2f 0x6c 0x79 0x78 0x73 0x6f 0x63 0x6b 0x65 0x74 and this one on windows: AFAICS, there are a couple of pending patches Uh? Has the patch above (or a similar one) been committed in the meantime? Yes: http://www.lyx.org/trac/changeset/18893 -- Enrico
Re: symbols don't display
On Wed, Jun 27, 2007 at 06:48:46PM +0200, Abdelrazak Younes wrote: Leuven, E. wrote: in math, \kappa and \leq don't show others seeing this as well? Since when? dunno, perhaps since forever Everything seems ok here. maybe some font trouble on my side... On my side too. So it's either a Windows problem or CMake problem. I also had this problem on Windows. In my case, I had a font with the same name as one of the Bakoma's. All other symbols were equal but the \kappa and \leq ones. The solution was to install the Bakoma fonts in the Windows fonts dir. -- Enrico
Re: [patch] doc/TOC.lyx: \usepackage[utf-8]{inputenc} causes 'utf-8.def not found'
On Fri, Jun 29, 2007 at 09:31:57AM +0200, Jean-Marc Lasgouttes wrote:
Uwe == Uwe Stöhr [EMAIL PROTECTED] writes:
I can not compile doc/TOC.lyx. I guess this is caused by line
\usepackage[utf-8]{inputenc}.
Uwe Because the correct line would be
Uwe \usepackage[utf8]{inputenc}
Why the need to set inputencoding to utf8?
Because it's easier to do without worrying for finding a better solution.
On my old tetex2, there is no utf8, and breaking it seems a bit
arbitrary.
Huff, these old-timers... you should spend the night upgrading all your
packages to the latest versions instead of sleeping!
--
Enrico
Re: 1.5.0beta2: export Latex(plain), why must overwrite my EPS graphics files?
On Sun, Jul 01, 2007 at 09:14:08AM +0200, Jürgen Spitzmüller wrote: Rob wrote: For all my graphics files I use eps format, which works OK within LyX. However, when I export my document with Export - LaTeX(plain), a dialog pops up with annoying choices:   The file  ~/my/doc/dir/figure.eps  already exists.   Do you want to over-write that file?   [Over-write]  [Overwrite-all]  [Cancel export] So I have to overwrite my own eps file, or cancel the export. Why isn't there the option [Do not overwrite] instead of [Cancel export] ? I would prefer to keep my original eps files (although you might say, the overwrite is the exactly the same file, I don't feel comfortable when clicking on 'overwrite', scared to lose my figure file.). Yes. Please file an enhancement request (although there's already a related request here: http://bugzilla.lyx.org/show_bug.cgi?id=3890 Also related: http://bugzilla.lyx.org/show_bug.cgi?id=2434 http://bugzilla.lyx.org/show_bug.cgi?id=2762 -- Enrico
Re: [PATCH] use native file dialog on windows (fix major bug 3907)
On Mon, Jul 02, 2007 at 05:02:03PM +0200, Abdelrazak Younes wrote: Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak Abdelrazak Younes wrote: Hello, Even though I like our file dialog, I think we have no choice but using native file dialog on Windows in order to fix bug 3907 (File - Open dialog needs many seconds before it opens). Abdelrazak Sorry, here is a correct patch. What version of qt is impacted? Only 4.3 or also older ones? If it is only 4.3, we can build official versions with 4.2.x until a fixed 4.3 appears. Nope, I use Qt4.2.1 so Qt4.2 _is_ impacted. I do not know about Qt4.3. Uwe, Edwin, Joost, Peter, do you use Qt4.3? The problem is the same in Qt4.3. This is because Qt queries for all logical drives in order to show them in the file dialog. Notice that this is not a problem on cygwin where the file dialog has the same layout as on *nix, so please add a !defined(Q_CYGWIN_WIN) if you go that route. Shared paths are also a problem when they are stored in the session file and and the network (or the machine they refer to) is not available. In this case, LyX freezes for a very long time. So, this is a more general problem and not confined to the file dialog. -- Enrico
Re: Status of LyX 1.5.0?
On Tue, Jul 03, 2007 at 08:13:42PM +0200, Peter Kümmel wrote: Peter Kümmel wrote: Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: 3962 cri (Math) Font problems on Windows This one is a packaging issue right? No, AFAIU you need to replace AddFontRessource and RemoveFontRessourse in support/os_win32.spp with AddFontResourceEx and RemoveFontResourceEx. Does attached patch solve the problem? Both functions are not supported by older Window versions. Therefore we have to decides at runtime which function to call. Compiles also with Qt 4.1: http://doc.trolltech.com/4.1/qsysinfo.html Please, could you also take care of that in os_cygwin.cpp, or do you prefer that I do it? -- Enrico
Re: Status of LyX 1.5.0?
On Tue, Jul 03, 2007 at 09:46:54PM +0200, Peter Kümmel wrote: Ok, here with the changes for cygwin, BUT I couldn't test it. And here is the result of my tests. I uninstalled the bakoma fonts from the Windows fonts dir and reinstalled the same fonts that were giving problems with \kappa (with these fonts installed, I get a hollow square instead of \kappa). Without the patch, \kappa was again a hollow square. However, after applying the patch, \kappa is still a hollow square. So the patch doesn't seem to be working. Initially, I thought that the problem was the addition of _LyX to the file names, so I removed it but nothing changed. I also ascertained that AddFontResourceEx rather than AddFontResource was being called and even tried rebooting. Just to be 100% sure, I also tried a mingw build and obtained the same result. -- Enrico
Re: Status of LyX 1.5.0?
On Tue, Jul 03, 2007 at 10:36:22PM +0200, Jean-Marc Lasgouttes wrote: Peter == Peter Kümmel [EMAIL PROTECTED] writes: Peter Jürgen Spitzmüller wrote: Abdelrazak Younes wrote: 3962 cri (Math) Font problems on Windows This one is a packaging issue right? No, AFAIU you need to replace AddFontRessource and RemoveFontRessourse in support/os_win32.spp with AddFontResourceEx and RemoveFontResourceEx. Peter Does attached patch solve the problem? Peter Both functions are not supported by older Window versions. Peter Therefore we have to decides at runtime which function to call. 1) I do not think that you need to rename the fonts and add _LyX when using AddFontResourceEx with FR_PRIVATE flag. That flag doesn't seem to do what the documentation says. I don't know whether Qt4 or Windows is to be blamed, but the patch by Peter doesn't work. 2) I thought we already had abandonned hope of running under windows 98? That was with Qt3, Qt4 is supposed to work with ME and 98. -- Enrico
Re: Status of LyX 1.5.0?
On Wed, Jul 04, 2007 at 06:53:10AM +0200, Peter Kümmel wrote: Enrico Forestieri wrote: On Tue, Jul 03, 2007 at 09:46:54PM +0200, Peter Kümmel wrote: Ok, here with the changes for cygwin, BUT I couldn't test it. And here is the result of my tests. I uninstalled the bakoma fonts from the Windows fonts dir and reinstalled the same fonts that were giving problems with \kappa (with these fonts installed, I get a hollow square instead of \kappa). Without the patch, \kappa was again a hollow square. However, after applying the patch, \kappa is still a hollow square. So the patch doesn't seem to be working. Initially, I thought that the problem was the addition of _LyX to the file names, so I removed it but nothing changed. I also ascertained that AddFontResourceEx rather than AddFontResource was being called and even tried rebooting. Just to be 100% sure, I also tried a mingw build and obtained the same result. As JMarc suggested, does it work when you rename the font file, and remove the _LyX from the patch? No, as I already tried to say. What is worse is that AddFontResource and AddFontResourceEx don't seem working with Qt4. Everything is ok only when the fonts are actually installed, otherwise they are not found. It puzzles me that in Qt3 it works alright, as demonstrated by LyX 1.4.4. This is what I get when using -dbg font in LyX 1.4.4: Looking for font family eufm10 ... raw: eufm10 alleged fi family: eufm10 got it normal! Looking for font family cmsy10 ... raw: cmsy10 alleged fi family: cmsy10 got it normal! Looking for font family cmmi10 ... raw: cmmi10 alleged fi family: cmmi10 got it normal! Looking for font family cmr10 ... raw: cmr10 alleged fi family: cmr10 got it normal! Looking for font family cmex10 ... raw: cmex10 alleged fi family: cmex10 got it normal! Looking for font family msam10 ... raw: msam10 alleged fi family: msam10 got it normal! Looking for font family msbm10 ... raw: msbm10 alleged fi family: msbm10 got it normal! Looking for font family wasy10 ... raw: wasy10 alleged fi family: wasy10 got it normal! and this is the result with 1.5.0svn: Looking for font family eufm10 ... got: MS Shell Dlg 2 Trying Eufm10 ... got: MS Shell Dlg 2 Trying -*-eufm10-medium-*-*-*-*-*-*-*-*-*-*-* ... got: MS Shell Dlg 2 FAILED :-( Looking for font family cmsy10 ... got: cmsy10 got it normal! Looking for font family cmmi10 ... got: cmmi10 got it normal! Looking for font family cmr10 ... got: cmr10 got it normal! Looking for font family cmex10 ... got: cmex10 got it normal! Looking for font family msam10 ... got: msam10 got it normal! Looking for font family msbm10 ... got: msbm10 got it normal! Looking for font family wasy10 ... got: MS Shell Dlg 2 Trying Wasy10 ... got: MS Shell Dlg 2 Trying -*-wasy10-medium-*-*-*-*-*-*-*-*-*-*-* ... got: MS Shell Dlg 2 FAILED :-( Looking for font family esint10 ... got: MS Shell Dlg 2 Trying Esint10 ... got: MS Shell Dlg 2 Trying -*-esint10-medium-*-*-*-*-*-*-*-*-*-*-* ... got: MS Shell Dlg 2 FAILED :-( Note that cmsy10, cmmi10, cmr10, cmex10, msam10, and msbm10 are *not* the bakoma fonts and they are installed in the Windows font directory. The fonts eufm10 and wasy10 are not installed but are added through AddFontResource, while esint10 doesn't exist. Qt3 is able to find and use eufm10 and wasy10, while Qt4 does not, apparently. -- Enrico
Re: Middle click to paste (Was: Status of LyX 1.5.0?)
On Wed, Jul 04, 2007 at 09:24:45AM +0200, [EMAIL PROTECTED] wrote: On Wed, 4 Jul 2007, Jürgen Spitzmüller wrote: [EMAIL PROTECTED] wrote: To be more serious, why should we restrict Windows users from functionality we appreciate elsewhere? Please read the whole thread: because the feature isn't implemented correctly and causes severe performance problems. I did catch a reference to that bit, but I felt someone should argue against things (roughly) like: * Windows users don't need unixy stuff So they don't need LyX? ;-) * No other Windows program does it like that This is not true. Gvim for Windows uses middle button to paste clipboard content, the way I would have liked LyX working. Having said that, a preference that allows a user to trade this functionality for performance would be fine by me for now. Nah, simply make the middle button work as Ctrl-v does. And, please, make it paste at the cursor and not mouse position, which is such a weird thing! -- Enrico
Re: Status of LyX 1.5.0?
On Wed, Jul 04, 2007 at 01:08:18PM +0200, Enrico Forestieri wrote: On Wed, Jul 04, 2007 at 06:53:10AM +0200, Peter Kümmel wrote: As JMarc suggested, does it work when you rename the font file, and remove the _LyX from the patch? No, as I already tried to say. What is worse is that AddFontResource and AddFontResourceEx don't seem working with Qt4. Everything is ok only when the fonts are actually installed, otherwise they are not found. It puzzles me that in Qt3 it works alright, as demonstrated by LyX 1.4.4. Now let me tell this story about this 32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition, often referred to as Windows. I tried LyX 1.4.5svn and, like 1.5.0svn, it was not able to find both eufm10 and wasy10. The only difference with 1.4.4 was that I was running it in place, but I had created the fonts dir in the source lib directory and populated it with the bakoma fonts, so it should have found them. So, I had a horrible suspect and in 1.5.0svn sources hardcoded the path to the bakoma fonts to the installed LyX 1.4.4 system directory. Well, you guess what, it worked. The fonts are used and the patch by Peter (without _LyX) works, too. I get the correct \kappa even with the other files named as the bakoma ones installed in the system font directory. It seems that once you have used AddFontResource to add a font file, you have no choice and cannot move them from the original position, otherwise they will not be found. I am really disgusted. So, all in all Peter, your patch works (take away _LyX), but the fonts cannot be moved from their original position! I think this is a problem when updating to a newer version on native Windows and the path changes from C:\Program Files\LyX14 to C:\Program Files\LyX15. Maybe the fonts should be installed to a fixed location, say C:\Program Files\Common Files\fonts or something like that. -- Enrico
Re: Status of LyX 1.5.0?
On Wed, Jul 04, 2007 at 04:31:55PM +0200, Jean-Marc Lasgouttes wrote: Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico It seems that once you have used AddFontResource to add a font Enrico file, you have no choice and cannot move them from the Enrico original position, otherwise they will not be found. I am Enrico really disgusted. Until you reboot, right? No, and this is most astonishing, the thing seems to survive a reboot. I tried to find whether the info is stored in the registry, but could not find anything. However, I investigated further and it turned out that what I said occurs on Vista but it does not occur on Win2k. Don't know about XP. Might it be that we do not remove the font where we should? We use RemoveFontResource at exit, but I don't know to what avail. With Qt4.2, we can also use QFontDatabase::addApplicationFont http://doc.trolltech.com/4.2/qfontdatabase.html#addApplicationFont Maybe this one would work. Anyway, if anybody can check whether WinXP behaves as Win2k, it seems to be a Vista related problem. -- Enrico
Re: issues installing/running lyx-1.5.0rc2
On Thu, Jul 05, 2007 at 03:40:20PM +0200, Jean-Marc Lasgouttes wrote:
Mikhail == Mikhail Teterin [EMAIL PROTECTED] writes:
Mikhail the right place for man-pages is under PREFIX/man (no share
Mikhail in between). I now have to add an explicit --mandir flag to
Mikhail configure. This was not an issue with LyX-1.4.4.
We do not do anything about that, and on my machine the mandir is
correctly set to prefix/man without any special intervention.
Strange...
This is due to the autoconf version. With autoconf = 2.59 you get:
mandir = ${prefix}/man
whereas with autoconf = 2.60 you will have:
datarootdir = ${prefix}/share
...
mandir = ${datarootdir}/man
--
Enrico
Re: Status of LyX 1.5.0?
On Thu, Jul 05, 2007 at 03:30:56PM +0200, Jean-Marc Lasgouttes wrote: Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico No, and this is most astonishing, the thing seems to survive a Enrico reboot. I tried to find whether the info is stored in the Enrico registry, but could not find anything. Enrico However, I investigated further and it turned out that what I Enrico said occurs on Vista but it does not occur on Win2k. Don't Enrico know about XP. I read somewhere that vista does not need fonts to be explicitly installed. So it is different from xp in this respect. No, I don't think so: http://blogs.msdn.com/michkap/archive/2006/08/27/726378.aspx and here: http://msdn2.microsoft.com/en-us/library/ms534231.aspx http://msdn2.microsoft.com/en-us/library/ms533937.aspx Vista is explicitely mentioned, so this is a bug on Vista. I can make AddFontResource(Ex) work only when I put the fonts in a precise location on disk, and given that this location is C:\cygwin\usr\local\share\lyx\fonts, i.e., the path where they got initially installed with lyx 1.4.4, I presume that once you used some fonts with those functions, you cannot move them somewhere else anymore. Even after a reboot. Ouch. However, I must say that this is not one of the most strange bugs or behaviors on Windows. For example, I learned that you cannot programmatically install fonts, because even if you copy them to the system font dir, they are not seen until after you open in explorer (the Windows file manager) the aforesaid font directory. Yes, exactly like that: copy the fonts in their place and then open the font directory in explorer (sic!). I think that without Cygwin I had already give up with Windows. -- Enrico
Re: Status of LyX 1.5.0?
On Wed, Jul 04, 2007 at 04:31:55PM +0200, Jean-Marc Lasgouttes wrote:
With Qt4.2, we can also use QFontDatabase::addApplicationFont
http://doc.trolltech.com/4.2/qfontdatabase.html#addApplicationFont
I tried this option (see attached patch). It works on Win2k and solves
the problem of having fonts with the same name as the bakoma ones in
the system font directory, but fails on Vista, where addApplicationFont
always returns -1.
However, pointing addApplicationFont to the the fonts of the installed
LyX 1.4.4, it succeeds. So, this seems to be the same bug afflicting
AddFontResource. Having spent some (too much) time on this problem,
I think I can say there is no way to solve it on Vista, the only
workaround being installing the bakoma fonts in the Windows font
directory.
--
Enrico
Index: src/frontends/qt4/GuiFontLoader.cpp
===
--- src/frontends/qt4/GuiFontLoader.cpp (revision 18990)
+++ src/frontends/qt4/GuiFontLoader.cpp (working copy)
@@ -21,8 +21,11 @@
#include support/filetools.h
#include support/lstrings.h
#include support/Systemcall.h
+#include support/Package.h
+#include support/os.h
#include qfontinfo.h
+#include QFontDatabase
#include boost/tuple/tuple.hpp
@@ -33,6 +36,9 @@
#endif
using lyx::support::contains;
+using lyx::support::package;
+using lyx::support::addPath;
+using lyx::support::addName;
using std::endl;
using std::make_pair;
@@ -41,6 +47,12 @@ using std::pair;
using std::vector;
using std::string;
+#if defined(Q_WS_WIN) QT_VERSION = 0x040200
+string const win_fonts_truetype[] = {cmex10, cmmi10, cmr10, cmsy10,
+ eufm10, msam10, msbm10, wasy10, esint10};
+const int num_fonts_truetype = sizeof(win_fonts_truetype) /
sizeof(*win_fonts_truetype);
+#endif
+
namespace lyx {
namespace frontend {
@@ -189,6 +201,19 @@ pairQFont, bool const getSymbolFont(st
GuiFontLoader::GuiFontLoader()
{
+#if defined(Q_WS_WIN) QT_VERSION = 0x040200
+ string const fonts_dir =
addPath(package().system_support().absFilename(), fonts);
+
+ for (int i = 0 ; i num_fonts_truetype ; ++i) {
+ string const font_file = lyx::support::os::external_path(
+ addName(fonts_dir, win_fonts_truetype[i] + .ttf));
+ fontID[i] =
QFontDatabase::addApplicationFont(toqstr(font_file));
+ LYXERR(Debug::FONT) Adding font font_file
+static_castconst char *
+ (fontID[i] 0 ? FAIL : OK)
+endl;
+ }
+#endif
for (int i1 = 0; i1 Font::NUM_FAMILIES; ++i1)
for (int i2 = 0; i2 2; ++i2)
for (int i3 = 0; i3 4; ++i3)
@@ -197,6 +222,17 @@ GuiFontLoader::GuiFontLoader()
}
+GuiFontLoader::~GuiFontLoader()
+{
+#if defined(Q_WS_WIN) QT_VERSION = 0x040200
+ for (int i = 0 ; i num_fonts_truetype ; ++i) {
+ if (fontID[i] = 0)
+ QFontDatabase::removeApplicationFont(fontID[i]);
+ }
+#endif
+}
+
+
void GuiFontLoader::update()
{
for (int i1 = 0; i1 Font::NUM_FAMILIES; ++i1)
Index: src/frontends/qt4/GuiFontLoader.h
===
--- src/frontends/qt4/GuiFontLoader.h (revision 18990)
+++ src/frontends/qt4/GuiFontLoader.h (working copy)
@@ -47,7 +47,7 @@ public:
GuiFontLoader();
/// Destructor
- virtual ~GuiFontLoader() {}
+ ~GuiFontLoader();
virtual void update();
virtual bool available(Font const f);
@@ -75,6 +75,8 @@ public:
private:
/// BUTT ugly !
QLFontInfo * fontinfo_[Font::NUM_FAMILIES][2][4][10];
+
+ int fontID[10];
};
Re: Status of LyX 1.5.0?
On Fri, Jul 06, 2007 at 12:48:10AM +0200, Enrico Forestieri wrote: On Wed, Jul 04, 2007 at 04:31:55PM +0200, Jean-Marc Lasgouttes wrote: With Qt4.2, we can also use QFontDatabase::addApplicationFont http://doc.trolltech.com/4.2/qfontdatabase.html#addApplicationFont I tried this option (see attached patch). It works on Win2k and solves the problem of having fonts with the same name as the bakoma ones in the system font directory, but fails on Vista, where addApplicationFont always returns -1. However, pointing addApplicationFont to the the fonts of the installed LyX 1.4.4, it succeeds. So, this seems to be the same bug afflicting AddFontResource. Having spent some (too much) time on this problem, I think I can say there is no way to solve it on Vista, the only workaround being installing the bakoma fonts in the Windows font directory. Being Windows ... well ... Windows (no need to say more), I think I should not be surprised. This one I think should be added to the old wives' tales about it. Please, have a look at what I obtain with the above patch applied: $ ./src/lyx-qt4.exe -dbg font Setting debug level to font Debugging `font' (Font handling) Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/cmex10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/cmmi10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/cmr10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/cmsy10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/eufm10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/msam10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/msbm10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/wasy10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/esint10.ttf FAIL $ chmod a+x /usr/local/src/lyx/lyx-devel/lib/fonts/*.ttf $ ./src/lyx-qt4.exe -dbg font Setting debug level to font Debugging `font' (Font handling) Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/cmex10.ttf OK Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/cmmi10.ttf OK Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/cmr10.ttf OK Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/cmsy10.ttf OK Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/eufm10.ttf OK Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/msam10.ttf OK Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/msbm10.ttf OK Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/wasy10.ttf OK Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/esint10.ttf FAIL $ chmod a-x /usr/local/src/lyx/lyx-devel/lib/fonts/*.ttf $ ./src/lyx-qt4.exe -dbg font Setting debug level to font Debugging `font' (Font handling) Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/cmex10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/cmmi10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/cmr10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/cmsy10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/eufm10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/msam10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/msbm10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/wasy10.ttf FAIL Adding font /usr/local/src/lyx/lyx-devel/lib/fonts/esint10.ttf FAIL I can't believe it! The font files must have the executable flag set, otherwise they are not found. But why, my god, why? However, there must be more to it, as when I look at the fonts installed with LyX 1.4.4 I don't see the executable flag set: $ ls -lG /usr/local/share/lyx/fonts/eufm10.ttf -rw-r-+ 1 root 23744 Jul 12 2006 /usr/local/share/lyx/fonts/eufm10.ttf but notice that '+' there, meaning that the file has an ACL attached: $ getfacl /usr/local/share/lyx/fonts/eufm10.ttf # file: /usr/local/share/lyx/fonts/eufm10.ttf # owner: root # group: users user::rw- group::r-- group:SYSTEM:rwx group:administrators:rwx mask:rwx other:--- These ACLs were set up by the cygwin installation tool, which surely knows more than me about Windows, but even when I copy them using $ getfacl source_file | setfacl -f - target_file the files are not found. Most probably, in this case all the path components should have a proper ACL. Windows really drives me mad. However, I will stick with the executable flag set, which seems working. And for the sake of my sanity, I will not try to find a logical explanation. This is Windows, after all... -- Enrico
Re: Status of LyX 1.5.0?
On Thu, Jul 05, 2007 at 05:23:52PM +0200, Enrico Forestieri wrote: On Thu, Jul 05, 2007 at 03:30:56PM +0200, Jean-Marc Lasgouttes wrote: Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico No, and this is most astonishing, the thing seems to survive a Enrico reboot. I tried to find whether the info is stored in the Enrico registry, but could not find anything. Enrico However, I investigated further and it turned out that what I Enrico said occurs on Vista but it does not occur on Win2k. Don't Enrico know about XP. I read somewhere that vista does not need fonts to be explicitly installed. So it is different from xp in this respect. No, I don't think so: http://blogs.msdn.com/michkap/archive/2006/08/27/726378.aspx and here: http://msdn2.microsoft.com/en-us/library/ms534231.aspx http://msdn2.microsoft.com/en-us/library/ms533937.aspx Vista is explicitely mentioned, so this is a bug on Vista. I can make AddFontResource(Ex) work only when I put the fonts in a precise location on disk, and given that this location is C:\cygwin\usr\local\share\lyx\fonts, i.e., the path where they got initially installed with lyx 1.4.4, I presume that once you used some fonts with those functions, you cannot move them somewhere else anymore. Even after a reboot. Ouch. Just for the records, I discovered that the font files must have the executable flag set, otherwise they are not found, unless they and all of their path components have proper ACLs. However, I can only guarantee that this happens on thursday with a full moon. Don't know in other conditions... -- Enrico
Re: Towards LyX 1.4.5 [status update #1]
On Fri, Jul 06, 2007 at 01:23:48PM +0200, Jean-Marc Lasgouttes wrote: Hello, Since Jose' plans to release 1.5.0 next week, we'd better be ready with 1.4.5 too. I append the ANNOUNCE file that I just updated. Jose', I would appreciate if you could upgrade lyx2lyx in branch to handle the 1.5 final format. Other things? I think that the patch by Peter dealing with duplicate font names in the system font dir should also be applied to 1.4.5. -- Enrico
Re: r19001 - in /lyx-devel/trunk/src/support: lstrings.cpp ls...
On Fri, Jul 06, 2007 at 04:50:17PM +0200, Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
Author: younes
Date: Fri Jul 6 16:43:18 2007
New Revision: 19001
URL: http://www.lyx.org/trac/changeset/19001
Log:
* lstring.cpp:
- isAscii(): char is signed with MSVC so the comparison was not correct.
Add a static_cast to unsigned char as per the other methods.
I took the liberty to commit this fix as it is obviously correct and
would have bitten us sooner than later.
Abdel, I really wonder if you know what you are doing. Please, try
to compile and launch the attached C++ source.
--
Enrico
#include iostream
using namespace std;
int main()
{
for (int i = 128; i 1000; ++i) {
if (static_castunsigned char(i) = 0x80)
continue;
cout Surprise! i is less than 128. endl;
}
}
Caught normal exception: St8bad_cast
This happens on Windows, I don't get it on Linux. After 1) File-New 2) Document-Settings LyX crashes with the message Caught normal exception: St8bad_cast I verified that this is a consequence of http://www.lyx.org/trac/changeset/18991 Any idea? -- Enrico
Re: Caught normal exception: St8bad_cast
On Sat, Jul 07, 2007 at 04:52:02PM +0200, Enrico Forestieri wrote: This happens on Windows, I don't get it on Linux. After 1) File-New 2) Document-Settings LyX crashes with the message Caught normal exception: St8bad_cast I verified that this is a consequence of http://www.lyx.org/trac/changeset/18991 Sorry, I meant that this is in consequence of http://www.lyx.org/trac/changeset/18988 (note that the correct bug number mentioned there is 2738) I am surprised that nobody still noticed it, so maybe this is only a problem with gcc on Windows? -- Enrico
Re: Crash only in recent SVN on FreeBSD
On Sun, Jul 08, 2007 at 02:13:41AM +0900, Koji Yokota wrote: Hi, Only recently lyx-svn begins to crash when I open some of menus on a FreeBSD machine (I confirmed on revision 19004). Is this only a temporary phenomenon to be fixed soon? If so, please neglect this mail. Lyx crashes, for example, when I open Tools - Preferences, with error messages: LyXFunc::dispatch: cmd: action: 225 arg: 'prefs' x: 0 y: 0 Setting controller ro: 1 Transition from state INITIAL to state INITIAL after input SMI_READ_ONLY Calling BC refresh() addCategory n= User interface parent= addCategory n= Look and feel parent= addCategory n= Screen fonts parent= addCategory n= Colors parent= addCategory n= Graphics parent= addCategory n= Keyboard parent= addCategory n= Paths parent= addCategory n= Identity parent= terminate called after throwing an instance of 'std::bad_cast' what(): St8bad_cast Abort. This is another consequence of http://www.lyx.org/trac/changeset/18988. Try whether reverting that changeset helps. I think that the problem here is a missing locale facet. -- Enrico
Re: Crash only in recent SVN on FreeBSD
On Sat, Jul 07, 2007 at 07:40:23PM +0200, Alfredo Braunstein wrote:
Wild guess: does the following helps?
No, sorry.
Index: frontends/controllers/frontend_helpers.cpp
===
--- frontends/controllers/frontend_helpers.cpp(revision 19003)
+++ frontends/controllers/frontend_helpers.cpp(working copy)
@@ -1108,7 +1108,7 @@
LanguagePair, bool
{
public:
- Sorter() : loc_() {};
+ Sorter() : loc_() {};
bool operator()(LanguagePair const lhs,
LanguagePair const rhs) const {
return loc_(lhs.first, rhs.first);
--
Enrico
Re: Crash only in recent SVN on FreeBSD
On Sun, Jul 08, 2007 at 03:29:46AM +0900, Koji Yokota wrote: Enrico Forestieri wrote: This is another consequence of http://www.lyx.org/trac/changeset/18988. Try whether reverting that changeset helps. Yes, I identified that reverting it removes the problem. I was sure that that was the problem in your case, too. I think that the problem here is a missing locale facet. Indeed, lyx always compains Locale ja_JP could not be set Locale en_US could not be set No, these are not related. These warnings mean that you don't have support for those locales. but crash also happens when I start it with env LC_ALL=C lyx In this case, there are no such complaints. Yes, the C locale is always supported. The crash is due to missing support for wchar_t, meaning that even the C locale can't deal with wide characters. Please try the patch I sent you. -- Enrico
Re: Crash only in recent SVN on FreeBSD
On Sat, Jul 07, 2007 at 08:37:15PM +0200, Enrico Forestieri wrote:
On Sun, Jul 08, 2007 at 03:29:46AM +0900, Koji Yokota wrote:
but crash also happens when I start it with
env LC_ALL=C lyx
In this case, there are no such complaints.
Yes, the C locale is always supported. The crash is due to missing
support for wchar_t, meaning that even the C locale can't deal with
wide characters. Please try the patch I sent you.
Strange. I still don't see on the list the mail with the patch, so
I am resending it attached here.
--
Enrico
Index: src/frontends/controllers/frontend_helpers.cpp
===
--- src/frontends/controllers/frontend_helpers.cpp (revision 19004)
+++ src/frontends/controllers/frontend_helpers.cpp (working copy)
@@ -,7 +,11 @@ public:
Sorter() : loc_() {};
bool operator()(LanguagePair const lhs,
LanguagePair const rhs) const {
+#if !defined(USE_WCHAR_T) defined(__GNUC__)
+ return loc_(to_local8bit(lhs.first), to_local8bit(rhs.first));
+#else
return loc_(lhs.first, rhs.first);
+#endif
}
private:
std::locale loc_;
Re: Crash only in recent SVN on FreeBSD
On Sun, Jul 08, 2007 at 04:22:29AM +0900, Koji Yokota wrote:
Enrico Forestieri wrote:
On Sat, Jul 07, 2007 at 08:37:15PM +0200, Enrico Forestieri wrote:
On Sun, Jul 08, 2007 at 03:29:46AM +0900, Koji Yokota wrote:
but crash also happens when I start it with
env LC_ALL=C lyx
In this case, there are no such complaints.
Yes, the C locale is always supported. The crash is due to missing
support for wchar_t, meaning that even the C locale can't deal with
wide characters. Please try the patch I sent you.
Strange. I still don't see on the list the mail with the patch, so
I am resending it attached here.
Indeed the problem seems around here. The patch solved the problem when
I start lyx with LC_ALL=C.
However, when it is started with ja_JP locale for example, it still
crashes with complaints:
terminate called after throwing an instance of 'std::runtime_error'
what(): locale::facet::_S_create_c_locale name not valid
Abort (damped core)
A little more modification may be necessary.
This occurs when the locale itself is not supported and I also get it
on cygwin. Please, try the attached patch, which should definitely
solve the issue.
--
Enrico
Index: src/frontends/controllers/frontend_helpers.cpp
===
--- src/frontends/controllers/frontend_helpers.cpp (revision 18988)
+++ src/frontends/controllers/frontend_helpers.cpp (working copy)
@@ -1108,6 +1108,12 @@ class Sorter
LanguagePair, bool
{
public:
+#if !defined(USE_WCHAR_T) defined(__GNUC__)
+ bool operator()(LanguagePair const lhs,
+ LanguagePair const rhs) const {
+ return lhs.first rhs.first;
+ }
+#else
Sorter() : loc_() {};
bool operator()(LanguagePair const lhs,
LanguagePair const rhs) const {
@@ -1115,6 +1121,7 @@ public:
}
private:
std::locale loc_;
+#endif
};
} // namespace anon
Re: Crash only in recent SVN on FreeBSD
On Mon, Jul 09, 2007 at 10:51:15AM +0100, José Matos wrote: On Sunday 08 July 2007 18:10:37 Koji Yokota wrote: Yap, it solved the problem. Thank you!! OK Enrico you can commit the patch. Done. -- Enrico
Re: Fwd: readme updates
On Mon, Jul 09, 2007 at 01:01:21PM +0200, Jean-Marc Lasgouttes wrote: Pavel == Pavel Sanda [EMAIL PROTECTED] writes: Pavel Sanda schrieb: For the patch to readme.localization, could you please send this as separate patch to the devel list for approval. i wonder what is this list for then :) I'm only unsure if I'm allowed to commit anything else than docs and po files because of the release freeze we are in. Your changes are reasonable I just want to have the OK from someone else. regards Uwe Pavel please see the attached patch pavel Looks good to me except maybe: - On Linux: LANG=xx_CC lyx + On Linux: export LANG=xx_CC lyx I do not thing the 'export' is needed. Does it change something for you? (when typing all in the same line) I would use env in place of export, such that it works whatever the shell used. -- Enrico
Re: Towards LyX 1.4.5 [status update #1]
On Fri, Jul 06, 2007 at 04:31:24PM +0200, Enrico Forestieri wrote:
On Fri, Jul 06, 2007 at 01:23:48PM +0200, Jean-Marc Lasgouttes wrote:
Hello,
Since Jose' plans to release 1.5.0 next week, we'd better be ready
with 1.4.5 too. I append the ANNOUNCE file that I just updated.
Jose', I would appreciate if you could upgrade lyx2lyx in branch to
handle the 1.5 final format.
Other things?
I think that the patch by Peter dealing with duplicate font names
in the system font dir should also be applied to 1.4.5.
Here it is. I verified that with the patch applied one can have fonts
with the same name as the Bakoma ones installed in the system font dir
and yet the latter are used in LyX.
--
Enrico
Index: src/frontends/qt2/qfont_loader.C
===
--- src/frontends/qt2/qfont_loader.C(revision 19013)
+++ src/frontends/qt2/qfont_loader.C(working copy)
@@ -52,7 +52,9 @@ using std::string;
#endif
#ifdef Q_WS_WIN
-#include windows.h
+// Require Windows API Win98 (only needed for AddFontResourceEx)
+#define _WIN32_WINNT 0x0500
+#include windows.h
#include support/os.h
#include support/package.h
#include support/path.h
@@ -100,9 +102,9 @@ void FontLoader::initFontPath()
string const fonts_dir = AddPath(package().system_support(), fonts);
for (int i = 0 ; i num_fonts_truetype ; ++i) {
- string const font_current =
- AddName(fonts_dir, win_fonts_truetype[i] + .ttf);
- AddFontResource(os::external_path(font_current).c_str());
+ string const font_current = os::external_path(
+ AddName(fonts_dir, win_fonts_truetype[i] + .ttf));
+ AddFontResourceEx(font_current.c_str(), FR_PRIVATE, 0);
}
#endif
}
@@ -113,9 +115,9 @@ FontLoader::~FontLoader() {
string const fonts_dir = AddPath(package().system_support(), fonts);
for(int i = 0 ; i num_fonts_truetype ; ++i) {
- string const font_current =
- AddName(fonts_dir, win_fonts_truetype[i] + .ttf);
- RemoveFontResource(os::external_path(font_current).c_str());
+ string const font_current = os::external_path(
+ AddName(fonts_dir, win_fonts_truetype[i] + .ttf));
+ RemoveFontResourceEx(font_current.c_str(), FR_PRIVATE, 0);
}
#endif
}
Re: Towards LyX 1.4.5 [status update #1]
On Mon, Jul 09, 2007 at 07:34:03PM +0200, Joost Verburg wrote: Enrico Forestieri wrote: Here it is. I verified that with the patch applied one can have fonts with the same name as the Bakoma ones installed in the system font dir and yet the latter are used in LyX. I just made LyX 1.5 support Windows 98/Me, so this patch needs to be changed to work on Windows versions without support for AddFontResourceEx. This is a patch for LyX 1.4.5, which already doesn't run on Win98... -- Enrico
Re: Towards LyX 1.4.5 [status update #1]
On Mon, Jul 09, 2007 at 10:48:32PM +0200, Jean-Marc Lasgouttes wrote: Enrico == Enrico Forestieri [EMAIL PROTECTED] writes: Enrico Here it is. I verified that with the patch applied one can Enrico have fonts with the same name as the Bakoma ones installed in Enrico the system font dir and yet the latter are used in LyX. I'll apply it tomorrow (is there a bug number?) Bug 3962. Note that the call to RemoveFontResourceEx is probably not necessary: FR_PRIVATESpecifies that only the process that called the AddFontResourceEx function can use this font. When the font name matches a public font, the private font will be chosen. When the process terminates, the system will remove all fonts installed by the process with the AddFontResourceEx function. Nevertheless, I think that it is a good policy to cleanup by ourselves, unless you want to get rid of the destructor. -- Enrico
Re: Status of LyX 1.5.0?
On Tue, Jul 10, 2007 at 09:40:38PM +0200, Peter Kümmel wrote: Here an updated patch which only calls the Ex functions if they are available. And what was the status? It doesn't work on Vista? And also needs some chmod changes on cygwin? The patch works on Vista. However, for some inexplicable reason the font files must have the executable flag set. I only found this explanation: http://cygwin.com/ml/cygwin/2005-11/msg00100.html hinting that the executable flag means more than just execution in Windows. This is not cygwin related, though. I incurred in this bug only because the cygwin svn did not set the executable flag on the files in lib/fonts. When the fonts are installed through the NSIS or cygwin installation tools, everything is fine, seemingly. -- Enrico
Re: r19028 - in /lyx-devel/branches/BRANCH_1_4_X: src/fronten...
On Wed, Jul 11, 2007 at 12:14:29AM +0200, Joost Verburg wrote: Abdelrazak Younes wrote: 1) you have a patch ready using LoadLibrary/GetProcAddress before tomorrow: 1.5.0 will support Win9X! Here is the patch. I tested it and it works for me. Hmm. Seems that you and Peter are treading on each other's toes. The patch by Peter seems to be more comprehensive, though... -- Enrico
Re: Status of LyX 1.5.0?
On Wed, Jul 11, 2007 at 07:12:42AM +0200, Peter Kümmel wrote: Enrico Forestieri wrote: On Tue, Jul 10, 2007 at 09:40:38PM +0200, Peter Kümmel wrote: Here an updated patch which only calls the Ex functions if they are available. And what was the status? It doesn't work on Vista? And also needs some chmod changes on cygwin? The patch works on Vista. However, for some inexplicable reason the font files must have the executable flag set. I only found this explanation: http://cygwin.com/ml/cygwin/2005-11/msg00100.html hinting that the executable flag means more than just execution in Windows. This is not cygwin related, though. I incurred in this bug only because the cygwin svn did not set the executable flag on the files in lib/fonts. When the fonts are installed through the NSIS or cygwin installation tools, everything is fine, seemingly. Isn't this stuff for the installer? But we could also set the flags in os_win32/os_cgwin, but I can't do it before this evening. The installers get it right, indeed. No need to do anything as I was experiencing the problem only when running LyX in place. Therefore, if LyX is really released today and we use my patch, then someone should just commit it. Maybe we should move the common code into a new file, os_win.cpp, and include this one in the other two files. I think that the patch by Joost is more compact. I am just complementing it with the changes for cygwin and then will send it to the list. -- Enrico
Re: r19028 - in /lyx-devel/branches/BRANCH_1_4_X: src/fronten...
On Wed, Jul 11, 2007 at 09:14:27AM +0200, Joost Verburg wrote:
Peter Kümmel wrote:
What about using my patch and to replace the QLibrary code with your
native calls?
I think using native calls is safer. This is the standard method that is
known to work on all Windows versions. You should not use #define
_WIN32_WINNT 0x0500 because it may cause other include files (like
boost) to think Windows 2000 functions can be used.
Please, find attached your patch complemented with the changes
for cygwin.
--
Enrico
Index: src/support/os_cygwin.cpp
===
--- src/support/os_cygwin.cpp (revision 19033)
+++ src/support/os_cygwin.cpp (working copy)
@@ -40,6 +40,11 @@ using lyx::support::addName;
using lyx::support::addPath;
using lyx::support::package;
+// API definition for manually calling font functions on Windows 2000 and later
+typedef int (WINAPI *FONTAPI)(LPCSTR, DWORD, PVOID);
+#define FR_PRIVATE 0x10
+
+// Names of TrueType fonts to load
string const win_fonts_truetype[] = {cmex10, cmmi10, cmr10, cmsy10,
eufm10, msam10, msbm10, wasy10, esint10};
const int num_fonts_truetype = sizeof(win_fonts_truetype) /
sizeof(*win_fonts_truetype);
@@ -330,12 +335,23 @@ void addFontResources()
// Windows only: Add BaKoMa TrueType font resources
string const fonts_dir =
addPath(package().system_support().absFilename(), fonts);
+ HMODULE hDLL = LoadLibrary(gdi32);
+ FONTAPI pAddFontResourceEx =
+ (FONTAPI) GetProcAddress(hDLL, AddFontResourceExA);
+
for (int i = 0 ; i num_fonts_truetype ; ++i) {
string const font_current = to_local8bit(from_utf8(convert_path(
addName(fonts_dir, win_fonts_truetype[i] + .ttf),
PathStyle(windows;
- AddFontResource(font_current.c_str());
+ if (pAddFontResourceEx) {
+ // Windows 2000 and later: Use AddFontResourceEx
+ pAddFontResourceEx(font_current.c_str(), FR_PRIVATE, 0);
+ } else {
+ // Older Windows versions: Use AddFontResource
+ AddFontResource(font_current.c_str());
+ }
}
+ FreeLibrary(hDLL);
#endif
}
@@ -346,12 +362,22 @@ void restoreFontResources()
// Windows only: Remove BaKoMa TrueType font resources
string const fonts_dir =
addPath(package().system_support().absFilename(), fonts);
+ HMODULE hDLL = LoadLibrary(gdi32);
+ FONTAPI pRemoveFontResourceEx = (FONTAPI) GetProcAddress(hDLL,
RemoveFontResourceExA);
+
for(int i = 0 ; i num_fonts_truetype ; ++i) {
string const font_current = to_local8bit(from_utf8(convert_path(
addName(fonts_dir, win_fonts_truetype[i] + .ttf),
PathStyle(windows;
- RemoveFontResource(font_current.c_str());
+ if (pRemoveFontResourceEx) {
+ // Windows 2000 and later: Use RemoveFontResourceEx
+ pRemoveFontResourceEx(font_current.c_str(), FR_PRIVATE,
0);
+ } else {
+ // Older Windows versions: Use RemoveFontResource
+ RemoveFontResource(font_current.c_str());
+ }
}
+ FreeLibrary(hDLL);
#endif
}
Index: src/support/os_win32.cpp
===
--- src/support/os_win32.cpp(revision 19033)
+++ src/support/os_win32.cpp(working copy)
@@ -74,6 +74,11 @@ using lyx::support::addName;
using lyx::support::addPath;
using lyx::support::package;
+// API definition for manually calling font functions on Windows 2000 and later
+typedef int (WINAPI *FONTAPI)(LPCSTR, DWORD, PVOID);
+#define FR_PRIVATE 0x10
+
+// Names of TrueType fonts to load
string const win_fonts_truetype[] = {cmex10, cmmi10, cmr10, cmsy10,
eufm10, msam10, msbm10, wasy10, esint10};
const int num_fonts_truetype = sizeof(win_fonts_truetype) /
sizeof(*win_fonts_truetype);
@@ -408,11 +413,22 @@ void addFontResources()
// Windows only: Add BaKoMa TrueType font resources
string const fonts_dir =
addPath(package().system_support().absFilename(), fonts);
+ HMODULE hDLL = LoadLibrary(gdi32);
+ FONTAPI pAddFontResourceEx = (FONTAPI) GetProcAddress(hDLL,
AddFontResourceExA);
+
for (int i = 0 ; i num_fonts_truetype ; ++i) {
string const font_current =
addName(fonts_dir, win_fonts_truetype[i] + .ttf);
-
AddFontResource(to_local8bit(from_utf8(external_path(font_current))).c_str());
+ if (pAddFontResourceEx) {
+ // Windows 2000 and later: Use AddFontResourceEx for
private font
+
pAddFontResourceEx(to_local8bit(from_utf8(external_path(font_current))).c_str(),
Re: r19028 - in /lyx-devel/branches/BRANCH_1_4_X: src/fronten...
On Wed, Jul 11, 2007 at 10:56:07AM +0100, José Matos wrote: On Wednesday 11 July 2007 10:25:44 Enrico Forestieri wrote: Please, find attached your patch complemented with the changes for cygwin. This can go with two OKs. I guess that Joost, Uwe, Peter or Abdel are the obvious candidates. I think that this can go in, then. Indeed, this is simply an extension to cygwin of the patch by Joost which I tried and found working. Peter agreed to use this patch with the extension I made (use Joost method in his patch). So, me, Peter, and Joost are endorsing this patch. That makes 3 crossed OKs ;-) -- Enrico
Re: r19028 - in /lyx-devel/branches/BRANCH_1_4_X: src/fronten...
On Wed, Jul 11, 2007 at 12:08:06PM +0200, Abdelrazak Younes wrote: Joost Verburg wrote: José Matos wrote: On Wednesday 11 July 2007 10:25:44 Enrico Forestieri wrote: Please, find attached your patch complemented with the changes for cygwin. This can go with two OKs. I guess that Joost, Uwe, Peter or Abdel are the obvious candidates. OK. I don't know much about Win32 API but the code seems correct to me. I trust Enrico and Joost about this. As too many cooks are working on it, I think that some coordination is needed ;-) So, please Joost go ahead and commit it. -- Enrico
Re: r19028 - in /lyx-devel/branches/BRANCH_1_4_X: src/fronten...
On Wed, Jul 11, 2007 at 12:23:18PM +0200, Abdelrazak Younes wrote: Enrico Forestieri wrote: On Wed, Jul 11, 2007 at 12:08:06PM +0200, Abdelrazak Younes wrote: Joost Verburg wrote: José Matos wrote: On Wednesday 11 July 2007 10:25:44 Enrico Forestieri wrote: Please, find attached your patch complemented with the changes for cygwin. This can go with two OKs. I guess that Joost, Uwe, Peter or Abdel are the obvious candidates. OK. I don't know much about Win32 API but the code seems correct to me. I trust Enrico and Joost about this. As too many cooks are working on it, I think that some coordination is needed ;-) Then you are not a good coordinator ;-). It's simpler for the last who touched the patch to commit it, so that should be you :-) So, in the end I did it... -- Enrico
Re: Exception when opening Document-settings on Solaris
On Wed, Jul 11, 2007 at 03:59:51PM +0200, Pavel Sanda wrote:
All is OK with 1.5.0rc2, but with 1.5.0-svn,
when I want to edit the settings of a template document
on Solaris 2.8/Qt4.3.1, I get this:
Caught normal exception: locale::facet::_S_create_c_locale name not valid
could not be this somehow related to
http://bugzilla.lyx.org/show_bug.cgi?id=2738
(ie does it happen before 18988 changeset) ?
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.
--
Enrico
Index: src/frontends/controllers/frontend_helpers.cpp
===
--- src/frontends/controllers/frontend_helpers.cpp (revision 19044)
+++ src/frontends/controllers/frontend_helpers.cpp (working copy)
@@ -1108,7 +1108,7 @@
LanguagePair, bool
{
public:
-#if !defined(USE_WCHAR_T) defined(__GNUC__)
+#if defined(__GNUC__) (!defined(USE_WCHAR_T) || __GNUC__ 4)
bool operator()(LanguagePair const lhs,
LanguagePair const rhs) const {
return lhs.first rhs.first;
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
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
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: 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: 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: Exception when opening Document-settings on Solaris
On Thu, Jul 12, 2007 at 05:18:04PM +0100, José Matos wrote: On Thursday 12 July 2007 16:51:55 Jürgen Spitzmüller wrote: For 1.5.0, I propose the attached. Jürgen OK then. Enrico earlier agreed with this and then we will have more time to fix this properly. Please, wait a minute. I have another option. -- Enrico
Re: Exception when opening Document-settings on Solaris
On Thu, Jul 12, 2007 at 06:32:28PM +0200, Jürgen Spitzmüller wrote:
Enrico Forestieri wrote:
Please, wait a minute. I have another option.
too late.
No problem. The attached patch should solve the problems related
to sorting according to the locale rules. I think that there is
no other way. When a locale is not installed, normal ordering
through is performed, otherwise the locale rules are obeyed.
The crash you were having with LANG=en_EN was probably due to the
fact that you don't have that locale installed. If you install it,
the crash disappears. This patch accounts for this case, too, i.e.,
if you don't have a locale, you get normal ordering, but after you
install it, you can have that locale ordering.
Only the poor systems which don't have support for wchar_t are left
in the cold. And before you ask, yes this also accounts for the missing
facets in GCC 3.
--
Enrico
Index: src/frontends/controllers/frontend_helpers.cpp
===
--- src/frontends/controllers/frontend_helpers.cpp (revision 19061)
+++ src/frontends/controllers/frontend_helpers.cpp (working copy)
@@ -1108,21 +1108,31 @@ class Sorter
LanguagePair, bool
{
public:
-#if 1//defined(__GNUC__) (!defined(USE_WCHAR_T) || __GNUC__ 4)
+#if !defined(USE_WCHAR_T) defined(__GNUC__)
bool operator()(LanguagePair const lhs,
LanguagePair const rhs) const {
return lhs.first rhs.first;
}
#else
-// this is supposed to fix bug 2738, but it is not stable yet
-// see http://bugzilla.lyx.org/show_bug.cgi?id=2738
- Sorter() : loc_() {};
+ Sorter() : loc_ok(true)
+ {
+ try {
+ loc_ = std::locale();
+ } catch (...) {
+ loc_ok = false;
+ }
+ };
+
bool operator()(LanguagePair const lhs,
LanguagePair const rhs) const {
- return loc_(lhs.first, rhs.first);
+ if (loc_ok)
+ return loc_(lhs.first, rhs.first);
+ else
+ return lhs.first rhs.first;
}
private:
std::locale loc_;
+ bool loc_ok;
#endif
};
Re: Exception when opening Document-settings on Solaris
On Thu, Jul 12, 2007 at 05:36:03PM +0100, José Matos wrote: On Thursday 12 July 2007 17:26:54 Enrico Forestieri wrote: I have another option. Tell us more. :-) The exception is thrown by the locale constructor, not when the ordering is performed. So, we catch it there and then either use the locale facilities or the normal ordering. See patch in the other post. -- Enrico
Re: Exception when opening Document-settings on Solaris
On Thu, Jul 12, 2007 at 07:16:45PM +0200, Jürgen Spitzmüller wrote: José Matos wrote: I saw the patch and I agree with the way it is done. This time though I will be on the safe side (read chicken) and I would suggest to delay this for 1.5.1. OK? I was about to say the same. The patch looks correct, but the bug is not too crucial to get it in urgently. No problem with me. Anyway, I already tested it on three different systems, so I am confident that it works ;-) -- Enrico
Re: [patch] bug 1820 --- footnotes in different language
On Thu, Jul 12, 2007 at 09:19:15PM +0300, Dov Feldstern wrote:
What the patch is trying to fix is the case where a language switch was
being missed, for example in the following situation:
document language is english
\lang english
bla bla bla
\lang hebrew
BLA BLA BLA
\footnote
\lang english
bla bla bla
The marked language switch was being missed, because LyX was assuming
the language at the beginning of a new paragraph is either the language
of the previous paragraph, or if there is none, the language of the
document. However, inside the inset, paragraph count start at 0 again
--- so there's no previous paragraph, so LyX assumes the current
language is english, and therefore decides that the \lang english
command is unnecessary upon entering the inset. LyX is wrong, however:
as far as latex is concerned, upon entering the footnote, the current
language is hebrew, and therefore to input english, it *is* necessary to
include the \lang english command inside the footnote...
So that's what I'm trying to solve. The problem is, I may be breaking
other, similar, situations...
Dov,
this is what I did. Without your patch applied, I started a new
document, so the language is english, and then activated View Source.
I wrote bla bla bla , then switched the language to italian and wrote
BLA BLA BLA. Now I inserted a footnote and wrote bla bla bla.
At this point, this is what I saw in the LaTeX Source window:
(Point 1a)
bla bla bla \foreignlanguage{italian}{BLA BLA BLA}%
\footnote{\selectlanguage{italian}
bla bla bla\selectlanguage{english}
%
}
Now I pressed backspace until I deleted the last bla bla bla I wrote.
The following is what the LaTeX Source window was showing at this point:
(Point 2a)
bla bla bla \foreignlanguage{italian}{BLA BLA BLA}%
\footnote{%
}
Writing again bla bla bla, I got:
(Point 3a)
bla bla bla \foreignlanguage{italian}{BLA BLA BLA}%
\footnote{bla bla bla%
}
which lacks the \selectlanguage commands, meaning that I obtain different
results after backspacing and writing again!
Now I applied your patch and repeated the previous steps. The results I
was getting at the same points as before, are the following:
(Point 1b)
bla bla bla \foreignlanguage{italian}{BLA BLA BLA}%
\footnote{bla bla bla\selectlanguage{english}
%
}
Note that a \selectlanguage{italian} is missing here wrt Point 1a.
(Point 2b)
bla bla bla \foreignlanguage{italian}{BLA BLA BLA}%
\footnote{\selectlanguage{english}
%
}
Note that a \selectlanguage{english} is still here wrt Point 2a.
(Point 3b)
bla bla bla \foreignlanguage{italian}{BLA BLA BLA}%
\footnote{\selectlanguage{english}
bla bla bla%
}
Note that what I wrote now was coming after \selectlanguage{english}
I think that now I am more confused than you... Without your patch,
LyX seems correctly translating to LaTeX after backspacing and writing
again in the footnote, as the text in the foreign language is the argument
of \foreignlanguage, so it should not apply to the footnote. With your
patch applied, there's only a \selectlanguage{english} in the footnote,
so it should always be correct without the need of backspacing.
Anyway, with or without your patch I am concerned about obtaining
different results after simply backspacing and writing again in the
footnote.
--
Enrico
Re: [patch] bug 1820 --- footnotes in different language
On Fri, Jul 13, 2007 at 01:27:09AM +0300, Dov Feldstern wrote:
Enrico Forestieri wrote:
Writing again bla bla bla, I got:
(Point 3a)
bla bla bla \foreignlanguage{italian}{BLA BLA BLA}%
\footnote{bla bla bla%
}
which lacks the \selectlanguage commands, meaning that I obtain different
results after backspacing and writing again!
I think this is purely a GUI issue, and has got to do with the
current_font stuff. I believe that the second time around, the language
you are typing in is Italian, not English. You can make sure by turning
on the mark foreign language preference. (I realize now that I have
the advantage of working with Hebrew and English, which use totally
different alphabets; so I very easily can tell when I'm in which
language...).
Yes, you are right. However, doing so I discovered a bug in your patch.
With your patch applied, when I mark as english the footnote content
I correctly see a \selectlanguage{english} inserted before bla bla bla.
But I also see that the whole footnote inset is marked as foreign, so I
select the whole of it and mark it as english. Now it is not underlined
anymore but the \selectlanguage{english} is gone, too!
--
Enrico
Re: [patch] bug 1820 --- footnotes in different language
On Fri, Jul 13, 2007 at 12:47:20AM +0200, Enrico Forestieri wrote:
On Fri, Jul 13, 2007 at 01:27:09AM +0300, Dov Feldstern wrote:
Enrico Forestieri wrote:
Writing again bla bla bla, I got:
(Point 3a)
bla bla bla \foreignlanguage{italian}{BLA BLA BLA}%
\footnote{bla bla bla%
}
which lacks the \selectlanguage commands, meaning that I obtain different
results after backspacing and writing again!
I think this is purely a GUI issue, and has got to do with the
current_font stuff. I believe that the second time around, the language
you are typing in is Italian, not English. You can make sure by turning
on the mark foreign language preference. (I realize now that I have
the advantage of working with Hebrew and English, which use totally
different alphabets; so I very easily can tell when I'm in which
language...).
Yes, you are right. However, doing so I discovered a bug in your patch.
More correctly, a bug not addressed by your patch.
With your patch applied, when I mark as english the footnote content
I correctly see a \selectlanguage{english} inserted before bla bla bla.
But I also see that the whole footnote inset is marked as foreign, so I
select the whole of it and mark it as english. Now it is not underlined
anymore but the \selectlanguage{english} is gone, too!
--
Enrico
Re: [patch] bug 1820 --- footnotes in different language
On Fri, Jul 13, 2007 at 02:31:05AM +0300, Dov Feldstern wrote:
Enrico Forestieri wrote:
With your patch applied, when I mark as english the footnote content
I correctly see a \selectlanguage{english} inserted before bla bla bla.
But I also see that the whole footnote inset is marked as foreign, so I
select the whole of it and mark it as english. Now it is not underlined
anymore but the \selectlanguage{english} is gone, too!
That's fine: once you set the language of the inset to be equal to that
of the text inside it, then the language switch command will happen
*before* the inset, and therefore there's no need for the language
switch to happen inside.
Hope you are right, as what I obtain in this case is:
\selectlanguage{italian}
BLA BLA BLA\foreignlanguage{english}{}%
\footnote{bla bla bla%
}\selectlanguage{english}
I would like bla bla bla to be in English, but it seems to me that
it will be in Italian, instead...
--
Enrico
Re: [patch] bug 1820 --- footnotes in different language
On Fri, Jul 13, 2007 at 03:05:39AM +0300, Dov Feldstern wrote:
Enrico Forestieri wrote:
On Fri, Jul 13, 2007 at 02:31:05AM +0300, Dov Feldstern wrote:
Enrico Forestieri wrote:
With your patch applied, when I mark as english the footnote content
I correctly see a \selectlanguage{english} inserted before bla bla bla.
But I also see that the whole footnote inset is marked as foreign, so I
select the whole of it and mark it as english. Now it is not underlined
anymore but the \selectlanguage{english} is gone, too!
That's fine: once you set the language of the inset to be equal to that
of the text inside it, then the language switch command will happen
*before* the inset, and therefore there's no need for the language
switch to happen inside.
Hope you are right, as what I obtain in this case is:
\selectlanguage{italian}
BLA BLA BLA\foreignlanguage{english}{}%
\footnote{bla bla bla%
}\selectlanguage{english}
I would like bla bla bla to be in English, but it seems to me that
it will be in Italian, instead...
hmmm, I don't know about the \foreignlanguage command, I've been playing
around with either \selectlanguage or \L and \R, which are RTL-specific.
Is there nothing you can type inside the footnote that will appear
differently, depending on the language it's in? punctuation or something?
The LaTeX output is clear, I think. However, just to be sure, I put
\today in the footnote and it gave the date in Italian format.
Moreover, after marking the footnote inset itself as English, I cannot
obtain anymore the \selectlanguage{english} inside the footnote even
trying to mark again as english the content.
The error here is that \footnote should be the argument of
\foreignlanguage but it is left out of it. Thinking about it,
as the footnote could have more paragraphs, \selectlanguage{english}
should be used, in order to avoid a runaway argument error in LaTeX.
--
Enrico
