Re: [PATCH] src/*.cpp: reformatting to increase consistency

[Abdelrazak Younes]

Hi Lars,

I didn't read in detail but I think this patch is good.

Thanks,
Abdel

Re: [PATCH] src/*.cpp: reformatting to increase consistency

[Abdelrazak Younes]

Hi Stephan,

On 27/10/2012 20:56, Stephan Witt wrote:
This invalidates all patches hanging around for cosmetic reasons. Is 
this really necessary? Stephan


Coding style and consistency is always worth it IMO. Solving merge 
issues because of those are often easy. But this was a very valid 
question :-)


Cheers,
Abdel.

Re: boost

[Abdelrazak Younes]

On 26/10/2012 23:42, Lars Gullik Bjønnes wrote:

Pavel Sanda sa...@lyx.org writes:

| | BTW after some decade we still include boost in our tarballs and maintain
| its updates. What was the original reason and is it still needed?

My preferences are as follows:

0. Standard C++
1. Something with the same apis/behaviour as standard C++
2. Use something that is destined for standardization.
3. third party libraries.

In a lot of cases 1  2 is solved by boost, when the stdlib/toolchain at
hand does not support it directly.


My preferences: always favour cleaner, easier to read code.

I agree that C++11 is nice for a lot of things but please don't 
re-inject more boost in our source code. We took a lot of time to 
understand and simplify some code using advanced template techniques, I 
wouldn't want us to go back there. Some people might not agree but our 
conversion to use Qt instead of boost simplified and robustified the 
code base a lot. Qt is there to stay in our code base so pretty please, 
let's just use it when it make sense.


Abdel.

Re: Bug in article (paper) document class

[Jürgen Spitzmüller]

Hendrik Weisser wrote:
 If the article (paper) document class is used with the titlepage
 class option, there's an interaction between the author and
 institution environments. author by itself will not be displayed in
 the document (PDF); institution (by itself or in combination with
 author) will produce the institution twice - first in the style of
 author (replacing the author), then in the style of institution.
 
 I've attached a minimal LyX file that produces this behaviour and the
 resulting PDF.
 
 I hope you can fix this easily.

This is a bug in the LaTeX class file. Nothing we can do on the LyX side, only 
the maintainer of the paper class can fix this. However, the class has not 
been updated since 1996. 

As a workaround, you can put the following code in your LaTeX preamble:

\if@titlepage
  \renewcommand\maketitle{\begin{titlepage}%
  \let\footnotesize\small
  \let\footnoterule\relax
  \let\real@thanks\thanks
  \DeclareRobustCommand\thanks{\real@thanks}
  \let \footnote \thanks
  \null\vfil
  \vskip 60\p@
  \if@center \begin{center} \else \begin{raggedright} \fi
 {\t@font \if@upper \uppercase\expandafter{\@title} \else
 \@title \fi \par}%
\vskip 3em%
 {\ifx\@subtitle\@empty\else
  \vskip.5em \st@font \@subtitle \par \fi}
  \vskip 1.5em
 {\a@font \lineskip .75em
\if@center\begin{tabular}[t]{c}\else\begin{tabular}[t]{@{}l@{}}\fi
 \@author \end{tabular} \par }
 {\ifx\@institution\@empty\else\vskip.5em
\in@font\bf \lineskip .75em
\if@center\begin{tabular}[t]{c}\else\begin{tabular}[t]{@{}l@{}}\fi
 \@institution \end{tabular} \par\fi}
  \vskip 1.5em%
{\large \@date \par}%   % Set date in \large size.
  \if@center \end{center} \else \end{raggedright} \fi
  \vfil\null
  \@thanks
  \end{titlepage}%
  \setcounter{footnote}{0}%
  \let\thanks\relax\let\maketitle\relax
  \gdef\@thanks{}\gdef\@author{}\gdef\@title{}\gdef\@institution{}
  \gdef\@subtitle{}}
\fi

HTH
Jürgen

 Best regards
 
 Hendrik

Re: Compilers used for compiling LyX?

[Jean-Marc Lasgouttes]

Le 27/10/12 13:44, Pavel Sanda a écrit :

Yes. It would be nice to know what is the last Qt version we actually
do compile with the current trunk and clean up all older ifdefs in the
code.

Anyone with Qt 4.4, 4.5 around here to test?


I have 4.6 at work with my old ubuntu 10.04.

I think using 4.5 as baseline would be very safe and allow for code 
simplification.


JMarc

Re: Compilers used for compiling LyX?

[Jean-Marc Lasgouttes]

Le 27/10/12 01:35, Lars Gullik Bjønnes a écrit :


Do any of you have feeling what compilers are use to compile LyX
now-a-days, that at what version they are?

Would be fun to see how far off we are from being able to use C++11.



I have 4.4 on my ubuntu 10.04 install.

JMarc

Re: boost

[Jean-Marc Lasgouttes]

Le 26/10/12 19:05, Pavel Sanda a écrit :

BTW after some decade we still include boost in our tarballs and maintain
its updates. What was the original reason and is it still needed? Some
distributions disable internal boost and we do not see any flood of bug
reports.


If one wants to compile with external boost, then it is not possible to 
compile with stdlib-debug.


JMarc

Re: boost

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes lasgout...@lyx.org writes:

| Le 26/10/12 19:05, Pavel Sanda a écrit :
 BTW after some decade we still include boost in our tarballs and maintain
 its updates. What was the original reason and is it still needed? Some
 distributions disable internal boost and we do not see any flood of bug
 reports.

| If one wants to compile with external boost, then it is not possible
| to compile with stdlib-debug.

That is a problem if we would want to ditch internal boost completely,
but as long as we keep the copy it is not a problem.

I have seen some discussion about this on the boost list in the last few
days, and they talked about createing a super-debug version that is
compiled with stdlib-debug turned on. A distro with a boost-debug variant
like that would probably work for us as well with stdlib-debug on.

-- 
Lgb

Retina support on Mac

[Lars Gullik Bjønnes]

What would having retina support on Mac entail for LyX?

I just got a request for that (together with a donation).

-- 
Lgb

Re: [PATCH] src/*.cpp: reformatting to increase consistency

[Stephan Witt]

Am 27.10.2012 um 22:21 schrieb Lars Gullik Bjønnes lar...@gullik.org:

 On 27 October 2012 21:31, Stephan Witt st.w...@gmx.net wrote:
 Am 27.10.2012 um 21:12 schrieb Lars Gullik Bjønnes lar...@gullik.org:
 
 This invalidates all patches hanging around for cosmetic reasons.
 Is this really necessary?
 
 Why do you have patches hanging around?
 
 Because I didn't apply them?
 
 Commit them to one or more branches and I'll rebase them to HEAD for you.

Thanks, but Abdel is probably right. I can easily do this myself.

 
 Are you saying that changes are hostage to undisclosed patches that
 someone might have?
 
 No, I asked if it's necessary to change the code for increased consistency 
 of coding style.
 
 Not necessary, but nice. Esp. consistency within a single file.
 
 Can you point me to the rules for coding style please?
 
 I only know of the old files in development/coding.

The best match I found is:

 - Adapt the formatting of your code to the one used in the
   other parts of LyX. In case there is different formatting for
   the same construct, use the one used more often.

So this implies one should care for *own* code, IMHO.

I can understand your goal and I'm often tempted to change the formatting of 
our code base at work myself.
But because it is a matter of taste until it's not well defined there is some 
chance of code format bouncing.

This said, I'll don't oppose to this patch.

Stephan

Re: Retina support on Mac

[Stephan Witt]

Am 28.10.2012 um 12:27 schrieb Lars Gullik Bjønnes lar...@gullik.org:What would having retina support on Mac entail for LyX?Basic support is already included now (and back-ported for 2.0.5).The drawing of the main work area is the problem and I'm not sureif this is easy to fix. I already tried to understand the probleman evening and it looks like the painting of one character aftertheother isn't good for retina support. I think the font cacheis to blame here. The text rendering of the Qt-dialogs is ok.StephanPS. This is the current state:

Re: Retina support on Mac

[Jürgen Spitzmüller]

Stephan Witt wrote:
 The drawing of the main work area is the problem and I'm not sure
 if this is easy to fix. I already tried to understand the problem
 an evening and it looks like the painting of one character after
 the other isn't good for retina support. I think the font cache
 is to blame here. The text rendering of the Qt-dialogs is ok.

Painting character-by-character also produces other problems, e.g. support for 
proper ligature drawing (e.g. the Malayalam issue recently reported on lyx-
users).

 Stephan
 
 PS. This is the current state:

What needs to be done wrt icons?

Jürgen

Re: Retina support on Mac

[Stephan Witt]

Am 28.10.2012 um 14:00 schrieb Jürgen Spitzmüller sp...@lyx.org:

 Stephan Witt wrote:
 The drawing of the main work area is the problem and I'm not sure
 if this is easy to fix. I already tried to understand the problem
 an evening and it looks like the painting of one character after
 the other isn't good for retina support. I think the font cache
 is to blame here. The text rendering of the Qt-dialogs is ok.
 
 Painting character-by-character also produces other problems, e.g. support 
 for 
 proper ligature drawing (e.g. the Malayalam issue recently reported on lyx-
 users).

Yes, these problems were present long time before retina.

 What needs to be done wrt icons?

I don't know this yet. But for sure you need an icon set with high resolution :)

Stephan

Re: Retina support on Mac

[Jürgen Spitzmüller]

Stephan Witt wrote:
 I don't know this yet. But for sure you need an icon set with high
 resolution

Or a vector format (svg).

Jürgen

Re: [PATCH] src/*.cpp: reformatting to increase consistency

[Lars Gullik Bjønnes]

Stephan Witt st.w...@gmx.net writes:

| Am 27.10.2012 um 22:21 schrieb Lars Gullik Bjønnes lar...@gullik.org:

 On 27 October 2012 21:31, Stephan Witt st.w...@gmx.net wrote:
 Am 27.10.2012 um 21:12 schrieb Lars Gullik Bjønnes lar...@gullik.org:
 
 This invalidates all patches hanging around for cosmetic reasons.
 Is this really necessary?
 
 Why do you have patches hanging around?
 
 Because I didn't apply them?
 
 Commit them to one or more branches and I'll rebase them to HEAD for you.

| Thanks, but Abdel is probably right. I can easily do this myself.

 
 Are you saying that changes are hostage to undisclosed patches that
 someone might have?
 
 No, I asked if it's necessary to change the code for increased
 consistency of coding style.
 
 Not necessary, but nice. Esp. consistency within a single file.
 
 Can you point me to the rules for coding style please?
 
 I only know of the old files in development/coding.

| The best match I found is:

|  - Adapt the formatting of your code to the one used in the
|other parts of LyX. In case there is different formatting for
|the same construct, use the one used more often.

| So this implies one should care for *own* code, IMHO.

What if one has not done this? Who will ever to it then?
(I'd call it a bug in the commit even, even if it can feel overly
pedantic I do belive that should be part of review comments.)

| I can understand your goal and I'm often tempted to change the formatting of 
our code base at work myself.
| But because it is a matter of taste until it's not well defined there is some 
chance of code format bouncing.

It is pretty well defined how we format code in LyX.
We can get some bouncing of course, but sometime it is not obvious how
to format everyting. esp. when it compes to overlong constructs and who
to make it more readable.

(As as to work... there I do it completely different. You wouldn't want
that style here.)

-- 
Lgb

Re: Bug in article (paper) document class

[Richard Heck]

On 10/28/2012 05:11 AM, Jürgen Spitzmüller wrote:

Hendrik Weisser wrote:

If the article (paper) document class is used with the titlepage
class option, there's an interaction between the author and
institution environments. author by itself will not be displayed in
the document (PDF); institution (by itself or in combination with
author) will produce the institution twice - first in the style of
author (replacing the author), then in the style of institution.

I've attached a minimal LyX file that produces this behaviour and the
resulting PDF.

I hope you can fix this easily.

This is a bug in the LaTeX class file. Nothing we can do on the LyX side, only 
the maintainer of the paper class can fix this. However, the class has not been 
updated since 1996.

I updated a few things a couple years ago, I think. That's my plan again.

rh

Re: Bug in article (paper) document class

[Jürgen Spitzmüller]

Richard Heck wrote:
 I updated a few things a couple years ago, I think. That's my plan again.

Excellent (I only looked at the date of the class manual).

In the given case, the fix is easy (replace \@institution by \@author in line 
348 of paper.cls). This is very obviously a copy and paste error.

Jürgen

Re: knitr and Sweave security

[Pavel Sanda]

Scott Kostyshak wrote:
 knitr (and thus knitr through LyX) will not work out of the box with
 R. The user would have to install the package.
 I think that Sweave is a different story because it comes with R so I
 think that the user would not have to do anything else in order to be
 on the bad end of a harmful .lyx file.

Richard, what is your opinion?
Pavel

Re: [PATCH] src/*.cpp: reformatting to increase consistency

[André Pönitz]

On Sun, Oct 28, 2012 at 01:46:05PM +0100, Stephan Witt wrote:
  Can you point me to the rules for coding style please?
  
  I only know of the old files in development/coding.
 
 The best match I found is:
 
  - Adapt the formatting of your code to the one used in the
other parts of LyX. In case there is different formatting for
the same construct, use the one used more often.
 
 So this implies one should care for *own* code, IMHO.

The vague formulation of In case there is different formatting
for the same construct, use the one used more often. was a result
of LyX not having a lot of written, but quite a few unwritten
rules, and the majority vote pretty much gives the same result
as having all rules explicit.

It was meant as a general permission, or even encouragement, to
strive for a uniform code base, especially, but not restricted to
cases where there are witten rules that are followed, and if the
reformatting (as was e.g. done by Lars here) is separated from
functional changes.

It is really easier to apply mechanical refactoring on top of
a uniform code base and to spot deviation from existing known
-to-work-well patterns easier this way.

Andre'

Qt = 4.5 for LyX 2.1 (was: Compilers used for compiling LyX?)

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
 I think using 4.5 as baseline would be very safe and allow for code 
 simplification.

Anyone against this?
Pavel

Re: Qt = 4.5 for LyX 2.1

[Richard Heck]

On 10/28/2012 02:18 PM, Pavel Sanda wrote:

Jean-Marc Lasgouttes wrote:

I think using 4.5 as baseline would be very safe and allow for code
simplification.

Anyone against this?

I know there are sometimes issues with cygwin, so we should wait to hear 
about that. But it's clear that a lot of this could go, then:


../lyx-devel/src/ [⚡ master]  grep -R QT_VERSION *
Buffer.cpp: /// is still here to allow (QT_VERSION  0x040400).
frontends/qt4/FancyLineEdit.cpp:#if QT_VERSION = 0x040600
frontends/qt4/FancyLineEdit.cpp:#endif // QT_VERSION = 0x040600
frontends/qt4/TocModel.cpp: #if QT_VERSION = 0x040600
frontends/qt4/TocModel.cpp: #if QT_VERSION = 0x040600
frontends/qt4/TocModel.cpp:#if QT_VERSION = 0x040300
frontends/qt4/TocModel.cpp:#if QT_VERSION = 0x040300
frontends/qt4/GuiAbout.cpp: out  Qt Version (compile-time):   
QT_VERSION_STR  \n;

frontends/qt4/GuiCharacter.cpp:#if QT_VERSION = 0x040200
frontends/qt4/LyXFileDialog.cpp:#if QT_VERSION  0x040304
frontends/qt4/GuiWorkArea.h:#if QT_VERSION  0x040300
frontends/qt4/InGuiThread.h:#if QT_VERSION  0x040400
frontends/qt4/Menus.cpp:#if QT_VERSION = 0x040600
frontends/qt4/Menus.cpp:#if defined(Q_WS_WIN)  (QT_VERSION = 0x040600)
frontends/qt4/Menus.cpp:#if defined(Q_WS_WIN)  (QT_VERSION = 0x040600)
frontends/qt4/GuiWorkArea.cpp:#if QT_VERSION  0x040500
frontends/qt4/GuiWorkArea.cpp:#if QT_VERSION = 0x040500
frontends/qt4/GuiWorkArea.cpp:#if QT_VERSION = 0x040500
frontends/qt4/GuiWorkArea.cpp:#if QT_VERSION = 0x040500
frontends/qt4/GuiWorkArea.cpp:#if QT_VERSION  0x040300
frontends/qt4/GuiWorkArea.cpp:#if QT_VERSION = 0x040300
frontends/qt4/GuiSymbols.cpp:#if QT_VERSION = 0x040300
frontends/qt4/GuiFontLoader.cpp:#if QT_VERSION = 0x040300 // 
QT_VERSION  0x040800

frontends/qt4/GuiPrefs.cpp:#if QT_VERSION  0x040600
frontends/qt4/GuiPrefs.cpp:#if QT_VERSION  0x040500
frontends/qt4/GuiPrefs.cpp:#if QT_VERSION  0x040500
frontends/qt4/GuiPrefs.cpp:#if QT_VERSION = 0x040200
frontends/qt4/Makefile.in:QT_VERSION = $(shell IFS=.; set -- `echo 
$(QT4_VERSION)`; \
frontends/qt4/Makefile.in: $(AM_V_GEN)$(MOC4) -DQT_VERSION=$(QT_VERSION) 
-o $@ $

frontends/qt4/FancyLineEdit.h:#if QT_VERSION = 0x040600
frontends/qt4/FancyLineEdit.h:#if QT_VERSION = 0x040600
frontends/qt4/FancyLineEdit.h:#endif // QT_VERSION = 0x040600*/
frontends/qt4/PanelStack.cpp:#if QT_VERSION = 0x040700
frontends/qt4/PanelStack.cpp:#if QT_VERSION = 0x040600
frontends/qt4/GuiApplication.cpp:#if QT_VERSION = 0x040400
frontends/qt4/GuiApplication.cpp:#if QT_VERSION = 0x040400
frontends/qt4/GuiApplication.cpp:#if QT_VERSION  0x040600
frontends/qt4/GuiApplication.cpp:#if QT_VERSION = 0x040300
frontends/qt4/GuiDocument.cpp:#if QT_VERSION = 0x040200
frontends/qt4/Makefile.am:QT_VERSION = $(shell IFS=.; set -- `echo 
$(QT4_VERSION)`; \
frontends/qt4/Makefile.am: $(AM_V_GEN)$(MOC4) -DQT_VERSION=$(QT_VERSION) 
-o $@ $

frontends/qt4/TocWidget.cpp:#if QT_VERSION = 0x040300
frontends/qt4/GuiView.cpp:#if (QT_VERSION = 0x040400)
frontends/qt4/GuiView.cpp:#if (QT_VERSION = 0x040400)
frontends/qt4/GuiView.cpp:#if (QT_VERSION = 0x040400)
frontends/qt4/GuiView.cpp:#if (QT_VERSION = 0x040600)
frontends/qt4/GuiView.cpp:#if (QT_VERSION = 0x040300)
frontends/qt4/GuiView.cpp:#if (QT_VERSION = 0x040400)
frontends/qt4/GuiView.cpp:#if QT_VERSION = 0x040400
frontends/qt4/GuiView.cpp:#if (QT_VERSION = 0x040202)
frontends/qt4/GuiView.cpp:#if (QT_VERSION = 0x040202)
frontends/qt4/GuiView.cpp:#if (QT_VERSION = 0x040202)
frontends/qt4/GuiView.cpp:#if (!defined Q_WS_X11) || (QT_VERSION = 
0x040500)

frontends/qt4/GuiView.cpp:#if EXPORT_in_THREAD  (QT_VERSION = 0x040400)
frontends/qt4/GuiView.cpp:#if (QT_VERSION = 0x040400)
frontends/qt4/GuiView.cpp:#if (QT_VERSION = 0x040400)
frontends/qt4/GuiView.cpp:#if (QT_VERSION = 0x040400)
frontends/qt4/GuiView.cpp:#if EXPORT_in_THREAD  (QT_VERSION = 0x040400)
frontends/qt4/GuiView.cpp:#if QT_VERSION  0x040400
frontends/qt4/GuiView.cpp:#if QT_VERSION = 0x040300
frontends/qt4/GuiView.cpp:#if QT_VERSION = 0x040300
frontends/qt4/GuiView.cpp:#if QT_VERSION = 0x040300
frontends/qt4/FileDialog.cpp:#if QT_VERSION != 0x040203
frontends/qt4/GuiImage.cpp:#if (QT_VERSION = 0x040500)  (QT_VERSION 
= 0x040502)

support/lyxtime.cpp:#if QT_VERSION = 0x040400
support/FileName.cpp:#if defined(_WIN32) || (QT_VERSION = 0x040500)
support/FileName.cpp:#if QT_VERSION = 0x99
support/FileName.cpp:#else // QT_VERSION
support/FileName.cpp:#endif // QT_VERSION

Re: Qt = 4.5 for LyX 2.1

[Pavel Sanda]

Richard Heck wrote:
 On 10/28/2012 02:18 PM, Pavel Sanda wrote:
 Jean-Marc Lasgouttes wrote:
 I think using 4.5 as baseline would be very safe and allow for code
 simplification.
 Anyone against this?

 I know there are sometimes issues with cygwin, so we should wait to hear 
 about that. But it's clear that a lot of this could go, then:

IIRC cygwin ships Qt = 4.5 for a long time.
Pavel

Re: Noweb/Literate programming Copier problem

[Scott Kostyshak]

On Mon, Oct 22, 2012 at 3:54 PM, Pavel Sanda sa...@lyx.org wrote:
 Scott Kostyshak wrote:
 On Sat, Oct 20, 2012 at 6:40 PM, Yihui Xie x...@yihui.name wrote:
  I think that should be enough. A pointer to the knitr manual in
  Help--Specific Manuals--Knitr Manual can be helpful too (I
  remember Liviu mentioned this once).

 Sure, I can do that. Pavel, is that OK? Trunk only?

 Yes, fine with me.

Is the attached patch OK? I broke style by leaving knitr lowercase
because I have never seen it capitalized.

Scott
From 8e20c4f90c59ef1d3a9424367186d6c68abc9ebd Mon Sep 17 00:00:00 2001
From: Scott Kostyshak skost...@lyx.org
Date: Sun, 28 Oct 2012 23:03:36 -0400
Subject: [PATCH] Add knitr manual to Help  Specific Manuals

---
 lib/ui/stdmenus.inc |1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/ui/stdmenus.inc b/lib/ui/stdmenus.inc
index 9cb6768..9f9c632 100644
--- a/lib/ui/stdmenus.inc
+++ b/lib/ui/stdmenus.inc
@@ -590,6 +590,7 @@ Menuset
Menu examples
Item Braille Manual|B help-open Braille
Item Feynman-diagram Manual|F help-open FeynmanDiagrams
+   Item knitr Manual|k help-open knitr
Item LilyPond Manual|M help-open lilypond
Item Linguistics Manual|L help-open linguistics
Item Multilingual Captions Manual|C help-open 
MultilingualCaptions
-- 
1.7.9.5

Re: Noweb/Literate programming Copier problem

[Yihui Xie]

That is okay for me, and I do not mind Knitr although it is indeed
rarely capitalized.

Regards,
Yihui
--
Yihui Xie xieyi...@gmail.com
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Sun, Oct 28, 2012 at 10:11 PM, Scott Kostyshak skost...@lyx.org wrote:

 Is the attached patch OK? I broke style by leaving knitr lowercase
 because I have never seen it capitalized.

 Scott

[PATCH] Remove repetitious Manual from Specific Manuals

[Scott Kostyshak]

Just as the other elements of the Help menu do not have Manual
appended to their names, I do not think items in the Specific
Manuals submenu should have Manual appended to their names.

Thoughts?

Thanks,

Scott
From 7c001a8d596dcd62ef8ddcf88b135ef3fd602e79 Mon Sep 17 00:00:00 2001
From: Scott Kostyshak skost...@lyx.org
Date: Sun, 28 Oct 2012 23:13:51 -0400
Subject: [PATCH] Remove repetitious Manual from Specific Manuals

---
 lib/ui/stdmenus.inc |   16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/lib/ui/stdmenus.inc b/lib/ui/stdmenus.inc
index 9cb6768..0c31b27 100644
--- a/lib/ui/stdmenus.inc
+++ b/lib/ui/stdmenus.inc
@@ -588,14 +588,14 @@ Menuset
End
 
Menu examples
-   Item Braille Manual|B help-open Braille
-   Item Feynman-diagram Manual|F help-open FeynmanDiagrams
-   Item LilyPond Manual|M help-open lilypond
-   Item Linguistics Manual|L help-open linguistics
-   Item Multilingual Captions Manual|C help-open 
MultilingualCaptions
-   Item Risk and Safety Statements Manual|R help-open 
R-S-statements
-   Item Sweave Manual|S help-open sweave
-   Item XY-pic Manual|X help-open xypic
+   Item Braille|B help-open Braille
+   Item Feynman-diagram|F help-open FeynmanDiagrams
+   Item LilyPond|P help-open lilypond
+   Item Linguistics|L help-open linguistics
+   Item Multilingual Captions|C help-open MultilingualCaptions
+   Item Risk and Safety Statements|R help-open R-S-statements
+   Item Sweave|S help-open sweave
+   Item XY-pic|X help-open xypic
End
 
 
-- 
1.7.9.5

Re: [PATCH] src/*.cpp: reformatting to increase consistency

[Abdelrazak Younes]

Hi Lars,

I didn't read in detail but I think this patch is good.

Thanks,
Abdel

Re: [PATCH] src/*.cpp: reformatting to increase consistency

[Abdelrazak Younes]

Hi Stephan,

On 27/10/2012 20:56, Stephan Witt wrote:
This invalidates all patches hanging around for cosmetic reasons. Is 
this really necessary? Stephan


Coding style and consistency is always worth it IMO. Solving merge 
issues because of those are often easy. But this was a very valid 
question :-)


Cheers,
Abdel.

Re: boost

[Abdelrazak Younes]

On 26/10/2012 23:42, Lars Gullik Bjønnes wrote:

Pavel Sanda  writes:

| | BTW after some decade we still include boost in our tarballs and maintain
| its updates. What was the original reason and is it still needed?

My preferences are as follows:

0. Standard C++
1. Something with the same apis/behaviour as standard C++
2. Use something that is destined for standardization.
3. third party libraries.

In a lot of cases 1 & 2 is solved by boost, when the stdlib/toolchain at
hand does not support it directly.


My preferences: always favour cleaner, easier to read code.

I agree that C++11 is nice for a lot of things but please don't 
re-inject more boost in our source code. We took a lot of time to 
understand and simplify some code using advanced template techniques, I 
wouldn't want us to go back there. Some people might not agree but our 
conversion to use Qt instead of boost simplified and robustified the 
code base a lot. Qt is there to stay in our code base so pretty please, 
let's just use it when it make sense.


Abdel.

Re: Bug in "article (paper)" document class

[Jürgen Spitzmüller]

Hendrik Weisser wrote:
> If the "article (paper)" document class is used with the "titlepage"
> class option, there's an interaction between the "author" and
> "institution" environments. "author" by itself will not be displayed in
> the document (PDF); "institution" (by itself or in combination with
> "author") will produce the institution twice - first in the style of
> "author" (replacing the author), then in the style of "institution".
> 
> I've attached a minimal LyX file that produces this behaviour and the
> resulting PDF.
> 
> I hope you can fix this easily.

This is a bug in the LaTeX class file. Nothing we can do on the LyX side, only 
the maintainer of the paper class can fix this. However, the class has not 
been updated since 1996. 

As a workaround, you can put the following code in your LaTeX preamble:

\if@titlepage
  \renewcommand\maketitle{\begin{titlepage}%
  \let\footnotesize\small
  \let\footnoterule\relax
  \let\real@thanks\thanks
  \DeclareRobustCommand\thanks{\real@thanks}
  \let \footnote \thanks
  \null\vfil
  \vskip 60\p@
  \if@center \begin{center} \else \begin{raggedright} \fi
 {\t@font \if@upper \uppercase\expandafter{\@title} \else
 \@title \fi \par}%
\vskip 3em%
 {\ifx\@subtitle\@empty\else
  \vskip.5em \st@font \@subtitle \par \fi}
  \vskip 1.5em
 {\a@font \lineskip .75em
\if@center\begin{tabular}[t]{c}\else\begin{tabular}[t]{@{}l@{}}\fi
 \@author \end{tabular} \par }
 {\ifx\@institution\@empty\else\vskip.5em
\in@font\bf \lineskip .75em
\if@center\begin{tabular}[t]{c}\else\begin{tabular}[t]{@{}l@{}}\fi
 \@institution \end{tabular} \par\fi}
  \vskip 1.5em%
{\large \@date \par}%   % Set date in \large size.
  \if@center \end{center} \else \end{raggedright} \fi
  \vfil\null
  \@thanks
  \end{titlepage}%
  \setcounter{footnote}{0}%
  \let\thanks\relax\let\maketitle\relax
  \gdef\@thanks{}\gdef\@author{}\gdef\@title{}\gdef\@institution{}
  \gdef\@subtitle{}}
\fi

HTH
Jürgen

> Best regards
> 
> Hendrik

Re: Compilers used for compiling LyX?

[Jean-Marc Lasgouttes]

Le 27/10/12 13:44, Pavel Sanda a écrit :

Yes. It would be nice to know what is the last Qt version we actually
do compile with the current trunk and clean up all older ifdefs in the
code.

Anyone with Qt 4.4, 4.5 around here to test?


I have 4.6 at work with my old ubuntu 10.04.

I think using 4.5 as baseline would be very safe and allow for code 
simplification.


JMarc

Re: Compilers used for compiling LyX?

[Jean-Marc Lasgouttes]

Le 27/10/12 01:35, Lars Gullik Bjønnes a écrit :


Do any of you have feeling what compilers are use to compile LyX
now-a-days, that at what version they are?

Would be fun to see how far off we are from being able to use C++11.



I have 4.4 on my ubuntu 10.04 install.

JMarc

Re: boost

[Jean-Marc Lasgouttes]

Le 26/10/12 19:05, Pavel Sanda a écrit :

BTW after some decade we still include boost in our tarballs and maintain
its updates. What was the original reason and is it still needed? Some
distributions disable internal boost and we do not see any flood of bug
reports.


If one wants to compile with external boost, then it is not possible to 
compile with stdlib-debug.


JMarc

Re: boost

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes  writes:

| Le 26/10/12 19:05, Pavel Sanda a écrit :
>> BTW after some decade we still include boost in our tarballs and maintain
>> its updates. What was the original reason and is it still needed? Some
>> distributions disable internal boost and we do not see any flood of bug
>> reports.
>
| If one wants to compile with external boost, then it is not possible
| to compile with stdlib-debug.

That is a problem if we would want to ditch internal boost completely,
but as long as we keep the copy it is not a problem.

I have seen some discussion about this on the boost list in the last few
days, and they talked about createing a "super-debug" version that is
compiled with stdlib-debug turned on. A distro with a boost-debug variant
like that would probably work for us as well with stdlib-debug on.

-- 
Lgb

Retina support on Mac

[Lars Gullik Bjønnes]

What would having retina support on Mac entail for LyX?

I just got a request for that (together with a donation).

-- 
Lgb

Re: [PATCH] src/*.cpp: reformatting to increase consistency

[Stephan Witt]

Am 27.10.2012 um 22:21 schrieb Lars Gullik Bjønnes :

> On 27 October 2012 21:31, Stephan Witt  wrote:
>> Am 27.10.2012 um 21:12 schrieb Lars Gullik Bjønnes :
>> 
 This invalidates all patches hanging around for cosmetic reasons.
 Is this really necessary?
>>> 
>>> Why do you have patches hanging around?
>> 
>> Because I didn't apply them?
> 
> Commit them to one or more branches and I'll rebase them to HEAD for you.

Thanks, but Abdel is probably right. I can easily do this myself.

> 
>>> Are you saying that changes are hostage to undisclosed patches that
>>> someone might have?
>> 
>> No, I asked if it's necessary to change the code for increased consistency 
>> of coding style.
> 
> Not necessary, but nice. Esp. consistency within a single file.
> 
>> Can you point me to the rules for coding style please?
> 
> I only know of the old files in development/coding.

The best match I found is:

 - Adapt the formatting of your code to the one used in the
   other parts of LyX. In case there is different formatting for
   the same construct, use the one used more often.

So this implies one should care for *own* code, IMHO.

I can understand your goal and I'm often tempted to change the formatting of 
our code base at work myself.
But because it is a matter of taste until it's not well defined there is some 
chance of "code format bouncing".

This said, I'll don't oppose to this patch.

Stephan

Re: Retina support on Mac

[Stephan Witt]

Am 28.10.2012 um 12:27 schrieb Lars Gullik Bjønnes :What would having retina support on Mac entail for LyX?Basic support is already included now (and back-ported for 2.0.5).The drawing of the main work area is the problem and I'm not sureif this is easy to fix. I already tried to understand the probleman evening and it looks like the painting of one character afterthe other isn't good for retina support. I think the font cacheis to blame here. The text rendering of the Qt-dialogs is ok.StephanPS. This is the current state:

Re: Retina support on Mac

[Jürgen Spitzmüller]

Stephan Witt wrote:
> The drawing of the main work area is the problem and I'm not sure
> if this is easy to fix. I already tried to understand the problem
> an evening and it looks like the painting of one character after
> the other isn't good for retina support. I think the font cache
> is to blame here. The text rendering of the Qt-dialogs is ok.

Painting character-by-character also produces other problems, e.g. support for 
proper ligature drawing (e.g. the Malayalam issue recently reported on lyx-
users).

> Stephan
> 
> PS. This is the current state:

What needs to be done wrt icons?

Jürgen

Re: Retina support on Mac

[Stephan Witt]

Am 28.10.2012 um 14:00 schrieb Jürgen Spitzmüller :

> Stephan Witt wrote:
>> The drawing of the main work area is the problem and I'm not sure
>> if this is easy to fix. I already tried to understand the problem
>> an evening and it looks like the painting of one character after
>> the other isn't good for retina support. I think the font cache
>> is to blame here. The text rendering of the Qt-dialogs is ok.
> 
> Painting character-by-character also produces other problems, e.g. support 
> for 
> proper ligature drawing (e.g. the Malayalam issue recently reported on lyx-
> users).

Yes, these problems were present long time before retina.

> What needs to be done wrt icons?

I don't know this yet. But for sure you need an icon set with high resolution :)

Stephan

Re: Retina support on Mac

[Jürgen Spitzmüller]

Stephan Witt wrote:
> I don't know this yet. But for sure you need an icon set with high
> resolution

Or a vector format (svg).

Jürgen

Re: [PATCH] src/*.cpp: reformatting to increase consistency

[Lars Gullik Bjønnes]

Stephan Witt  writes:

| Am 27.10.2012 um 22:21 schrieb Lars Gullik Bjønnes :
>
>> On 27 October 2012 21:31, Stephan Witt  wrote:
>>> Am 27.10.2012 um 21:12 schrieb Lars Gullik Bjønnes :
>>> 
> This invalidates all patches hanging around for cosmetic reasons.
> Is this really necessary?
 
 Why do you have patches hanging around?
>>> 
>>> Because I didn't apply them?
>> 
>> Commit them to one or more branches and I'll rebase them to HEAD for you.
>
| Thanks, but Abdel is probably right. I can easily do this myself.
>
>> 
 Are you saying that changes are hostage to undisclosed patches that
 someone might have?
>>> 
>>> No, I asked if it's necessary to change the code for increased
>>> consistency of coding style.
>> 
>> Not necessary, but nice. Esp. consistency within a single file.
>> 
>>> Can you point me to the rules for coding style please?
>> 
>> I only know of the old files in development/coding.
>
| The best match I found is:
>
|  - Adapt the formatting of your code to the one used in the
|other parts of LyX. In case there is different formatting for
|the same construct, use the one used more often.
>
| So this implies one should care for *own* code, IMHO.

What if "one" has not done this? Who will ever to it then?
(I'd call it a "bug" in the commit even, even if it can feel overly
pedantic I do belive that should be part of review comments.)

| I can understand your goal and I'm often tempted to change the formatting of 
our code base at work myself.
| But because it is a matter of taste until it's not well defined there is some 
chance of "code format bouncing".

It is pretty well defined how we format code in LyX.
We can get some bouncing of course, but sometime it is not obvious how
to format everyting. esp. when it compes to overlong constructs and who
to make it more readable.

(As as to work... there I do it completely different. You wouldn't want
that style here.)

-- 
Lgb

Re: Bug in "article (paper)" document class

[Richard Heck]

On 10/28/2012 05:11 AM, Jürgen Spitzmüller wrote:

Hendrik Weisser wrote:

If the "article (paper)" document class is used with the "titlepage"
class option, there's an interaction between the "author" and
"institution" environments. "author" by itself will not be displayed in
the document (PDF); "institution" (by itself or in combination with
"author") will produce the institution twice - first in the style of
"author" (replacing the author), then in the style of "institution".

I've attached a minimal LyX file that produces this behaviour and the
resulting PDF.

I hope you can fix this easily.

This is a bug in the LaTeX class file. Nothing we can do on the LyX side, only 
the maintainer of the paper class can fix this. However, the class has not been 
updated since 1996.

I updated a few things a couple years ago, I think. That's my plan again.

rh

Re: Bug in "article (paper)" document class

[Jürgen Spitzmüller]

Richard Heck wrote:
> I updated a few things a couple years ago, I think. That's my plan again.

Excellent (I only looked at the date of the class manual).

In the given case, the fix is easy (replace \@institution by \@author in line 
348 of paper.cls). This is very obviously a copy and paste error.

Jürgen

Re: knitr and Sweave security

[Pavel Sanda]

Scott Kostyshak wrote:
> knitr (and thus knitr through LyX) will not work out of the box with
> R. The user would have to install the package.
> I think that Sweave is a different story because it comes with R so I
> think that the user would not have to do anything else in order to be
> on the bad end of a harmful .lyx file.

Richard, what is your opinion?
Pavel

Re: [PATCH] src/*.cpp: reformatting to increase consistency

[André Pönitz]

On Sun, Oct 28, 2012 at 01:46:05PM +0100, Stephan Witt wrote:
> >> Can you point me to the rules for coding style please?
> > 
> > I only know of the old files in development/coding.
> 
> The best match I found is:
> 
>  - Adapt the formatting of your code to the one used in the
>other parts of LyX. In case there is different formatting for
>the same construct, use the one used more often.
> 
> So this implies one should care for *own* code, IMHO.

The vague formulation of "In case there is different formatting
for the same construct, use the one used more often." was a result
of LyX not having a lot of written, but quite a few unwritten
rules, and the "majority vote" pretty much gives the same result
as having all rules explicit.

It was meant as a general permission, or even encouragement, to
strive for a uniform code base, especially, but not restricted to
cases where there are witten rules that are followed, and if the
reformatting (as was e.g. done by Lars here) is separated from
functional changes.

It is really easier to apply mechanical refactoring on top of
a uniform code base and to spot deviation from existing known
-to-work-well patterns easier this way.

Andre'

Qt >= 4.5 for LyX 2.1 (was: Compilers used for compiling LyX?)

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> I think using 4.5 as baseline would be very safe and allow for code 
> simplification.

Anyone against this?
Pavel

Re: Qt >= 4.5 for LyX 2.1

[Richard Heck]

On 10/28/2012 02:18 PM, Pavel Sanda wrote:

Jean-Marc Lasgouttes wrote:

I think using 4.5 as baseline would be very safe and allow for code
simplification.

Anyone against this?

I know there are sometimes issues with cygwin, so we should wait to hear 
about that. But it's clear that a lot of this could go, then:


../lyx-devel/src/ [⚡ master] > grep -R QT_VERSION *
Buffer.cpp: /// is still here to allow (QT_VERSION < 0x040400).
frontends/qt4/FancyLineEdit.cpp:#if QT_VERSION >= 0x040600
frontends/qt4/FancyLineEdit.cpp:#endif // QT_VERSION >= 0x040600
frontends/qt4/TocModel.cpp: #if QT_VERSION >= 0x040600
frontends/qt4/TocModel.cpp: #if QT_VERSION >= 0x040600
frontends/qt4/TocModel.cpp:#if QT_VERSION >= 0x040300
frontends/qt4/TocModel.cpp:#if QT_VERSION >= 0x040300
frontends/qt4/GuiAbout.cpp: out << "Qt Version (compile-time): " << 
QT_VERSION_STR << "\n";

frontends/qt4/GuiCharacter.cpp:#if QT_VERSION >= 0x040200
frontends/qt4/LyXFileDialog.cpp:#if QT_VERSION < 0x040304
frontends/qt4/GuiWorkArea.h:#if QT_VERSION < 0x040300
frontends/qt4/InGuiThread.h:#if QT_VERSION < 0x040400
frontends/qt4/Menus.cpp:#if QT_VERSION >= 0x040600
frontends/qt4/Menus.cpp:#if defined(Q_WS_WIN) && (QT_VERSION >= 0x040600)
frontends/qt4/Menus.cpp:#if defined(Q_WS_WIN) && (QT_VERSION >= 0x040600)
frontends/qt4/GuiWorkArea.cpp:#if QT_VERSION < 0x040500
frontends/qt4/GuiWorkArea.cpp:#if QT_VERSION >= 0x040500
frontends/qt4/GuiWorkArea.cpp:#if QT_VERSION >= 0x040500
frontends/qt4/GuiWorkArea.cpp:#if QT_VERSION >= 0x040500
frontends/qt4/GuiWorkArea.cpp:#if QT_VERSION < 0x040300
frontends/qt4/GuiWorkArea.cpp:#if QT_VERSION >= 0x040300
frontends/qt4/GuiSymbols.cpp:#if QT_VERSION >= 0x040300
frontends/qt4/GuiFontLoader.cpp:#if QT_VERSION >= 0x040300 //&& 
QT_VERSION < 0x040800

frontends/qt4/GuiPrefs.cpp:#if QT_VERSION > 0x040600
frontends/qt4/GuiPrefs.cpp:#if QT_VERSION < 0x040500
frontends/qt4/GuiPrefs.cpp:#if QT_VERSION < 0x040500
frontends/qt4/GuiPrefs.cpp:#if QT_VERSION >= 0x040200
frontends/qt4/Makefile.in:QT_VERSION = $(shell IFS=.; set -- `echo 
$(QT4_VERSION)`; \
frontends/qt4/Makefile.in: $(AM_V_GEN)$(MOC4) -DQT_VERSION=$(QT_VERSION) 
-o $@ $<

frontends/qt4/FancyLineEdit.h:#if QT_VERSION >= 0x040600
frontends/qt4/FancyLineEdit.h:#if QT_VERSION >= 0x040600
frontends/qt4/FancyLineEdit.h:#endif // QT_VERSION >= 0x040600*/
frontends/qt4/PanelStack.cpp:#if QT_VERSION >= 0x040700
frontends/qt4/PanelStack.cpp:#if QT_VERSION >= 0x040600
frontends/qt4/GuiApplication.cpp:#if QT_VERSION >= 0x040400
frontends/qt4/GuiApplication.cpp:#if QT_VERSION >= 0x040400
frontends/qt4/GuiApplication.cpp:#if QT_VERSION > 0x040600
frontends/qt4/GuiApplication.cpp:#if QT_VERSION >= 0x040300
frontends/qt4/GuiDocument.cpp:#if QT_VERSION >= 0x040200
frontends/qt4/Makefile.am:QT_VERSION = $(shell IFS=.; set -- `echo 
$(QT4_VERSION)`; \
frontends/qt4/Makefile.am: $(AM_V_GEN)$(MOC4) -DQT_VERSION=$(QT_VERSION) 
-o $@ $<

frontends/qt4/TocWidget.cpp:#if QT_VERSION >= 0x040300
frontends/qt4/GuiView.cpp:#if (QT_VERSION >= 0x040400)
frontends/qt4/GuiView.cpp:#if (QT_VERSION >= 0x040400)
frontends/qt4/GuiView.cpp:#if (QT_VERSION >= 0x040400)
frontends/qt4/GuiView.cpp:#if (QT_VERSION >= 0x040600)
frontends/qt4/GuiView.cpp:#if (QT_VERSION >= 0x040300)
frontends/qt4/GuiView.cpp:#if (QT_VERSION >= 0x040400)
frontends/qt4/GuiView.cpp:#if QT_VERSION >= 0x040400
frontends/qt4/GuiView.cpp:#if (QT_VERSION >= 0x040202)
frontends/qt4/GuiView.cpp:#if (QT_VERSION >= 0x040202)
frontends/qt4/GuiView.cpp:#if (QT_VERSION >= 0x040202)
frontends/qt4/GuiView.cpp:#if (!defined Q_WS_X11) || (QT_VERSION >= 
0x040500)

frontends/qt4/GuiView.cpp:#if EXPORT_in_THREAD && (QT_VERSION >= 0x040400)
frontends/qt4/GuiView.cpp:#if (QT_VERSION >= 0x040400)
frontends/qt4/GuiView.cpp:#if (QT_VERSION >= 0x040400)
frontends/qt4/GuiView.cpp:#if (QT_VERSION >= 0x040400)
frontends/qt4/GuiView.cpp:#if EXPORT_in_THREAD && (QT_VERSION >= 0x040400)
frontends/qt4/GuiView.cpp:#if QT_VERSION < 0x040400
frontends/qt4/GuiView.cpp:#if QT_VERSION >= 0x040300
frontends/qt4/GuiView.cpp:#if QT_VERSION >= 0x040300
frontends/qt4/GuiView.cpp:#if QT_VERSION >= 0x040300
frontends/qt4/FileDialog.cpp:#if QT_VERSION != 0x040203
frontends/qt4/GuiImage.cpp:#if (QT_VERSION >= 0x040500) && (QT_VERSION 
<= 0x040502)

support/lyxtime.cpp:#if QT_VERSION >= 0x040400
support/FileName.cpp:#if defined(_WIN32) || (QT_VERSION >= 0x040500)
support/FileName.cpp:#if QT_VERSION >= 0x99
support/FileName.cpp:#else // QT_VERSION
support/FileName.cpp:#endif // QT_VERSION

Re: Qt >= 4.5 for LyX 2.1

[Pavel Sanda]

Richard Heck wrote:
> On 10/28/2012 02:18 PM, Pavel Sanda wrote:
>> Jean-Marc Lasgouttes wrote:
>>> I think using 4.5 as baseline would be very safe and allow for code
>>> simplification.
>> Anyone against this?
>>
> I know there are sometimes issues with cygwin, so we should wait to hear 
> about that. But it's clear that a lot of this could go, then:

IIRC cygwin ships Qt >= 4.5 for a long time.
Pavel

Re: Noweb/Literate programming Copier problem

[Scott Kostyshak]

On Mon, Oct 22, 2012 at 3:54 PM, Pavel Sanda  wrote:
> Scott Kostyshak wrote:
>> On Sat, Oct 20, 2012 at 6:40 PM, Yihui Xie  wrote:
>> > I think that should be enough. A pointer to the knitr manual in
>> > "Help-->Specific Manuals-->Knitr Manual" can be helpful too (I
>> > remember Liviu mentioned this once).
>>
>> Sure, I can do that. Pavel, is that OK? Trunk only?
>
> Yes, fine with me.

Is the attached patch OK? I broke style by leaving knitr lowercase
because I have never seen it capitalized.

Scott
From 8e20c4f90c59ef1d3a9424367186d6c68abc9ebd Mon Sep 17 00:00:00 2001
From: Scott Kostyshak 
Date: Sun, 28 Oct 2012 23:03:36 -0400
Subject: [PATCH] Add knitr manual to Help > Specific Manuals

---
 lib/ui/stdmenus.inc |1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/ui/stdmenus.inc b/lib/ui/stdmenus.inc
index 9cb6768..9f9c632 100644
--- a/lib/ui/stdmenus.inc
+++ b/lib/ui/stdmenus.inc
@@ -590,6 +590,7 @@ Menuset
Menu "examples"
Item "Braille Manual|B" "help-open Braille"
Item "Feynman-diagram Manual|F" "help-open FeynmanDiagrams"
+   Item "knitr Manual|k" "help-open knitr"
Item "LilyPond Manual|M" "help-open lilypond"
Item "Linguistics Manual|L" "help-open linguistics"
Item "Multilingual Captions Manual|C" "help-open 
MultilingualCaptions"
-- 
1.7.9.5

Re: Noweb/Literate programming Copier problem

[Yihui Xie]

That is okay for me, and I do not mind "Knitr" although it is indeed
rarely capitalized.

Regards,
Yihui
--
Yihui Xie 
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA


On Sun, Oct 28, 2012 at 10:11 PM, Scott Kostyshak  wrote:
>
> Is the attached patch OK? I broke style by leaving knitr lowercase
> because I have never seen it capitalized.
>
> Scott

[PATCH] Remove repetitious "Manual" from Specific Manuals

[Scott Kostyshak]

Just as the other elements of the Help menu do not have "Manual"
appended to their names, I do not think items in the "Specific
Manuals" submenu should have "Manual" appended to their names.

Thoughts?

Thanks,

Scott
From 7c001a8d596dcd62ef8ddcf88b135ef3fd602e79 Mon Sep 17 00:00:00 2001
From: Scott Kostyshak 
Date: Sun, 28 Oct 2012 23:13:51 -0400
Subject: [PATCH] Remove repetitious "Manual" from Specific Manuals

---
 lib/ui/stdmenus.inc |   16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/lib/ui/stdmenus.inc b/lib/ui/stdmenus.inc
index 9cb6768..0c31b27 100644
--- a/lib/ui/stdmenus.inc
+++ b/lib/ui/stdmenus.inc
@@ -588,14 +588,14 @@ Menuset
End
 
Menu "examples"
-   Item "Braille Manual|B" "help-open Braille"
-   Item "Feynman-diagram Manual|F" "help-open FeynmanDiagrams"
-   Item "LilyPond Manual|M" "help-open lilypond"
-   Item "Linguistics Manual|L" "help-open linguistics"
-   Item "Multilingual Captions Manual|C" "help-open 
MultilingualCaptions"
-   Item "Risk and Safety Statements Manual|R" "help-open 
R-S-statements"
-   Item "Sweave Manual|S" "help-open sweave"
-   Item "XY-pic Manual|X" "help-open xypic"
+   Item "Braille|B" "help-open Braille"
+   Item "Feynman-diagram|F" "help-open FeynmanDiagrams"
+   Item "LilyPond|P" "help-open lilypond"
+   Item "Linguistics|L" "help-open linguistics"
+   Item "Multilingual Captions|C" "help-open MultilingualCaptions"
+   Item "Risk and Safety Statements|R" "help-open R-S-statements"
+   Item "Sweave|S" "help-open sweave"
+   Item "XY-pic|X" "help-open xypic"
End
 
 
-- 
1.7.9.5