[PATCH] Remove repetitious "Manual" from Specific Manuals
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
Re: Noweb/Literate programming Copier problem
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
Re: Noweb/Literate programming Copier problem
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: Qt >= 4.5 for LyX 2.1
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: Qt >= 4.5 for LyX 2.1
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
Qt >= 4.5 for LyX 2.1 (was: Compilers used for compiling LyX?)
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: [PATCH] src/*.cpp: reformatting to increase consistency
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'
Re: knitr and Sweave security
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: Bug in "article (paper)" document class
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: Bug in "article (paper)" document class
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: [PATCH] src/*.cpp: reformatting to increase consistency
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: Retina support on Mac
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: Retina support on Mac
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
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
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: [PATCH] src/*.cpp: reformatting to increase consistency
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
Retina support on Mac
What would having retina support on Mac entail for LyX? I just got a request for that (together with a donation). -- Lgb
Re: boost
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
Re: boost
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: Compilers used for compiling LyX?
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: Compilers used for compiling LyX?
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: Bug in "article (paper)" document class
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: boost
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.