Re: [PATCH] unique_ptr and some clean-up

[Jean-Marc Lasgouttes]

Full day of teaching in Rouen. But yes, RER is on strike :)

JMarc 

Le 14 juin 2016 21:41:12 GMT+02:00, Guillaume Munch  a écrit :
>Le 14/06/2016 20:16, Jean-Marc Lasgouttes a écrit :
>> I will not be able to test until Thursday afternoon.
>>
>
>RER is on strike ? ;)

Re: A tiny cedilla anomaly

[Scott Kostyshak]

On Thu, Jun 02, 2016 at 10:07:44PM -0400, Scott Kostyshak wrote:
> On Tue, May 03, 2016 at 02:47:43PM +0100, Guillaume Munch wrote:
> > Le 03/05/2016 06:09, Stephan Witt a écrit :
> > > Am 03.05.2016 um 03:04 schrieb Guillaume Munch :
> > > > 
> > > > Le 03/05/2016 01:40, Scott Kostyshak a écrit :
> > > > > On Sun, May 01, 2016 at 08:38:58AM +0200, Stephan Witt wrote:
> > > > > > Am 01.05.2016 um 04:06 schrieb Scott Kostyshak :
> > > > > > > 
> > > > > > > On Sun, May 01, 2016 at 01:28:56PM +1200, Andrew Parsloe wrote:
> > > > > > > > On 1/05/2016 11:33 a.m., Jean-Marc Lasgouttes wrote:
> > > > > > > > > Le 27/04/2016 03:22, Andrew Parsloe a écrit :
> > > > > > > > > > Having just skimmed through an article on Wikipedia about 
> > > > > > > > > > cedillas, I
> > > > > > > > > > gather a cedilla is never attached to the letter 'i'. 
> > > > > > > > > > Nonetheless, when
> > > > > > > > > > I do attach one (using european.kmap,  then ',' followed by 
> > > > > > > > > > 'i'),
> > > > > > > > > > everything looks fine in the main LyX window but in the 
> > > > > > > > > > Source Pane, LyX
> > > > > > > > > > format, the cedilla gets attached to the following letter. 
> > > > > > > > > > For instance,
> > > > > > > > > > writing'aei̧ou' with a cedilla under the 'i', all is fine 
> > > > > > > > > > in the main LyX
> > > > > > > > > > window (and the pdf) but when viewed in the Source Pane, 
> > > > > > > > > > the cedilla is
> > > > > > > > > > located under the 'o'. A quick experiment suggests 'i' is 
> > > > > > > > > > the only
> > > > > > > > > > letter for which this happens. It doesn't happen in 2.1.4 
> > > > > > > > > > so it appears
> > > > > > > > > > to be a (tiny) regression.
> > > > > > > > > 
> > > > > > > > > The source pane in under the responsability of Qt, AFAIK. It 
> > > > > > > > > might be
> > > > > > > > > that you see a bug in Qt itself. What is the Qt version that 
> > > > > > > > > your LyX
> > > > > > > > > uses?
> > > > > > > > > 
> > > > > > > > > JMarc
> > > > > > > > It's Uwe's windows version of rc1, hence Qt 5.6 as I 
> > > > > > > > understand. (There
> > > > > > > > isn't anything about Qt version in the About LyX tabs. It would 
> > > > > > > > be a good
> > > > > > > > addition to the information there.)
> > > > > > > 
> > > > > > > I thought we did have it. In Help > About, for me it says:
> > > > > > > 
> > > > > > > Qt Version (run-time): 5.6.0
> > > > > > > Qt Version (compile-time): 5.6.0
> > > > > > 
> > > > > > This is visible for development version only.
> > > > > 
> > > > > I see. Is the concern that we will confuse the user? Or that the
> > > > > information is useless because we should remember which Qt version was
> > > > > used for each release we provide?
> > > 
> > > The idea was: it’s useful for developers only because one shouldn’t be 
> > > unsure
> > > about the Qt-version of the released LyX package. But it’s easy to change 
> > > and
> > > if in practice it’s interesting to know - why not. Patch is attached.
> > > 
> > > > 
> > > > Here, it is in About > Build Info in release mode.
> > > 
> > > Yes, I was not precise enough. It depends on the location of the source 
> > > tree
> > > in a git clone or not.
> > > 
> > 
> > Patch looks sensible and reasonable.
> > 
> > 
> 
> Doesn't seem like there is any disagreement. I would say commit.

Bump. I just want to make sure the patch is not forgotten. Stephan I
think you can commit.

Scott


signature.asc
Description: PGP signature

Re: scrunched radio buttons on message pane

[Scott Kostyshak]

On Tue, Jun 14, 2016 at 06:19:27PM +, Paul A. Rubin wrote:
> Scott Kostyshak  lyx.org> writes:
> 
> > 
> > Does anyone else see that the radio buttons are cut-off on the message
> > pane?
> > 
> 
> FWIW, they're find with LyX 2.2.0 /Qt 4.8.6 on Linux Mint Rebecca.
> 
> Paul

I forgot to mention: when testing you should try to make the height of
the messages pane as small as possible. Does it allow you to go "too"
small?

Attached is a patch. I've tested docking it, undocking it, and resizing
it in weird ways. I link below to before/after screenshots with Qt 4 and
Qt 5 and two different systems (both Ubuntu though):

https://www.dropbox.com/s/rysu6whqg8h87z5/qt4_15_after.png?dl=0
https://www.dropbox.com/s/bambj1hlkxwdhrm/qt4_15_before.png?dl=0
https://www.dropbox.com/s/xtiryrxhoq7ht02/qt5_13_after.png?dl=0
https://www.dropbox.com/s/sxjwrno7xe347a5/qt5_13_before.png?dl=0
https://www.dropbox.com/s/o85jugavc62fk7l/qt5_15_after.png?dl=0
https://www.dropbox.com/s/7zfbgfatvvssh55/qt5_15_before.png?dl=0

I've tested with Arabic, French, and German.

The patch solves two issues:

1. gets rid of the issue with the radio buttons that I posted about.

2. makes room for both the "Outline" and "Settings" tab names to show,
so there is no clipping and the arrows are not needed (did other people
see this issue as well or just me?).

The second issue that is solved is partly by luck, and that is good.
That is to say, the vertical size is not determined based on the tab
names. Thus the bad news is that the little arrows that annoy me could
come back (i.e. this change is not robust). The good news is that we do
not have to be worried that there are translations with long names for
the tab names that would make the vertical size extremely large.

The disadvantage of the patch is that the minimum size required is now
larger than before. Perhaps some people not as bothered as I was by the
two issues I mention above prefer to have the smaller vertical size. I
attempted to make it so that the widget containing the list of debug
levels (named "outTE") was not important in determining the size (there
is a scrollbar anyway), but I failed to figure this out. I did my
testing on a 13-inch screen and the increase did not bother me at all so
I don't expect others to mind it, but I bring this up just in case.
 
As for the patch itself, I don't know much about ui files so I am
proposing it mostly based on the "it works for me" principle. From what
I understand, many editors of the ui files before me have used the same
principle. My approach was to remove some numbers that seemed arbitrary
to me.

Any objection?

Scott
From 3c19a922d384b6544434bfdd74a4f44538853326 Mon Sep 17 00:00:00 2001
From: Scott Kostyshak 
Date: Tue, 14 Jun 2016 16:42:25 -0400
Subject: [PATCH] Fix two UI issues in the messages pane

1. sets the correct height for the radio buttons to avoid clipping

2. makes room for both the "Outline" and "Settings" tab names to
show, so there is no clipping and the arrows are not needed.

The second issue above is solved partly by luck, and that is good.
That is to say, the vertical size is not determined based on the tab
names. Thus the bad news is that the little arrows could come back
when we make future changes to this ui file (i.e. this change is not
robust). The good news is that we do not have to be worried that
there are translations with long names for the tab names that would
make the vertical size of the widget extremely large.

The disadvantage of this patch is that the minimum size required by
the messages pane is now larger than before. Perhaps some people not
as bothered as I was by the two issues I mention above prefer to
have the smaller vertical size. I attempted to make it so that the
widget containing the list of debug levels (named "outTE") was not
important in determining the size (there is a scrollbar anyway), but
I failed to figure this out.
---
 src/frontends/qt4/ui/ProgressViewUi.ui | 54 --
 1 file changed, 54 deletions(-)

diff --git a/src/frontends/qt4/ui/ProgressViewUi.ui 
b/src/frontends/qt4/ui/ProgressViewUi.ui
index 1ae1c6d..356d2ad 100644
--- a/src/frontends/qt4/ui/ProgressViewUi.ui
+++ b/src/frontends/qt4/ui/ProgressViewUi.ui
@@ -4,40 +4,6 @@
  
  ProgressViewUi
  
-  
-   
-0
-0
-543
-298
-   
-  
-  
-   
-7
-13
-0
-0
-   
-  
-  
-   
-0
-0
-   
-  
-  
-   
-0
-0
-   
-  
-  
-   
-0
-0
-   
-  
   

   
@@ -53,20 +19,6 @@
  
   true
  
- 
-  
-   7
-   13
-   0
-   0
-  
- 
- 
-  
-   0
-   0
-  
- 
  
   false
  
@@ -106,12 +58,6 @@
0
   
  
- 
-  
-   16777215
-   16777215
-  
- 
  
   QFrame::StyledPanel
  
-- 
2.1.4



signature.asc
Description: PGP signature

Re: One official build system?

[Scott Kostyshak]

On Tue, Jun 14, 2016 at 10:03:15PM +0200, Kornel Benko wrote:
> Am Dienstag, 14. Juni 2016 um 14:56:21, schrieb Scott Kostyshak 
> 
> > On Tue, Jun 14, 2016 at 10:02:23AM +0200, Kornel Benko wrote:
> > > Am Montag, 13. Juni 2016 um 19:09:04, schrieb Scott Kostyshak 
> > > 
> > > > Note also that for me make package_source produces a tar.gz, not a
> > > > tar.xz as you suggested above.
> > > 
> > > It depends on how you configure, so that 'make package' knows what to 
> > > produce.
> > > 1.)  -DCPACK_SOURCE_TGZ:BOOL=ON
> > >   -> .tar.gz
> > > 2.)  -DCPACK_SOURCE_TBZ2:BOOL=ON
> > >   -> .bz2
> > > 3.) -DCPACK_SOURCE_TZ:BOOL=ON
> > >   -> .tar.Z
> > > or
> > > 4.)  -DCPACK_SOURCE_ZIP:BOOL=ON
> > >   -> nothing on linux
> > > 
> > > (Select only one of them)
> > > But, yes, .tar.xz is not created :(
> > 
> > OK
> > 
> > > For the differences:
> > >   'make git-archive' and 'make package_source' create different files.
> > > Which one have you used for comparison?
> > 
> > I used make package_source.
> > 
> > > Here, 'make package_source' creates
> > >   LyX-2.3.tar.gz
> > >   LyX-2.3.tar.xz
> > >   LyX-2.3.tar.Z
> > 
> > Ah so xz is created? I must have missed that.
> > 
> > If you have time and want to take a look, compare the tar.gz you get
> > from CMake to the 2.2.0 tar from the following command:
> > yourself: ./autogen.sh && ./configure && make lyxdist
> 
> I made it. But I do not see many differences.
> To test:
>   # cd  /usr/BUILD/BuildLyxGitQt5.6mainAutomake
>   # make lyxdist
>   # cd /usr/BUILD/BuildLyxGitQt5.6main-gcc5.3
>   # make package_source
>   # cd ~/tmp
>   # mkdir -p compare/automake
>   # cd compare/automake
>   # tar axvf /usr/BUILD/BuildLyxGitQt5.6mainAutomake/lyx-2.3.0dev.tar.gz
>   # cd ~/tmp
>   # mkdir -p compare/cmake
>   # cd compare/cmake
>   # tar axvf /usr/BUILD/BuildLyxGitQt5.6main-gcc5.3/LyX-2.3.tar.gz
>   # cd LyX-2.3
>   # diff -r .  ~/tmp/compare/automake/lyx-2.3.0dev/.
> 
> The result is that cmake part misses
>   Makefile.in
> automake misses
>   lib/fonts/*.sfd (11 files)
>   lib/images/ipa/*.svgz (30 files)
>   lib/images/oxygen/*.svgz (88 files)
>   src/mathed/InsetMathXYArrow.{cpp,h}
>   3rdparty/boost/libs/regex/src/{icu,usinstances,wc_regex_traits}.cpp
> 
> There are also many files in cmake-tar which are only for tests and not 
> important.
> But the automake missed files are more than serious IMHO.

Thanks for doing that. I guess I just saw a large diff and did not look
closely enough to categorize the items. Looks like there is not any
major problem then.

Good news.

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Cmake build: Check for QPA_XCB when QT_USES_X11 is known

[Scott Kostyshak]

On Tue, Jun 14, 2016 at 10:24:18PM +0200, Georg Baum wrote:
> Scott Kostyshak wrote:
> 
> > Thanks to your comment, I realized that when I copy the master directory
> > to e.g. master-mingw, the lyx-dependencies folder came with the copy. I
> > removed that directory, and then removed the monolithic build option,
> > and now it works for me.
> 
> To me it does rather look like a copied build folder caused the errors, 
> because the build folder contained .cpp files produced by the wrong moc.
> 
> > With the monolithic build option, it still fails for me.
> > 
> > Does that give us a clue for how to fix the build for me with the
> > monolithic build option? Note that the monolithic build works fine for
> > me when building normally (with both autotools and CMake)
> 
> Unfortunately I have no idea, but I don't trust monolithic builds anyway. 
> They produce a lot more interaction between different parts of the sources, 
> and IIRC the compiler is also allowed to do clever optimizations inside one 
> compilation unit. My guess would be that you see something like that.

OK good to know.

> The xmingw script works fine for me BTW with the monolithic build.

What is your version? Kornel has 4.8.2 and it works for him.

It does not work for me with either

$ i686-w64-mingw32-g++ --version
i686-w64-mingw32-g++ (GCC) 4.9.2

or

$ /usr/bin/i686-w64-mingw32-g++ --version
i686-w64-mingw32-g++ (GCC) 5.3.1 20160211

Scott


signature.asc
Description: PGP signature

Re: Tarballs for LyX 2.2.0 are on FTP

[Enrico Forestieri]

On Fri, Jun 10, 2016 at 10:20:32PM +0100, Guillaume Munch wrote:
> As for lyx2lyx, I gave one example of a commit which explicitly said
> that it would not be made round-trip, and another example where it had
> to be fixed afterwards because a special case was not taken into
> accountn because it is developped on a trial-and-error basis.

Yes, development should not be performed on a trial-and-error basis.
Thanks for the mud.

-- 
Enrico

Re: lyx and dark color schemes

[Cor Blom]

Op 14-06-16 om 22:21 schreef Guillaume Munch:

Le 14/06/2016 21:16, Cor Blom a écrit :

Op 14-06-16 om 22:09 schreef Guillaume Munch:

Le 14/06/2016 18:44, Cor Blom a écrit :

Hi,

Recently I tried lyx with a dark color scheme (breeze-dark  under kde
plasma 5). Ihe toolbar icons are problematic, but I know how to fix
that
(and the oxygen set is not that bad against a dark background). In
general I'm happy about it. There is one issue. I don't know whether
it's possible and I'm missing something, or not.

Under de Documents > Settings, in the preamble part, blue is used for
code. Against a dark background this is unreadable. Also in the code
view panel, de latex commands are blue, which makes them unreadable. Is
that color configurable somewhere? I've searched but can't find the
solution.

Thanks,

Cor



Hi,

Can you compile master and test a patch I send you?

Guillaume




Yes I can.

Cor






Thanks! This is a huge improvement. I have now readable purple text 
against the dark background.


Cor

Re: [PATCH] unique_ptr and some clean-up

[Georg Baum]

Guillaume Munch wrote:

> What error is it?

../../src/MetricsInfo.cpp:61:4: error: type ‘lyx::MetricsBase’ is not a 
direct base of ‘lyx::MetricsBase’


BTW, if it is possible to keep gcc 4.6 supported for a while with little 
effort I am in favour of this as well, and I can do also some testing or 
fixing if needed (this should improve my C++11 knowledge as well). What we 
do have learnt from this exercise is that anything older than gcc 4.6 does 
not make sense, so we should bump the current requirement from 4.3 to 4.6.



Georg

Re: One official build system?

[Georg Baum]

Kornel Benko wrote:

> The result is that cmake part misses
> Makefile.in
> automake misses
> lib/fonts/*.sfd (11 files)
> lib/images/ipa/*.svgz (30 files)
> lib/images/oxygen/*.svgz (88 files)
> src/mathed/InsetMathXYArrow.{cpp,h}
> 3rdparty/boost/libs/regex/src/{icu,usinstances,wc_regex_traits}.cpp
> 
> There are also many files in cmake-tar which are only for tests and not
> important. But the automake missed files are more than serious IMHO.

Not all missing files are a problem. InsetMathXYArrow is dead code and the 
.sfd files are left out on purpose as well (only usable by font experts).

The icons and the regex files are indeed a serious problem. The icons should 
be fixed now, this was simply a wrong style of using variables. I'll take 
care for the regex files later, but what I do not understand is how the 
official windows build could succeed without these files (because of 
http://www.lyx.org/trac/ticket/9373). I fear that (again) the official 
installers were produced from git and not from an unpacked .tar.gz. Or bug 
9373 is magically fixed and nobody noticed.


Georg

Re: lyx and dark color schemes

[Guillaume Munch]

Le 14/06/2016 21:16, Cor Blom a écrit :

Op 14-06-16 om 22:09 schreef Guillaume Munch:

Le 14/06/2016 18:44, Cor Blom a écrit :

Hi,

Recently I tried lyx with a dark color scheme (breeze-dark  under kde
plasma 5). Ihe toolbar icons are problematic, but I know how to fix that
(and the oxygen set is not that bad against a dark background). In
general I'm happy about it. There is one issue. I don't know whether
it's possible and I'm missing something, or not.

Under de Documents > Settings, in the preamble part, blue is used for
code. Against a dark background this is unreadable. Also in the code
view panel, de latex commands are blue, which makes them unreadable. Is
that color configurable somewhere? I've searched but can't find the
solution.

Thanks,

Cor



Hi,

Can you compile master and test a patch I send you?

Guillaume




Yes I can.

Cor




diff --git a/src/frontends/qt4/LaTeXHighlighter.cpp b/src/frontends/qt4/LaTeXHighlighter.cpp
index 9a9e545..fa949a6 100644
--- a/src/frontends/qt4/LaTeXHighlighter.cpp
+++ b/src/frontends/qt4/LaTeXHighlighter.cpp
@@ -19,13 +19,23 @@
 namespace lyx {
 namespace frontend {
 
+
 LaTeXHighlighter::LaTeXHighlighter(QTextDocument * parent)
 	: QSyntaxHighlighter(parent)
 {
-	keywordFormat.setForeground(Qt::darkBlue);
+	auto blend = [](QColor color1, QColor color2) {
+		int r = 0.5 * (color1.red() + color2.red());
+		int g = 0.5 * (color1.green() + color2.green());
+		int b = 0.5 * (color1.blue() + color2.blue());
+		return QColor(r, g, b);
+	};
+	QPalette palette = QPalette();
+	QColor text_color = palette.color(QPalette::Active, QPalette::Text);
+	keywordFormat.setForeground(blend(Qt::blue, text_color));
 	keywordFormat.setFontWeight(QFont::Bold);
-	commentFormat.setForeground(Qt::darkGray);
-	mathFormat.setForeground(Qt::red);
+	commentFormat.setForeground(palette.color(QPalette::Disabled,
+	  QPalette::Text));
+	mathFormat.setForeground(blend(Qt::red, text_color));
 	warningFormat.setForeground(Qt::red);
 	warningFormat.setFontWeight(QFont::Bold);
 }

Re: [LyX/master] Cmake build: Check for QPA_XCB when QT_USES_X11 is known

[Georg Baum]

Scott Kostyshak wrote:

> Thanks to your comment, I realized that when I copy the master directory
> to e.g. master-mingw, the lyx-dependencies folder came with the copy. I
> removed that directory, and then removed the monolithic build option,
> and now it works for me.

To me it does rather look like a copied build folder caused the errors, 
because the build folder contained .cpp files produced by the wrong moc.

> With the monolithic build option, it still fails for me.
> 
> Does that give us a clue for how to fix the build for me with the
> monolithic build option? Note that the monolithic build works fine for
> me when building normally (with both autotools and CMake)

Unfortunately I have no idea, but I don't trust monolithic builds anyway. 
They produce a lot more interaction between different parts of the sources, 
and IIRC the compiler is also allowed to do clever optimizations inside one 
compilation unit. My guess would be that you see something like that.

The xmingw script works fine for me BTW with the monolithic build.


Georg

Re: [PATCH] unique_ptr and some clean-up

[Guillaume Munch]

Le 14/06/2016 20:55, Georg Baum a écrit :

Guillaume Munch wrote:


Le 14/06/2016 16:38, Jean-Marc Lasgouttes a écrit :


but of course RefChange
proved more difficult. I tried to define it as a subclass of
unique_ptr, but then my C++11 default skills showed
their weakness.


What errors does it give with the attached?


Only errors about constructor inheritance.
With the attached patch in addition it compiles fine & passes all tests.


Thanks.

What error is it?


I
am not proposing to use the patch as-is, but it does not only make things
worse: It avoids to initialize members twice.


I should have done the obvious converse: initialize the short 
constructor from the long constructor.





Georg

PS: If anyone running debian wants to test old compilers easily you can
simply install packages from older releases. For example, I used gcc-4.6,
g++-4.6 and corresponding dependencies from wheezy on a jessie system (the
packages do not interfere with the default compiler which is gcc 4.9). This
might work on ubuntu as well, but I did not try.



Good idea, this should work on Ubuntu.

Re: lyx and dark color schemes

[Cor Blom]

Op 14-06-16 om 22:09 schreef Guillaume Munch:

Le 14/06/2016 18:44, Cor Blom a écrit :

Hi,

Recently I tried lyx with a dark color scheme (breeze-dark  under kde
plasma 5). Ihe toolbar icons are problematic, but I know how to fix that
(and the oxygen set is not that bad against a dark background). In
general I'm happy about it. There is one issue. I don't know whether
it's possible and I'm missing something, or not.

Under de Documents > Settings, in the preamble part, blue is used for
code. Against a dark background this is unreadable. Also in the code
view panel, de latex commands are blue, which makes them unreadable. Is
that color configurable somewhere? I've searched but can't find the
solution.

Thanks,

Cor



Hi,

Can you compile master and test a patch I send you?

Guillaume




Yes I can.

Cor

Re: [PATCH] unique_ptr and some clean-up

[Georg Baum]

Guillaume Munch wrote:

> Le 14/06/2016 16:38, Jean-Marc Lasgouttes a écrit :
> 
>> but of course RefChange
>> proved more difficult. I tried to define it as a subclass of
>> unique_ptr, but then my C++11 default skills showed
>> their weakness.
> 
> What errors does it give with the attached?

Only errors about constructor inheritance.
With the attached patch in addition it compiles fine & passes all tests. I 
am not proposing to use the patch as-is, but it does not only make things 
worse: It avoids to initialize members twice.


Georg

PS: If anyone running debian wants to test old compilers easily you can 
simply install packages from older releases. For example, I used gcc-4.6, 
g++-4.6 and corresponding dependencies from wheezy on a jessie system (the 
packages do not interfere with the default compiler which is gcc 4.9). This 
might work on ubuntu as well, but I did not try.diff --git a/src/MetricsInfo.cpp b/src/MetricsInfo.cpp
index 5e10df1..e9821e3 100644
--- a/src/MetricsInfo.cpp
+++ b/src/MetricsInfo.cpp
@@ -58,11 +58,23 @@ MetricsBase::MetricsBase()
 
 
 MetricsBase::MetricsBase(BufferView * b, FontInfo f, int w)
-	: MetricsBase()
+	: bv(b), font(f), style(LM_ST_TEXT), fontname("mathnormal"), textwidth(w),
+	  solid_line_thickness_(1), solid_line_offset_(1), dotted_line_thickness_(1)
 {
-	bv = b;
-	font = f;
-	textwidth = w;
+	if (lyxrc.zoom >= 200) {
+		// derive the line thickness from zoom factor
+		// the zoom is given in percent
+		// (increase thickness at 250%, 450% etc.)
+		solid_line_thickness_ = (lyxrc.zoom + 50) / 200;
+		// adjust line_offset_ too
+		solid_line_offset_ = 1 + solid_line_thickness_ / 2;
+	}
+	if (lyxrc.zoom >= 100) {
+		// derive the line thickness from zoom factor
+		// the zoom is given in percent
+		// (increase thickness at 150%, 250% etc.)
+		dotted_line_thickness_ = (lyxrc.zoom + 50) / 100;
+	}
 }
 
 
diff --git a/src/mathed/MathStream.cpp b/src/mathed/MathStream.cpp
index e91db43..48a54ae 100644
--- a/src/mathed/MathStream.cpp
+++ b/src/mathed/MathStream.cpp
@@ -124,12 +124,11 @@ WriteStream & operator<<(WriteStream & ws, docstring const & s)
 
 WriteStream::WriteStream(otexrowstream & os, bool fragile, bool latex,
 		 OutputType output, Encoding const * encoding)
-	: WriteStream(os)
+	: os_(os), fragile_(fragile), firstitem_(false), latex_(latex),
+	  output_(output), pendingspace_(false), pendingbrace_(false),
+	  textmode_(false), locked_(0), ascii_(0), canbreakline_(true),
+	  line_(0), encoding_(encoding), row_entry_(TexRow::row_none)
 {
-	fragile_ = fragile;
-	latex_ = latex;
-	output_ = output;
-	encoding_ = encoding;
 }
 
 

Re: lyx and dark color schemes

[Guillaume Munch]

Le 14/06/2016 18:44, Cor Blom a écrit :

Hi,

Recently I tried lyx with a dark color scheme (breeze-dark  under kde
plasma 5). Ihe toolbar icons are problematic, but I know how to fix that
(and the oxygen set is not that bad against a dark background). In
general I'm happy about it. There is one issue. I don't know whether
it's possible and I'm missing something, or not.

Under de Documents > Settings, in the preamble part, blue is used for
code. Against a dark background this is unreadable. Also in the code
view panel, de latex commands are blue, which makes them unreadable. Is
that color configurable somewhere? I've searched but can't find the
solution.

Thanks,

Cor



Hi,

Can you compile master and test a patch I send you?

Guillaume

Re: #10214: Fail to Compile LyX with Visual C++ 2015

[Georg Baum]

Kornel Benko wrote:

> I'd like to remove the file development/cmake/configCompiler.h.msvc. It
> was meant as a cache-like set for compiler settings for msvc.

+1

> As a first step I want to disable the possibility to select this bypass
> (see attached) I expect this works for windows, but will wait for
> confirmation.

If you did not ask the bug reporter already I suggest to do that. This is 
probably the fastet way to get a confirmation.


Georg

Re: One official build system?

[Kornel Benko]

Am Dienstag, 14. Juni 2016 um 14:56:21, schrieb Scott Kostyshak 

> On Tue, Jun 14, 2016 at 10:02:23AM +0200, Kornel Benko wrote:
> > Am Montag, 13. Juni 2016 um 19:09:04, schrieb Scott Kostyshak 
> > 
> > > Note also that for me make package_source produces a tar.gz, not a
> > > tar.xz as you suggested above.
> > 
> > It depends on how you configure, so that 'make package' knows what to 
> > produce.
> > 1.)  -DCPACK_SOURCE_TGZ:BOOL=ON
> > -> .tar.gz
> > 2.)  -DCPACK_SOURCE_TBZ2:BOOL=ON
> > -> .bz2
> > 3.) -DCPACK_SOURCE_TZ:BOOL=ON
> > -> .tar.Z
> > or
> > 4.)  -DCPACK_SOURCE_ZIP:BOOL=ON
> > -> nothing on linux
> > 
> > (Select only one of them)
> > But, yes, .tar.xz is not created :(
> 
> OK
> 
> > For the differences:
> > 'make git-archive' and 'make package_source' create different files.
> > Which one have you used for comparison?
> 
> I used make package_source.
> 
> > Here, 'make package_source' creates
> > LyX-2.3.tar.gz
> > LyX-2.3.tar.xz
> > LyX-2.3.tar.Z
> 
> Ah so xz is created? I must have missed that.
> 
> If you have time and want to take a look, compare the tar.gz you get
> from CMake to the 2.2.0 tar from the following command:
> yourself: ./autogen.sh && ./configure && make lyxdist

I made it. But I do not see many differences.
To test:
# cd  /usr/BUILD/BuildLyxGitQt5.6mainAutomake
# make lyxdist
# cd /usr/BUILD/BuildLyxGitQt5.6main-gcc5.3
# make package_source
# cd ~/tmp
# mkdir -p compare/automake
# cd compare/automake
# tar axvf /usr/BUILD/BuildLyxGitQt5.6mainAutomake/lyx-2.3.0dev.tar.gz
# cd ~/tmp
# mkdir -p compare/cmake
# cd compare/cmake
# tar axvf /usr/BUILD/BuildLyxGitQt5.6main-gcc5.3/LyX-2.3.tar.gz
# cd LyX-2.3
# diff -r .  ~/tmp/compare/automake/lyx-2.3.0dev/.

The result is that cmake part misses
Makefile.in
automake misses
lib/fonts/*.sfd (11 files)
lib/images/ipa/*.svgz (30 files)
lib/images/oxygen/*.svgz (88 files)
src/mathed/InsetMathXYArrow.{cpp,h}
3rdparty/boost/libs/regex/src/{icu,usinstances,wc_regex_traits}.cpp

There are also many files in cmake-tar which are only for tests and not 
important.
But the automake missed files are more than serious IMHO.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] unique_ptr and some clean-up

[Guillaume Munch]

Le 14/06/2016 20:16, Jean-Marc Lasgouttes a écrit :

Le 14/06/16 à 18:41, Guillaume Munch a écrit :


but of course RefChange
proved more difficult. I tried to define it as a subclass of
unique_ptr, but then my C++11 default skills showed
their weakness.


What errors does it give with the attached?


I will not be able to test until Thursday afternoon.



RER is on strike ? ;)

Re: [PATCH] unique_ptr and some clean-up

[Jean-Marc Lasgouttes]

Le 14/06/16 à 18:41, Guillaume Munch a écrit :


but of course RefChange
proved more difficult. I tried to define it as a subclass of
unique_ptr, but then my C++11 default skills showed
their weakness.


What errors does it give with the attached?


I will not be able to test until Thursday afternoon.

JMarc

Re: One official build system?

[Scott Kostyshak]

On Tue, Jun 14, 2016 at 10:02:23AM +0200, Kornel Benko wrote:
> Am Montag, 13. Juni 2016 um 19:09:04, schrieb Scott Kostyshak 
> 
> > Note also that for me make package_source produces a tar.gz, not a
> > tar.xz as you suggested above.
> 
> It depends on how you configure, so that 'make package' knows what to produce.
> 1.)  -DCPACK_SOURCE_TGZ:BOOL=ON
>   -> .tar.gz
> 2.)  -DCPACK_SOURCE_TBZ2:BOOL=ON
>   -> .bz2
> 3.) -DCPACK_SOURCE_TZ:BOOL=ON
>   -> .tar.Z
> or
> 4.)  -DCPACK_SOURCE_ZIP:BOOL=ON
>   -> nothing on linux
> 
> (Select only one of them)
> But, yes, .tar.xz is not created :(

OK

> For the differences:
>   'make git-archive' and 'make package_source' create different files.
> Which one have you used for comparison?

I used make package_source.

> Here, 'make package_source' creates
>   LyX-2.3.tar.gz
>   LyX-2.3.tar.xz
>   LyX-2.3.tar.Z

Ah so xz is created? I must have missed that.

If you have time and want to take a look, compare the tar.gz you get
from CMake to the 2.2.0 tar from the following command:
yourself: ./autogen.sh && ./configure && make lyxdist

Alternatively, we can wait until we figure out other CMake issues if you
prefer.

Scott

> 
> and 'make git-archive' creates
>   LyX-2.3.0-47802git-Linux.tgz
> 
>   Kornel




signature.asc
Description: PGP signature

Re: One official build system?

[Pavel Sanda]

Kornel Benko wrote:
> (Select only one of them)
> But, yes, .tar.xz is not created :(

I know nothing of cmake, but we really want .xz. 
Not only it gets better compression ratio but it's
standard already:
http://henrich-on-debian.blogspot.cz/2016/06/which-compression-do-debian-packages-use.html

I guess you can easily code it like we do in autotools.
Pavel

Re: scrunched radio buttons on message pane

[Paul A . Rubin]

Scott Kostyshak  lyx.org> writes:

> 
> Does anyone else see that the radio buttons are cut-off on the message
> pane?
> 

FWIW, they're find with LyX 2.2.0 /Qt 4.8.6 on Linux Mint Rebecca.

Paul

lyx and dark color schemes

[Cor Blom]

Hi,

Recently I tried lyx with a dark color scheme (breeze-dark  under kde 
plasma 5). Ihe toolbar icons are problematic, but I know how to fix that 
(and the oxygen set is not that bad against a dark background). In 
general I'm happy about it. There is one issue. I don't know whether 
it's possible and I'm missing something, or not.


Under de Documents > Settings, in the preamble part, blue is used for 
code. Against a dark background this is unreadable. Also in the code 
view panel, de latex commands are blue, which makes them unreadable. Is 
that color configurable somewhere? I've searched but can't find the 
solution.


Thanks,

Cor

Re: [LyX/master] Add perf comment

[Guillaume Munch]

Le 14/06/2016 17:31, Jean-Marc Lasgouttes a écrit :

Le 14/06/2016 à 18:06, Guillaume Munch a écrit :

Interesting. Is it only the loop in itself that is costly, or some of
the functions it calls?



The combined loop and recursion, I believe.


But is the usual behavior is a no-op, except for the few redefinitions
done by the user, right?



No, it is also called for the default bindings I believe.

Re: [LyX/master] Add some comments to fix coverity #23386.

[Richard Heck]

On 06/14/2016 05:35 PM, Jean-Marc Lasgouttes wrote:

Le 14/06/2016 à 18:29, Richard Heck a écrit :

It's actually set by the call in createView to the GuiView constructor,
which calls setCurrentView.

Maybe we should add an assertion here?


OK, maybe coverity does not know that guiapp is the same 
GuiApplication object.


I do not know what is the right way to signal it to coverity. Maybe 
indeed adding an assertion in createView would be good.


I will add one and, for the moment, remove the coverity comment. We can 
see on next compile whether the assertion is enough to make coverity 
happy. If not, I think we can add a model for doAssert that will solve 
the problem.


Richard

InPreamble Tag: Bug #10215

[Richard Heck]

Suppose you have a style like this:

Style Test
  LaTeXType command
  LaTeXName whatever
  InPreamble 1
  Preamble
\newcommand\whatever[1]{#1}
  EndPreamble
End

Then LyX gives you:

% LyX specific LaTeX commands.
\whatever{this is a test}

% Textclass specific LaTeX commands.
\newcommand\whatever[1]{#1}

Which will of course fail. Obviously, the problem is that we output the 
"Preamble" code *after* we output the code from the paragraph itself.


This seems to me to count as a bug. To fix it, though, we'd obviously 
have to output the code from the style AFTER the Preamble, which would 
change the TeX export of lots of files. An alternative would be to 
introduce a new tag that would basically mean: Output this before or 
after the Preamble code. But I can't imagine why you'd want to do it 
before the Preamble code.


Thoughts?

Richard

Re: [PATCH] unique_ptr and some clean-up

[Guillaume Munch]

Le 14/06/2016 16:38, Jean-Marc Lasgouttes a écrit :

Le 14/06/2016 à 16:39, Guillaume Munch a écrit :

I am a little short on ideas so we could try the attached, and if it
does not work try the commented version below it, and if it does not
work, revert e87febd0 for the moment. What I am concerned about is
future breakages, about which I will ask that you be patient (as you
have been so far—thank you). I do not have g++ 4.6, so I will set up my
test-before-commit build with g++ 4.8 and fixes for 4.6 will be done as
breakages happen.


The second version did work. I managed to get around the new aliasing
thing in Changer.h using a plain old typedef,


Yes, this should be synonymous.


but of course RefChange
proved more difficult. I tried to define it as a subclass of
unique_ptr, but then my C++11 default skills showed
their weakness.


What errors does it give with the attached?

diff --git a/src/support/Changer.h b/src/support/Changer.h
index 8f24ba5..9d85c26 100644
--- a/src/support/Changer.h
+++ b/src/support/Changer.h
@@ -24,7 +24,9 @@ struct Revertible {
 	virtual void keep() {}
 };
 
-using Changer = unique_ptr;
+//for gcc 4.6
+//using Changer = unique_ptr;
+typedef unique_ptr Changer;
 
 
 }
diff --git a/src/support/RefChanger.h b/src/support/RefChanger.h
index 9b9d020..baf3d84 100644
--- a/src/support/RefChanger.h
+++ b/src/support/RefChanger.h
@@ -45,7 +45,19 @@ private:
 	bool enabled;
 };
 
+
+//for gcc 4.6
+#if defined(__GNUC__) && (__GNUC__ == 4) && (__GNUC_MINOR__ == 6)
+template 
+struct RefChanger : unique_ptr
+{
+	RefChanger(unique_ptr p)
+		: unique_ptr(move(p))
+		{}
+};
+#else
 template  using RefChanger = unique_ptr;
+#endif
 
 
 /// Saves the value of \param ref in a movable object

Re: [LyX/master] Add some comments to fix coverity #23386.

[Jean-Marc Lasgouttes]

Le 14/06/2016 à 18:29, Richard Heck a écrit :

It's actually set by the call in createView to the GuiView constructor,
which calls setCurrentView.

Maybe we should add an assertion here?


OK, maybe coverity does not know that guiapp is the same GuiApplication 
object.


I do not know what is the right way to signal it to coverity. Maybe 
indeed adding an assertion in createView would be good.


JMarc

Re: [LyX/master] Add perf comment

[Jean-Marc Lasgouttes]

Le 14/06/2016 à 18:06, Guillaume Munch a écrit :

Interesting. Is it only the loop in itself that is costly, or some of
the functions it calls?



The combined loop and recursion, I believe.


But is the usual behavior is a no-op, except for the few redefinitions 
done by the user, right?


JMarc

Re: [LyX/master] Add some comments to fix coverity #23386.

[Richard Heck]

On 06/14/2016 05:17 PM, Jean-Marc Lasgouttes wrote:

Le 12/06/2016 à 06:46, Richard Heck a écrit :

commit 1bd5ef9a754a5b521f9d067b68fdac26035ef342
Author: Richard Heck 
Date:   Sat Jun 11 23:26:02 2016 -0400

Add some comments to fix coverity #23386.

diff --git a/src/frontends/qt4/GuiApplication.cpp 
b/src/frontends/qt4/GuiApplication.cpp

index 460d7ad..022418f 100644
--- a/src/frontends/qt4/GuiApplication.cpp
+++ b/src/frontends/qt4/GuiApplication.cpp
@@ -1670,7 +1670,10 @@ void GuiApplication::dispatch(FuncRequest 
const & cmd, DispatchResult & dr)

 boost::crc_32_type crc;
 crc = for_each(fname.begin(), fname.end(), crc);
 createView(crc.checksum());
+// we know current_view_ is non-null, because createView 
sets it.


Could you explain where does createView set current_view_? I am lost 
in this function. Normally coverity is able to follow these things.


It's actually set by the call in createView to the GuiView constructor, 
which calls setCurrentView.


Maybe we should add an assertion here?

Richard

Re: [LyX/master] Add perf comment

[Guillaume Munch]

Le 14/06/2016 17:01, Jean-Marc Lasgouttes a écrit :

Le 12/06/2016 à 20:23, Guillaume Munch a écrit :

commit 89175ee0f10f75311e2a746dbd450fb23d6c2845
Author: Guillaume Munch 
Date:   Sat Jun 11 09:14:38 2016 +0100

Add perf comment

diff --git a/src/KeyMap.cpp b/src/KeyMap.cpp
index 7628d0d..32f9926 100644
--- a/src/KeyMap.cpp
+++ b/src/KeyMap.cpp
@@ -106,6 +106,8 @@ void KeyMap::bind(KeySequence * seq, FuncRequest
const & func, unsigned int r)
 KeyModifier const mod2 = seq->modifiers[r].second;

 // check if key is already there
+// FIXME perf: Profiling shows that this is responsible of 99% of
the
+// cost of GuiPrefs::applyView()
 Table::iterator end = table.end();


Interesting. Is it only the loop in itself that is costly, or some of
the functions it calls?



The combined loop and recursion, I believe.

Re: [LyX/master] Add some comments to fix coverity #23386.

[Jean-Marc Lasgouttes]

Le 12/06/2016 à 06:46, Richard Heck a écrit :

commit 1bd5ef9a754a5b521f9d067b68fdac26035ef342
Author: Richard Heck 
Date:   Sat Jun 11 23:26:02 2016 -0400

Add some comments to fix coverity #23386.

diff --git a/src/frontends/qt4/GuiApplication.cpp 
b/src/frontends/qt4/GuiApplication.cpp
index 460d7ad..022418f 100644
--- a/src/frontends/qt4/GuiApplication.cpp
+++ b/src/frontends/qt4/GuiApplication.cpp
@@ -1670,7 +1670,10 @@ void GuiApplication::dispatch(FuncRequest const & cmd, 
DispatchResult & dr)
boost::crc_32_type crc;
crc = for_each(fname.begin(), fname.end(), crc);
createView(crc.checksum());
+   // we know current_view_ is non-null, because 
createView sets it.


Could you explain where does createView set current_view_? I am lost in 
this function. Normally coverity is able to follow these things.


JMarc


+   // coverity[FORWARD_NULL]
current_view_->openDocument(fname);
+   // FIXME but then why check current_view_ here?
if (current_view_ && 
!current_view_->documentBufferView())
current_view_->close();
} else {

Re: [LyX/master] Add perf comment

[Jean-Marc Lasgouttes]

Le 12/06/2016 à 20:23, Guillaume Munch a écrit :

commit 89175ee0f10f75311e2a746dbd450fb23d6c2845
Author: Guillaume Munch 
Date:   Sat Jun 11 09:14:38 2016 +0100

Add perf comment

diff --git a/src/KeyMap.cpp b/src/KeyMap.cpp
index 7628d0d..32f9926 100644
--- a/src/KeyMap.cpp
+++ b/src/KeyMap.cpp
@@ -106,6 +106,8 @@ void KeyMap::bind(KeySequence * seq, FuncRequest const & 
func, unsigned int r)
KeyModifier const mod2 = seq->modifiers[r].second;

// check if key is already there
+   // FIXME perf: Profiling shows that this is responsible of 99% of the
+   // cost of GuiPrefs::applyView()
Table::iterator end = table.end();


Interesting. Is it only the loop in itself that is costly, or some of 
the functions it calls?


JMarc

Re: [PATCH] unique_ptr and some clean-up

[Jean-Marc Lasgouttes]

Le 14/06/2016 à 16:39, Guillaume Munch a écrit :

I am a little short on ideas so we could try the attached, and if it
does not work try the commented version below it, and if it does not
work, revert e87febd0 for the moment. What I am concerned about is
future breakages, about which I will ask that you be patient (as you
have been so far—thank you). I do not have g++ 4.6, so I will set up my
test-before-commit build with g++ 4.8 and fixes for 4.6 will be done as
breakages happen.


The second version did work. I managed to get around the new aliasing 
thing in Changer.h using a plain old typedef, but of course RefChange 
proved more difficult. I tried to define it as a subclass of 
unique_ptr, but then my C++11 default skills showed 
their weakness.


Here is what I have right now. If we manage to get somewhere we should 
keep both the new shiny constructs and the old crufty ones, guarded by 
the appropriate #ifdef.


JMarc



diff --git a/src/support/Changer.h b/src/support/Changer.h
index 8f24ba5..e395147 100644
--- a/src/support/Changer.h
+++ b/src/support/Changer.h
@@ -24,8 +24,9 @@ struct Revertible {
 	virtual void keep() {}
 };
 
-using Changer = unique_ptr;
-
+// for gcc 4.6
+//using Changer = unique_ptr;
+typedef unique_ptr Changer;
 
 }
 
diff --git a/src/support/unicode.cpp b/src/support/unicode.cpp
index 187d018..c1bc5df 100644
--- a/src/support/unicode.cpp
+++ b/src/support/unicode.cpp
@@ -66,6 +66,14 @@ IconvProcessor::IconvProcessor(string tocode, string fromcode)
 {}
 
 
+// for gcc 4.6
+//IconvProcessor::IconvProcessor(IconvProcessor &&) = default;
+IconvProcessor::IconvProcessor(IconvProcessor && other)
+	: tocode_(move(other.tocode_)), fromcode_(move(other.fromcode_)),
+	  h_(move(other.h_))
+{}
+
+
 bool IconvProcessor::init()
 {
 	if (h_)
diff --git a/src/support/unicode.h b/src/support/unicode.h
index 6373e47..17b95dd 100644
--- a/src/support/unicode.h
+++ b/src/support/unicode.h
@@ -62,8 +62,8 @@ public:
 		char * out_buffer, size_t max_out_size);
 	/// target encoding
 	std::string to() const { return tocode_; }
-	// required by g++ 4.7
-	IconvProcessor(IconvProcessor &&) = default;
+	// required by g++ 4.6
+	IconvProcessor(IconvProcessor && other);
 };
 
 /// Get the global IconvProcessor instance of the current thread for

Re: [PATCH] unique_ptr and some clean-up

[Guillaume Munch]

Le 14/06/2016 10:38, Jean-Marc Lasgouttes a écrit :

Le 13/06/2016 à 23:15, Guillaume Munch a écrit :

I am not in charge for the machines around me and given 12.04 LTS
ends up
2017-04 I don't expect any migration happening soon :)


I am in a similar situation (although as I said, clang works). My fatest
machine runs 12.04, only updated in terms of security stuff, but not
software. I have little visibility on what updates to expect.


So I guess the bad news is I can't quickly bisect what's going on 32
cores
anymore, the good news is I'll get more real work done :)


Thank you Pavel for your understanding. I hope the inconvenience is
temporary.


I think that not having Pavel waste his time on LyX is a loss.


So is there a consensus that g++ 4.8 is a reasonable minimum version to
support?


Could we try for a little while to cope with gcc 4.6, with explicitly
marked code (that we can remove later) and see where this leads us?

In this case, for example, what would the cure be?



I am of course very happy to let Pavel and you spend more time on LyX.

I am a little short on ideas so we could try the attached, and if it
does not work try the commented version below it, and if it does not
work, revert e87febd0 for the moment. What I am concerned about is
future breakages, about which I will ask that you be patient (as you
have been so far—thank you). I do not have g++ 4.6, so I will set up my
test-before-commit build with g++ 4.8 and fixes for 4.6 will be done as
breakages happen.

Guillaume

diff --git a/src/support/unicode.cpp b/src/support/unicode.cpp
index 187d018..2d15ff0 100644
--- a/src/support/unicode.cpp
+++ b/src/support/unicode.cpp
@@ -66,6 +66,14 @@ IconvProcessor::IconvProcessor(string tocode, string fromcode)
 {}
 
 
+// for gcc 4.6
+IconvProcessor::IconvProcessor(IconvProcessor &&) = default;
+//IconvProcessor::IconvProcessor(IconvProcessor && other)
+//	: tocode_(move(other.tocode_)), fromcode_(move(other.fromcode_)),
+//	  h_(move(other.h_))
+//{}
+
+
 bool IconvProcessor::init()
 {
 	if (h_)
diff --git a/src/support/unicode.h b/src/support/unicode.h
index 6373e47..17b95dd 100644
--- a/src/support/unicode.h
+++ b/src/support/unicode.h
@@ -62,8 +62,8 @@ public:
 		char * out_buffer, size_t max_out_size);
 	/// target encoding
 	std::string to() const { return tocode_; }
-	// required by g++ 4.7
-	IconvProcessor(IconvProcessor &&) = default;
+	// required by g++ 4.6
+	IconvProcessor(IconvProcessor && other);
 };
 
 /// Get the global IconvProcessor instance of the current thread for

Re: scrunched radio buttons on message pane

[Andrew Parsloe]

On 14/06/2016 6:52 p.m., Scott Kostyshak wrote:

Does anyone else see that the radio buttons are cut-off on the message
pane?

Attached is a screenshot.

Scott

Attached is 2.2.0 on windows 7. No scrunching, but no colour.

Andrew


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: #10214: Fail to Compile LyX with Visual C++ 2015

[Kornel Benko]

Am Dienstag, 14. Juni 2016 um 02:24:02, schrieb LyX Ticket Tracker 

> #10214: Fail to Compile LyX with Visual C++ 2015
> -+--
>  Reporter:  zxvc |   Owner:  lasgouttes
>  Type:  defect   |  Status:  closed
>  Priority:  normal   |   Milestone:
> Component:  general  | Version:  unspecified
>  Severity:  normal   |  Resolution:  fixed
>  Keywords:   |
> -+--
> Changes (by zxvc):
>
>  * status:  reopened => closed
>  * resolution:   => fixed
>

I'd like to remove the file development/cmake/configCompiler.h.msvc. It was 
meant as
a cache-like set for compiler settings for msvc.

But it also bypasses new tests, so that it has to be maintained separately.

As a first step I want to disable the possibility to select this bypass (see 
attached)
I expect this works for windows, but will wait for confirmation.

Kornel

signature.asc
Description: This is a digitally signed message part.
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 1a52acc..9564bce 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -156,7 +156,7 @@ LYX_OPTION(PROFILE  "Build with options for gprof" OFF GCC)
 LYX_OPTION(CONSOLE   "Show console on Windows, enforce with =FORCE" ON MSVC)
 LYX_OPTION(VLD   "Use VLD with MSVC" OFF MSVC)
 LYX_OPTION(WALL  "Enable all warnings" OFF MSVC)
-LYX_OPTION(CONFIGURE_CHECKS  "Also run configure checks for MSVC" OFF MSVC)
+#LYX_OPTION(CONFIGURE_CHECKS  "Also run configure checks for MSVC" OFF MSVC)
 LYX_OPTION(DEPENDENCIES_DOWNLOAD "Download dependencies for MSVC 10" OFF MSVC)
 
 # APPLE specific

Re: [PATCH] unique_ptr and some clean-up

[Jean-Marc Lasgouttes]

Le 13/06/2016 à 23:15, Guillaume Munch a écrit :

I am not in charge for the machines around me and given 12.04 LTS ends up
2017-04 I don't expect any migration happening soon :)


I am in a similar situation (although as I said, clang works). My fatest 
machine runs 12.04, only updated in terms of security stuff, but not 
software. I have little visibility on what updates to expect.



So I guess the bad news is I can't quickly bisect what's going on 32
cores
anymore, the good news is I'll get more real work done :)


Thank you Pavel for your understanding. I hope the inconvenience is
temporary.


I think that not having Pavel waste his time on LyX is a loss.


So is there a consensus that g++ 4.8 is a reasonable minimum version to
support?


Could we try for a little while to cope with gcc 4.6, with explicitly 
marked code (that we can remove later) and see where this leads us?


In this case, for example, what would the cure be?

JMarc

Re: scrunched radio buttons on message pane

[Jean-Marc Lasgouttes]

Le 14/06/2016 à 10:05, Kornel Benko a écrit :

Am Dienstag, 14. Juni 2016 um 02:52:58, schrieb Scott Kostyshak 


Does anyone else see that the radio buttons are cut-off on the message
pane?

Attached is a screenshot.

Scott


I see the same. QT5.6.


Same here with Qt 4.8.1, LyX 2.2.2dev.

JMarc

Re: scrunched radio buttons on message pane

[Kornel Benko]

Am Dienstag, 14. Juni 2016 um 02:52:58, schrieb Scott Kostyshak 

> Does anyone else see that the radio buttons are cut-off on the message
> pane?
> 
> Attached is a screenshot.
> 
> Scott

I see the same. QT5.6.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: One official build system?

[Kornel Benko]

Am Montag, 13. Juni 2016 um 19:09:04, schrieb Scott Kostyshak 
> Note also that for me make package_source produces a tar.gz, not a
> tar.xz as you suggested above.

It depends on how you configure, so that 'make package' knows what to produce.
1.)  -DCPACK_SOURCE_TGZ:BOOL=ON
-> .tar.gz
2.)  -DCPACK_SOURCE_TBZ2:BOOL=ON
-> .bz2
3.) -DCPACK_SOURCE_TZ:BOOL=ON
-> .tar.Z
or
4.)  -DCPACK_SOURCE_ZIP:BOOL=ON
-> nothing on linux

(Select only one of them)
But, yes, .tar.xz is not created :(

For the differences:
'make git-archive' and 'make package_source' create different files.
Which one have you used for comparison?

Here, 'make package_source' creates
LyX-2.3.tar.gz
LyX-2.3.tar.xz
LyX-2.3.tar.Z

and 'make git-archive' creates
LyX-2.3.0-47802git-Linux.tgz

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] unique_ptr and some clean-up

[Kornel Benko]

Am Montag, 13. Juni 2016 um 22:15:02, schrieb Guillaume Munch 
> Le 13/06/2016 21:54, Pavel Sanda a écrit :
> > Guillaume Munch wrote:
> >> Starting from 2.3, LyX will require a C++11 compiler, and g++ 4.6 fails
> >> (it seems) at a feature as elementary as generating a default move
> >> constructor, even when told so explicitly (which we cannot really blame
> >> it for, given that it does not claim C++11 compliance in the first
> >> place). Moreover, the only distribution release that is currently stuck
> >> with g++ 4.6 is (to my knowledge) Ubuntu 12.04LTS, which will no longer
> >> be around by the time 2.3 ships (unless a miracle happens), and which
> >> offers another compiler more respectful of C++11. On the other hand,
> >> what reasons do we have for supporting g++ 4.6?
> >>
> >> If you really need a temporary workaround until you get to migrate your
> >> work environment, (and you do not want to/can use clang,) you could keep
> >> a local series of fixes. I imagine that for your current sort of problem
> >> (as far as I understand, because I do not have access to g++ 4.6 to test
> >> my theory), you just need manual definitions of move constructors and
> >> assignment operators. For e87febd0 in particular, however, it is easier,
> >> because it should be safe to just revert it locally, given that this is
> >> an isolated change.
> >
> > Thanks for summarizing.
> > I can confirm that reverting e87febd0 makes master compilable again with 
> > 4.6.
> >
> > I am not in charge for the machines around me and given 12.04 LTS ends up
> > 2017-04 I don't expect any migration happening soon :)
> >
> > So I guess the bad news is I can't quickly bisect what's going on 32 cores
> > anymore, the good news is I'll get more real work done :)
> >
> 
> Thank you Pavel for your understanding. I hope the inconvenience is
> temporary.
> 
> So is there a consensus that g++ 4.8 is a reasonable minimum version to
> support?
> 

I'd like Pavel be able to compile too.

Kornel

signature.asc
Description: This is a digitally signed message part.

scrunched radio buttons on message pane

[Scott Kostyshak]

Does anyone else see that the radio buttons are cut-off on the message
pane?

Attached is a screenshot.

Scott


signature.asc
Description: PGP signature

Re: LyX 2.1.5 Tarballs

[Jean-Pierre Chrétien]

Le 13/06/2016 16:33, Richard Heck a écrit :


The tarballs for the release of LyX 2.1.5 can be found here:
 ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.1/2.1.5/
Please prepare binaries.


Compilation and installation run flawlessly as usual on Debian Jessie:

Configuration
  Host type:x86_64-unknown-linux-gnu
  Special build flags:  build=release use-hunspell
  C++ Compiler: g++ (4.9.2)
  C++ Compiler LyX flags:
  C++ Compiler flags:-O2
  Linker flags:
  Linker user flags:
  Qt 4 Frontend:
  Qt 4 version: 4.8.6
  Packaging:posix
  LyX binary dir:   /usr/local/bin
  LyX files dir:/usr/local/share/lyx-2.1.5

--
Jean-Pierre

Re: LyX 2.1.5 Tarballs

[Pavel Sanda]

Richard Heck wrote:
> 
> The tarballs for the release of LyX 2.1.5 can be found here:
> ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.1/2.1.5/
> Please prepare binaries.

tested and seems to work on gentoo x86. p