Re: Questions for Uwe once you are back

2016-01-18 Thread Uwe Stöhr 
 From: Peter KümmelSent: Montag, 18. Januar 2016 03:26‎> Do you mean you have to specify the Qt pathes in the installer script?No, in CMake as I wrote. My Script works fine.Regards Uwe

Re: Beta hopefully soon, only waiting on Windows installer(s)

2016-01-18 Thread Peter Kümmel 
Am 18. Januar 2016 09:33:17 MEZ, schrieb "Uwe Stöhr" :
>
>
>  Original Message  
>From: Peter Kümmel
>Sent: Montag, 18. Januar 2016 03:49
>To: Uwe Stöhr; Scott Kostyshak; LyX Developers
>Subject: Re: Beta hopefully soon, only waiting on Windows installer(s)
>
>Am 18. Januar 2016 01:24:38 MEZ, schrieb "Uwe Stöhr"
>:
>>Am 17.01.2016 um 03:22 schrieb Peter Kümmel:
>>
>>> I would release the beta with the available Windows installer, but
>>would also mention, that because of men power this time on Windows
>>there will be nothing better that beta quality.
>>> In the announcement you could mention that we are busy improving
>>this, but that at the moment no Windows developer has the time to
>>create a reliable installer and that we are very interested in someone
>>who wanna help out.
>>
>>But what is going on here? I reported that i am ready for beta1. I
>even
>>
>>presented you an installer.
>>And to repeat myself, building the installer was never a problem, 
>>building LyX with Qt 5 was the problem.
>>
>
>But there must be no problem in building with Qt5. And if you report
>problems about cmake could not find Qt5 something is fishy on your
>system.
>
>Damn no, I did not report this. I can compile Lyx with Qt 5.5.1 with
>MSVC 2010, but not with MSVC 2012 Or newer.
>
>CMake could and can find Qt, I only need to specify some Qt paths. I
>think that specifying only one should be sufficient too.‎
>
>That your script doesn't work is another issue. As I wrote I could
>compile with the script before you changed it.
>
> > And nobody had an idea what you are doing when creating the
>installer.
>
>I wrote you an email with the instructions. Have you read it? Have you
>tried it out? I'm upset to hear such statements if people did not even
>tried it. I asked you for feedback and got no reply.

You mean the installer instructions? Yes I tried yesterday and it worked. I 
also saw your nsh changes in git. I further plan to investigate how a mingw 
build could be integrated. Also I wonder what for files from the zip packages 
are really needed and if there would be a better place than a downloadable zip 
file for them.



>
>> >Sorry, but it is an effrontery to say that no dev has the time nor
>the 
>>ability to build a reliable installer!
>
>> But it looked like you are not able to get a straightforward build, 
>
>Please read what I wrote. I did not write thus! I wrote the opposite
>and requested you to test a ready installer.
>
>> you told you have to touch 40 pathes to get a build up. Hearing this,
>the only reaction is "wtf is he doing". 
>
>Just run CMake and set Qt to Qt4. For Qt 5 there are only 6 Qt paths.
>
>>> Of course the installer for beta works fine - tested for 2 days on 5
>
>>PCs. And no, LyX on Windows is as stable as LyX on Mac and Unix.
>
>> This was to early, because until now we have no beta release. You
>have to build the installer after the beta is out.
>
>Damn, the INSTALLER. Of course I will build LYx wheb it is released.
>
>Uwe

Re: compilation problems with Qt 5.5.1 and MSVC 2010

2016-01-18 Thread Uwe Stöhr 
 From: Peter KümmelSent: Montag, 18. Januar 2016 03:18‎> Something is different on your system, there should be no problem with finding Qt 5. How actual is your cmake installation? Up to date (3.4.1). Qt is in the folder you hardcoded in the script.> Or do you use a years old Windows for the build? What do you imply with this sentence?‎ I'm on Win7 64bit.
> Latest build folder name should be build5-msvc2010, didn't land this commit upstream? It is. This folder.However, with the build script I uploaded to git I can and could compile LyX so we don't need to invest time in your script to release a beta version.
Regards Uwe

Re: compilation problems with Qt 5.5.1 and MSVC 2010

2016-01-18 Thread Peter Kümmel 
Am 18. Januar 2016 09:17:01 MEZ, schrieb "Uwe Stöhr" :
>
>
>From: Peter Kümmel
>
>Sent: Montag, 18. Januar 2016 03:18‎
>
>
>> Something is different on your system, there should be no problem
>with finding Qt 5. How actual is your cmake installation? 
>
>
>Up to date (3.4.1). Qt is in the folder you hardcoded in the script.
>
>
>> Or do you use a years old Windows for the build?
>
> What do you imply with this sentence?‎ I'm on Win7 64bit.
>
>> Latest build folder name should be build5-msvc2010, didn't land this
>commit upstream? 
>
>
>It is. This folder.
>
>
>However, with the build script I uploaded to git I can and could
>compile LyX so we don't need to invest time in your script to release a
>beta version.
>

Forget it, your script or system is broken. 

>Regards Uwe

Re: Questions for Uwe once you are back

2016-01-18 Thread Peter Kümmel 
Am 18. Januar 2016 09:20:32 MEZ, schrieb "Uwe Stöhr" :
>
>
>From: Peter Kümmel
>
>Sent: Montag, 18. Januar 2016 03:26‎
>
>
>> Do you mean you have to specify the Qt pathes in the installer
>script?
>
>
>No, in CMake as I wrote. My Script works fine.
>
>
>Regards Uwe 

Maybe there is still a Qt 4 qmake.exe in PATH.

Re: [LyX/master] UserGuide.lyx: describe the horizontal scrolling

2016-01-18 Thread Jean-Marc Lasgouttes 

Le 18/01/2016 00:25, Uwe Stöhr a écrit :

commit f1a46bac7cb459cc0283e9dca8548e8be33f2b60
Author: Uwe Stöhr 
Date:   Mon Jan 18 00:25:11 2016 +0100

 UserGuide.lyx: describe the horizontal scrolling


Thanks for that Uwe. It is a good description.

JMarc

Re: Beta hopefully soon, only waiting on Windows installer(s)

2016-01-18 Thread Uwe Stöhr 


  Original Message  
From: Peter Kümmel
Sent: Montag, 18. Januar 2016 03:49
To: Uwe Stöhr; Scott Kostyshak; LyX Developers
Subject: Re: Beta hopefully soon, only waiting on Windows installer(s)

Am 18. Januar 2016 01:24:38 MEZ, schrieb "Uwe Stöhr" :
>Am 17.01.2016 um 03:22 schrieb Peter Kümmel:
>
>> I would release the beta with the available Windows installer, but
>would also mention, that because of men power this time on Windows
>there will be nothing better that beta quality.
>> In the announcement you could mention that we are busy improving
>this, but that at the moment no Windows developer has the time to
>create a reliable installer and that we are very interested in someone
>who wanna help out.
>
>But what is going on here? I reported that i am ready for beta1. I even
>
>presented you an installer.
>And to repeat myself, building the installer was never a problem, 
>building LyX with Qt 5 was the problem.
>

But there must be no problem in building with Qt5. And if you report problems 
about cmake could not find Qt5 something is fishy on your system.

Damn no, I did not report this. I can compile Lyx with Qt 5.5.1 with MSVC 2010, 
but not with MSVC 2012 Or newer.

CMake could and can find Qt, I only need to specify some Qt paths. I think that 
specifying only one should be sufficient too.‎

That your script doesn't work is another issue. As I wrote I could compile with 
the script before you changed it.

 > And nobody had an idea what you are doing when creating the installer.

I wrote you an email with the instructions. Have you read it? Have you tried it 
out? I'm upset to hear such statements if people did not even tried it. I asked 
you for feedback and got no reply.

> >Sorry, but it is an effrontery to say that no dev has the time nor the 
>ability to build a reliable installer!

> But it looked like you are not able to get a straightforward build, 

Please read what I wrote. I did not write thus! I wrote the opposite and 
requested you to test a ready installer.

> you told you have to touch 40 pathes to get a build up. Hearing this, the 
> only reaction is "wtf is he doing". 

Just run CMake and set Qt to Qt4. For Qt 5 there are only 6 Qt paths.

>> Of course the installer for beta works fine - tested for 2 days on 5 
>PCs. And no, LyX on Windows is as stable as LyX on Mac and Unix.

> This was to early, because until now we have no beta release. You have to 
> build the installer after the beta is out.

Damn, the INSTALLER. Of course I will build LYx wheb it is released.

Uwe

Re: why Babel with dvi3 (LuTeX)?

2016-01-18 Thread Kornel Benko 
Am Montag, 18. Januar 2016 um 15:59:16, schrieb Guenter Milde 

> On 2016-01-12, Georg Baum wrote:
> > Scott Kostyshak wrote:
> 
> >> I strongly agree with Georg as for the good unit tests that we have. But
> >> for our export tests and specifically our export tests known to be
> >> unreliable, I understand Günter's objection that it could be just a lot
> >> of wasted time.
> 
> > I should clarify that a prerequisite of my recommendation is that all tests 
> > that are used in this workflow are always green and do not take ages. This 
> > does rule out all unreliable tests and all tests that depend on very up to 
> > date TeXLive or special packages. IMHO it does not rule out all export ests 
> > (especially not the dedicated ones in autotests/export/, and it would also 
> > be nice if we had a smaller subset of the export tests that run on the doc 
> > files which could be used.
> 
> >> However, as for the statement "the test suite is cleaned up in a couple
> >> of days whenever new test failures are noticed", I want to caution that
> >> in a couple of days, sometimes there are many changes that are committed
> >> and it might not be clear which commit caused a change and why. Doing a
> >> bisect and figuring out the change and then asking the author of the
> >> commit that caused the change and then waiting for that author's
> >> response and then running the tests after applying whatever patch that
> >> author implies should be made can in the end take up 5x more time than
> >> if the author had just run the tests and incorporated the changes with
> >> explanations into his commit.
> 
> > Yes, such a workflow does not work. I understood Günters comment a little 
> > bit different, namely that the author of a commit would check himself the 
> > test failures, just not before submitting the change, but sometimes a few 
> > days later.
> 
> My objection to running the complete export test suite is
> 
> * the tests are way too many and take very long
> * they require a full TeXLive installation
> * they require cmake
> 
> I agree, that it is not good to have "unaccounted" failing tests for longer.
> OTOH, mailing patches and keeping a buch of non-commited patches waiting to
> be tested by some kind soul is also taking valuable time...
> 
> As a short measure, everyone running the tests and realizing an error
> could/should add it to "suspiciousTests" as "todo" with a comment like
> "fails at commit ". This would help to narrow the possible breaking
> commits.

Correct me if I am wrong. Rephrasing the sentence:
Everyone realizing an error is supposed to change the test. The error vanishes.

> Alternatively, we could have an "untested" branch for commits that should go
> in after a test run...
> 
> 
> 
> Could you life with the the current description of "expectations of LyX
> developers" (sec 3.3.1.1 in Develomplent.lyx):
> 
>   When making non-trivial changes to LyX's LaTeX export code (e.g. touching
>   the encoding code or package handling code that you expect will change
>   the exported LaTeX in some way):
>   
>   Consider running all of the export tests before and after your change. If
>   there are differences, please reconcile these (i.e. fix the bug or fix
>   the tests) before committing. Ask for help if you're not sure what to.
>   
>   If you do not want to run the tests,
>   
>   * post the patch on the list and others will run the tests and eventually
> ask for fixes, or
>   
>   * commit, but be prepared to fix eventually arising problems or to revert
> the commit if there is no easy fix.
> 

That's better.

> 
> Günter
> 

Kornel

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

Re: why Babel with dvi3 (LuTeX)?

2016-01-18 Thread Scott Kostyshak 
On Mon, Jan 18, 2016 at 03:59:16PM +, Guenter Milde wrote:

> My objection to running the complete export test suite is
> 
> * the tests are way too many and take very long

I agree with this one. But if you view it in a different way, then
really the tests take 20 seconds to run---Just start them before you go
to bed. That's it.

> * they require a full TeXLive installation

I had no idea that it was not common for LyX developers to have a full
TeX Live installation. If that is indeed the case, then I also agree
with this.

> * they require cmake

I do not agree with this. It is easy to have a separate CMake build
directory. Ah, perhaps you mean literally that they require CMake,
meaning that a system has to have CMake installed and that such a
dependency is significant?

> I agree, that it is not good to have "unaccounted" failing tests for longer.
> OTOH, mailing patches and keeping a buch of non-commited patches waiting to
> be tested by some kind soul is also taking valuable time...

Indeed.

> As a short measure, everyone running the tests and realizing an error
> could/should add it to "suspiciousTests" as "todo" with a comment like
> "fails at commit ". This would help to narrow the possible breaking
> commits.

Yes this could be helpful.

> Alternatively, we could have an "untested" branch for commits that should go
> in after a test run...

I would like this. But I'm not sure all LyX developers feel comfortable
with git branches or with learning about git branches.

> Could you life with the the current description of "expectations of LyX
> developers" (sec 3.3.1.1 in Develomplent.lyx):

I can live with the below for most cases. For trivial changes, no need
to run the tests. For non-trivial but small or medium changes, then the
below is fine. However, for significant changes where one thinks there
is a good chance that many (non-suspicious) tests will be broken, then I
think the committer should be required to either run the tests or to
post and wait until someone else runs the tests. I only expect this to
happen for a few commits every release cycle. For example, changing from
babel to polyglossia. Looking backward, it was expected that many tests
could break. Another example is the reporting missing characters commit.
I don't think there are many other commits that fall in this category of
"I think there is a large probability that many tests will fail".

>   When making non-trivial changes to LyX's LaTeX export code (e.g. touching
>   the encoding code or package handling code that you expect will change
>   the exported LaTeX in some way):
>   
>   Consider running all of the export tests before and after your change. If
>   there are differences, please reconcile these (i.e. fix the bug or fix
>   the tests) before committing. Ask for help if you're not sure what to.
>   
>   If you do not want to run the tests,
>   
>   * post the patch on the list and others will run the tests and eventually
> ask for fixes, or
>   
>   * commit, but be prepared to fix eventually arising problems or to revert
> the commit if there is no easy fix.

In the end, my concern is that the author of a commit should be
responsible for fixing things. Currently how it is set up, Günter and
Kornel have been doing most of the work on the tests. It would be nice
to arrive at an equilibrium where those who break things that are viewed
as important to LyX developers as a whole, fix them (and fix them
quickly or revert what broke them). I'm not convinced that most
developers think these export tests are that important. If that is
indeed the case, then I'm not sure we should encourage anyone to run the
tests. In any case, your and Kornel's work have gone a far way I hope
for LyX developers believing that at least a *subset* of the export test
are important enough to have some sort of policy.

Scott


signature.asc
Description: PGP signature

Re: why Babel with dvi3 (LuTeX)?

2016-01-18 Thread Guenter Milde 
On 2016-01-12, Georg Baum wrote:
> Scott Kostyshak wrote:

>> I strongly agree with Georg as for the good unit tests that we have. But
>> for our export tests and specifically our export tests known to be
>> unreliable, I understand Günter's objection that it could be just a lot
>> of wasted time.

> I should clarify that a prerequisite of my recommendation is that all tests 
> that are used in this workflow are always green and do not take ages. This 
> does rule out all unreliable tests and all tests that depend on very up to 
> date TeXLive or special packages. IMHO it does not rule out all export ests 
> (especially not the dedicated ones in autotests/export/, and it would also 
> be nice if we had a smaller subset of the export tests that run on the doc 
> files which could be used.

>> However, as for the statement "the test suite is cleaned up in a couple
>> of days whenever new test failures are noticed", I want to caution that
>> in a couple of days, sometimes there are many changes that are committed
>> and it might not be clear which commit caused a change and why. Doing a
>> bisect and figuring out the change and then asking the author of the
>> commit that caused the change and then waiting for that author's
>> response and then running the tests after applying whatever patch that
>> author implies should be made can in the end take up 5x more time than
>> if the author had just run the tests and incorporated the changes with
>> explanations into his commit.

> Yes, such a workflow does not work. I understood Günters comment a little 
> bit different, namely that the author of a commit would check himself the 
> test failures, just not before submitting the change, but sometimes a few 
> days later.

My objection to running the complete export test suite is

* the tests are way too many and take very long
* they require a full TeXLive installation
* they require cmake

I agree, that it is not good to have "unaccounted" failing tests for longer.
OTOH, mailing patches and keeping a buch of non-commited patches waiting to
be tested by some kind soul is also taking valuable time...

As a short measure, everyone running the tests and realizing an error
could/should add it to "suspiciousTests" as "todo" with a comment like
"fails at commit ". This would help to narrow the possible breaking
commits.

Alternatively, we could have an "untested" branch for commits that should go
in after a test run...



Could you life with the the current description of "expectations of LyX
developers" (sec 3.3.1.1 in Develomplent.lyx):

  When making non-trivial changes to LyX's LaTeX export code (e.g. touching
  the encoding code or package handling code that you expect will change
  the exported LaTeX in some way):
  
  Consider running all of the export tests before and after your change. If
  there are differences, please reconcile these (i.e. fix the bug or fix
  the tests) before committing. Ask for help if you're not sure what to.
  
  If you do not want to run the tests,
  
  * post the patch on the list and others will run the tests and eventually
ask for fixes, or
  
  * commit, but be prepared to fix eventually arising problems or to revert
the commit if there is no easy fix.



Günter

Re: "Splitting of consecutive environments has been reworked and enhanced"

2016-01-18 Thread Enrico Forestieri 
On Tue, Jan 12, 2016 at 08:00:18PM -0500, Richard Heck wrote:
> On 01/12/2016 06:53 PM, Enrico Forestieri wrote:
> > What about a symbol like the attached one? It resembles a pilcrow with a
> > left pointing arrow.
> 
> That looks good to me, and of course we don't want to rely upon color,
> especially red.

The attached patch implements this symbol.

I tried using GuiPainter::arc but did not succeed in convincing Qt
to draw the arc such that its ends were fitting the horizontal strokes.
As a consequence, the symbol was looking really ugly. So, I implemented
GuiPainter::path to draw paths with bezier curves and now the symbol
looks nice.

-- 
Enrico
diff --git a/src/frontends/Painter.h b/src/frontends/Painter.h
index d077a1f..c72d813 100644
--- a/src/frontends/Painter.h
+++ b/src/frontends/Painter.h
@@ -95,6 +95,23 @@ public:
fill_style = fill_none, line_style = line_solid,
int line_width = thin_line) = 0;
 
+   /**
+* path -  draw a path with bezier curves
+* @param xp array of points' x co-ords
+* @param yp array of points' y co-ords
+* @param c1x array of first control points' x co-ords
+* @param c1y array of first control points' y co-ords
+* @param c2x array of second control points' x co-ords
+* @param c2y array of second control points' y co-ords
+* @param np size of the points array
+*/
+   virtual void path(int const * xp, int const * yp,
+   int const * c1x, int const * c1y,
+   int const * c2x, int const * c2y,
+   int np, Color,
+   fill_style = fill_none, line_style = line_solid,
+   int line_width = thin_line) = 0;
+
/// draw a rectangle
virtual void rectangle(int x, int y, int w, int h, Color,
line_style = line_solid, int line_width = thin_line) = 0;
diff --git a/src/frontends/qt4/GuiPainter.cpp b/src/frontends/qt4/GuiPainter.cpp
index 2b024d8..9407825 100644
--- a/src/frontends/qt4/GuiPainter.cpp
+++ b/src/frontends/qt4/GuiPainter.cpp
@@ -229,6 +229,40 @@ void GuiPainter::lines(int const * xp, int const * yp, int 
np,
 }
 
 
+void GuiPainter::path(int const * xp, int const * yp,
+   int const * c1x, int const * c1y,
+   int const * c2x, int const * c2y,
+   int np,
+   Color col,
+   fill_style fs,
+   line_style ls,
+   int lw)
+{
+   if (!isDrawingEnabled())
+   return;
+
+   QPainterPath bpath;
+   bpath.moveTo(xp[0], yp[0]);
+
+   for (int i = 1; i < np; ++i) {
+   bool line = c1x[i] == xp[i - 1] && c1y[i] == yp[i - 1] &&
+   c2x[i] == xp[i] && c2y[i] == yp[i];
+   if (line)
+   bpath.lineTo(xp[i], yp[i]);
+   else
+   bpath.cubicTo(c1x[i], c1y[i],  c2x[i], c2y[i], xp[i], 
yp[i]);
+   }
+   QColor const color = computeColor(col);
+   setQPainterPen(color, ls, lw);
+   bool const text_is_antialiased = renderHints() & TextAntialiasing;
+   setRenderHint(Antialiasing, text_is_antialiased);
+   drawPath(bpath);
+   if (fs != fill_none)
+   fillPath(bpath, QBrush(color));
+   setRenderHint(Antialiasing, false);
+}
+
+
 void GuiPainter::rectangle(int x, int y, int w, int h,
Color col,
line_style ls,
diff --git a/src/frontends/qt4/GuiPainter.h b/src/frontends/qt4/GuiPainter.h
index eadf985..3819ff3 100644
--- a/src/frontends/qt4/GuiPainter.h
+++ b/src/frontends/qt4/GuiPainter.h
@@ -18,6 +18,7 @@
 #include "frontends/Painter.h"
 
 #include 
+#include 
 #include 
 
 class QString;
@@ -59,6 +60,23 @@ public:
line_style ls = line_solid,
int lw = thin_line);
 
+   /**
+* path -  draw a path with bezier curves
+* @param xp array of points' x co-ords
+* @param yp array of points' y co-ords
+* @param c1x array of first control points' x co-ords
+* @param c1y array of first control points' y co-ords
+* @param c2x array of second control points' x co-ords
+* @param c2y array of second control points' y co-ords
+* @param np size of the points array
+*/
+   virtual void path(int const * xp, int const * yp,
+   int const * c1x, int const * c1y,
+   int const * c2x, int const * c2y,
+   int np, Color,
+   fill_style = fill_none, line_style = line_solid,
+   int line_width = thin_line);
+
/// draw a rectangle
virtual void rectangle(
int x, int y,
diff --git a/src/insets/InsetSeparator.cpp b/src/insets/InsetSeparator.cpp
index 7fb7c64..4d70a1b 100644
--- a/src/insets/InsetSeparator.cpp
+++ b/src/insets/InsetSeparator.cpp
@@ -176,9 +176,9 @@ void InsetSeparator::metrics(MetricsInfo & mi, Dimension & 
dim) const
frontend::FontMetrics const & fm = theFontMetrics(mi.base.font);

Re: Questions for Uwe once you are back

2016-01-18 Thread Uwe Stöhr 

Am 18.01.2016 um 10:18 schrieb Peter Kümmel:


Maybe there is still a Qt 4 qmake.exe in PATH.


No, the solution are path changes:

- Qt is installed here in
  C:\Qt\Qt5-5-1-2010\5.5\msvc2010\bin
  not in
  C:\Qt\Qt5.5.1-2010\5.5\msvc2010\bin
  (don't know why, I could change that if you prefer)

- set LYX_BUILD=%LYX_SOURCE%\build-result-5-2010
  instead of
  set LYX_BUILD=%LYX_SOURCE%\..\build-result-5-2010
  (this quit the build operations because the folder could not be created)

- set GNUWIN32_DIR=%LYX_SOURCE%\lyx-windows-deps-msvc2010
  instead of
  set GNUWIN32_DIR=%LYX_SOURCE%\..\lyx-windows-deps-msvc2010
  (same issue as above)

- I also added
  RMDIR /S /Q %LYX_SOURCE%\build-result-5-2010
  to assure a clean rebuild. Otherwise files that were removed or
  renamed in Git or for a new LyX release could still be in the 
LYX_INSTALLED folder.


With these changes your script works for me. Also the merged build works.

To avoid confusions and to re-enable myself to build devel versions of 
LyX 2.2 I restored my script in Git and upload your version with my 
changes as

"build5-2010-installer"
to clarify that this is the one-click file to build LyX for an installer.

I removed the now 2 unused build scripts.

I hope that this is fine for you. Feel free to change something in the 
one-click script and I will change my paths accordingly.


regards Uwe

Re: [LyX/master] UserGuide.lyx: describe the horizontal scrolling

2016-01-18 Thread Uwe Stöhr 

Am 18.01.2016 um 10:39 schrieb Jean-Marc Lasgouttes:


 UserGuide.lyx: describe the horizontal scrolling


Thanks for that Uwe. It is a good description.


Thanks for the thanks. it was indeed not easy to find a good description.

regards Uwe

what are the new DVI-PS Options in LyX preferences for?

2016-01-18 Thread Uwe Stöhr 
While updating the UserGuide I noticed a new preferences setting under 
Outputs->General


"DVI-PS Options"

What feature of LyX is using this and where can I find a list of 
possible options?


This new feature should be added to
http://wiki.lyx.org/LyX/NewInLyX22
if possible.

thanks and regards
Uwe

Re: Beta hopefully soon, only waiting on Windows installer(s)

2016-01-18 Thread Uwe Stöhr 
To summarize:

After a very tiring trip abroad I invested almost all spare time‎ and hours of 
sleep to get ready for beta1. Although I don't know much about CMake and 
compilers I was able to overcome all corner cases. I reported the CMake bugs I 
found. I am able to build LyX with Qt 5.5.1 and MSVC 2010. I was also able to 
build an installer for LyX 2.2 with Qt 5. I tested everything a lot and proudly 
reported when I was ready. I also presented a working installer that was tested 
on several PCs.
Georg explained me why I should change the way I compile and I will do so in 
future as I stated.

And you thank this to me by opening a thread that beta is delayed because of me 
-- one day after I reported I am ready. Then it is even proposed‎ to state in 
the release announcement that LyX has no developer to build on Windows and to 
create an installer. That hurts!

Sorry for the rant, but now I feel better.

Regards Uwe

‎P.s. Peter, ‎
could you please only cite what you you really cite in your mails? It is hard 
to find your statements in all this text‎‎.

What does new module paralist do?

2016-01-18 Thread Uwe Stöhr 

Hi Georg,

you added a new module "paralist". What is this for? Do you have a 
documentation how to use this module? I would like to have at least a 
small example files in our examples folder. This assures that the module 
will be usable in future (e.g. at least before a new release all 
examples files are compiled and possible regressions will this way 
become visible).

If you like, we can also link it to the special files in the Help menu.

If you don't have a documentation or no time, please give me a pointer 
to create this.


thanks and regards
Uwe

Re: "Splitting of consecutive environments has been reworked and enhanced"

2016-01-18 Thread Guillaume Munch 

Le 18/01/2016 19:19, Enrico Forestieri a écrit :

On Tue, Jan 12, 2016 at 08:00:18PM -0500, Richard Heck wrote:

On 01/12/2016 06:53 PM, Enrico Forestieri wrote:

What about a symbol like the attached one? It resembles a pilcrow with a
left pointing arrow.


That looks good to me, and of course we don't want to rely upon color,
especially red.


The attached patch implements this symbol.

I tried using GuiPainter::arc but did not succeed in convincing Qt
to draw the arc such that its ends were fitting the horizontal strokes.
As a consequence, the symbol was looking really ugly. So, I implemented
GuiPainter::path to draw paths with bezier curves and now the symbol
looks nice.




For anybody curious, here is how it looks like.

Enrico: the width of the line of the plain separator changed, as you can 
see, which I guess was not intended.

Re: Beta hopefully soon, only waiting on Windows installer(s)

2016-01-18 Thread Scott Kostyshak 
On Tue, Jan 19, 2016 at 01:10:22AM +0100, Uwe Stöhr wrote:
> To summarize:
> 
> After a very tiring trip abroad I invested almost all spare time‎ and hours 
> of sleep to get ready for beta1.

Please, do not sacrifice hours of sleep. No one here wants you to do
this. We want LyX development to be fun for you and if it is not, then
we have to find a way to make it fun for you again. It seems that LyX
development is so stressful for you that it really affects your life in
a negative way. We do not want this and it's not good for anyone.

> Although I don't know much about CMake and compilers I was able to overcome 
> all corner cases. I reported the CMake bugs I found. I am able to build LyX 
> with Qt 5.5.1 and MSVC 2010. I was also able to build an installer for LyX 
> 2.2 with Qt 5. I tested everything a lot and proudly reported when I was 
> ready. I also presented a working installer that was tested on several PCs.
> Georg explained me why I should change the way I compile and I will do so in 
> future as I stated.

Great, thanks for doing that.

> And you thank this to me by opening a thread that beta is delayed because of 
> me -- one day after I reported I am ready.

This was not my intention. I just meant that the Windows installer was
the only thing left before beta. That is all I wanted to say. Nothing
more. Perhaps this is a language issue. I think I see what you mean that
"waiting" could mean that I am sitting around impatiently wondering
where the Windows installer is. There is another usage of the word that
simply means it's the only thing left.

In the end, there were a couple of issues that we hope to fix before
beta is released so my subject line was not even accurate.

> Then it is even proposed‎ to state in the release announcement that LyX has 
> no developer to build on Windows and to create an installer. That hurts!

I thought this is what you wanted. I thought you wanted help with
development of a Windows installer or for someone to replace you so that
LyX development would not be so stressful.

> Sorry for the rant, but now I feel better.

Yes I always think it is best to get everything out.

Scott


signature.asc
Description: PGP signature

Re: Test results for 2.2.0dev on Mac

2016-01-18 Thread Scott Kostyshak 
On Mon, Jan 18, 2016 at 09:53:26PM +0100, Stephan Witt wrote:
> Am 18.01.2016 um 21:48 schrieb Kornel Benko :
> > 
> > Am Montag, 18. Januar 2016 um 15:26:06, schrieb Scott Kostyshak 
> > 
> >> On Mon, Jan 18, 2016 at 09:23:47PM +0100, Stephan Witt wrote:
> >>> Running ctest there are 16 failed tests in tex2lyx. 
> >>> Is this to be expected? 
> >> 
> >> I don't think so. All of the tex2lyx tests pass for me.
> > 
> > Here too.
> > 
> >>> Where are the details to analyze it further?
> >> 
> >> In the CMake build directory, look at
> >> 
> >> Testing/Temporary/LastTest.log
> > 
> > To compare with my results, please try (in the build directory)
> > # ctest -R tex2lyx
> > too.
> 
> Ok, I did it. Here you are.

Interesting, I just looked at once test. My entry in the log for it is below. I
think the main difference is that I have the output "Ignoring options 'boxed'
of package algorithm2e."

8/4947 Testing: tex2lyx/roundtrip/algo2e.tex
8/4947 Test: tex2lyx/roundtrip/algo2e.tex
Command: "/usr/bin/cmake" 
"-DLYX_TESTS_USERDIR=/home/scott/lyxbuilds/master/CMakeBuild/Testing/.lyx" 
"-DLYX_USERDIR_VER=LYX_USERDIR_22x" 
"-DLYX_PYTHON_EXECUTABLE=/usr/bin/python2.7" 
"-DPY_SCRIPT=/home/scott/lyxbuilds/master/repo/src/tex2lyx/test/runtests.py" 
"-DTEX2LYX_EXE=/home/scott/lyxbuilds/master/CMakeBuild/bin/tex2lyx2.2" 
"-DSCRIPT_DIR=/home/scott/lyxbuilds/master/repo/lib/scripts" 
"-DWORKDIR=/home/scott/lyxbuilds/master/CMakeBuild/src/tex2lyx/test" 
"-DTESTFILE=algo2e.tex" "-P" 
"/home/scott/lyxbuilds/master/repo/src/tex2lyx/test/runtests.cmake"
Directory: /home/scott/lyxbuilds/master/CMakeBuild/src/tex2lyx/test
"tex2lyx/roundtrip/algo2e.tex" start time: Jan 18 15:24 EST
Output:
--
-- SCRIPT_DIR = /home/scott/lyxbuilds/master/repo/lib/scripts
-- Executing: /home/scott/lyxbuilds/master/CMakeBuild/bin/tex2lyx2.2 -roundtrip 
-copyfiles -f /home/scott/lyxbuilds/master/repo/src/tex2lyx/test/algo2e.tex 
/home/scott/lyxbuilds/master/CMakeBuild/src/tex2lyx/test/algo2e.lyx

Creating file 
/home/scott/lyxbuilds/master/CMakeBuild/src/tex2lyx/test/algo2e.lyx
Ignoring options 'boxed' of package algorithm2e.


-- Error output of 
/home/scott/lyxbuilds/master/repo/src/tex2lyx/test/runtests.py = 0

Test time =   0.39 sec
--
Test Passed.
"tex2lyx/roundtrip/algo2e.tex" end time: Jan 18 15:25 EST
"tex2lyx/roundtrip/algo2e.tex" time elapsed: 00:00:00

Scott


signature.asc
Description: PGP signature

Re: [patch] - GIT - version control for LyX documents not detected

2016-01-18 Thread Peter Kümmel 
Am 18. Januar 2016 23:25:03 MEZ, schrieb Pavel Sanda :
>Stephan Witt wrote:
>> The attached patch fixes the broken detection of GIT version control.
>> It seems so that Qt is caching the file meta data and fools the test
>> of file emptiness. Perhaps this has changed with Qt5 and didn???t
>happen
>> with Qt4???
>
>Bad news, if your analysis is correct, we might encounter the same
>problem
>in other parts of the code as well. I don't have easy access to qt5 to
>test.
>
>Quick check says we use is FileEmpty also in:
>Buffer.cpp:   enable = (d->preview_file_).exists() &&
>!(d->preview_file_).isFileEmpty();
>LaTeX.cpp:rerun = idxfile.exists() && idxfile.isFileEmpty();
>LaTeX.cpp:if (head.haschanged(nlofile) || (nlofile.exists() &&
>nlofile.isFileEmpty()))
>
>Pavel

I did not follow this git stuff, but I assume current implementation tries to 
use system git calls via Qt classes, am I right? I really could imagine this 
makes problems, because of Qt. 

Afaik QtCreator tries the same, is any code used from there in LyX?

Had someone the idea to use libgit2 instead of the system git? Was it 
evaluated? I assume then there we have much more control over the git files.

Peter

Re: Test results for 2.2.0dev on Mac

2016-01-18 Thread Stephan Witt 
Am 19.01.2016 um 05:13 schrieb Scott Kostyshak :
> 
> On Mon, Jan 18, 2016 at 09:53:26PM +0100, Stephan Witt wrote:
>> Am 18.01.2016 um 21:48 schrieb Kornel Benko :
>>> 
>>> Am Montag, 18. Januar 2016 um 15:26:06, schrieb Scott Kostyshak 
>>> 
 On Mon, Jan 18, 2016 at 09:23:47PM +0100, Stephan Witt wrote:
> Running ctest there are 16 failed tests in tex2lyx. 
> Is this to be expected? 
 
 I don't think so. All of the tex2lyx tests pass for me.
>>> 
>>> Here too.
>>> 
> Where are the details to analyze it further?
 
 In the CMake build directory, look at
 
 Testing/Temporary/LastTest.log
>>> 
>>> To compare with my results, please try (in the build directory)
>>> # ctest -R tex2lyx
>>> too.
>> 
>> Ok, I did it. Here you are.
> 
> Interesting, I just looked at once test. My entry in the log for it is below. 
> I
> think the main difference is that I have the output "Ignoring options 'boxed'
> of package algorithm2e."
> 
> 8/4947 Testing: tex2lyx/roundtrip/algo2e.tex
> 8/4947 Test: tex2lyx/roundtrip/algo2e.tex
> Command: "/usr/bin/cmake" 
> "-DLYX_TESTS_USERDIR=/home/scott/lyxbuilds/master/CMakeBuild/Testing/.lyx" 
> "-DLYX_USERDIR_VER=LYX_USERDIR_22x" 
> "-DLYX_PYTHON_EXECUTABLE=/usr/bin/python2.7" 
> "-DPY_SCRIPT=/home/scott/lyxbuilds/master/repo/src/tex2lyx/test/runtests.py" 
> "-DTEX2LYX_EXE=/home/scott/lyxbuilds/master/CMakeBuild/bin/tex2lyx2.2" 
> "-DSCRIPT_DIR=/home/scott/lyxbuilds/master/repo/lib/scripts" 
> "-DWORKDIR=/home/scott/lyxbuilds/master/CMakeBuild/src/tex2lyx/test" 
> "-DTESTFILE=algo2e.tex" "-P" 
> "/home/scott/lyxbuilds/master/repo/src/tex2lyx/test/runtests.cmake"
> Directory: /home/scott/lyxbuilds/master/CMakeBuild/src/tex2lyx/test
> "tex2lyx/roundtrip/algo2e.tex" start time: Jan 18 15:24 EST
> Output:
> --
> -- SCRIPT_DIR = /home/scott/lyxbuilds/master/repo/lib/scripts
> -- Executing: /home/scott/lyxbuilds/master/CMakeBuild/bin/tex2lyx2.2 
> -roundtrip -copyfiles -f 
> /home/scott/lyxbuilds/master/repo/src/tex2lyx/test/algo2e.tex 
> /home/scott/lyxbuilds/master/CMakeBuild/src/tex2lyx/test/algo2e.lyx
> 
> Creating file 
> /home/scott/lyxbuilds/master/CMakeBuild/src/tex2lyx/test/algo2e.lyx
> Ignoring options 'boxed' of package algorithm2e.
> 
> 
> -- Error output of 
> /home/scott/lyxbuilds/master/repo/src/tex2lyx/test/runtests.py = 0
> 
> Test time =   0.39 sec
> --
> Test Passed.
> "tex2lyx/roundtrip/algo2e.tex" end time: Jan 18 15:25 EST
> "tex2lyx/roundtrip/algo2e.tex" time elapsed: 00:00:00

I have this:

$ cat 
/Users/stephan/git/lyx-build/cmake/2.2.0dev/Testing/.lyx/layouts/testalgorithm2e.layout
 
#% Do not delete the line below; configure depends on this
#  \DeclareLaTeXClass{testalgorithm2e}
Format 55
Input algorithm2e.module

Do you have the same in /home/scott/lyxbuilds/master/CMakeBuild/Testing/.lyx?

BTW, when debugging tex2lyx it complains about missing USERDIR and I have to add
-userdir /Users/stephan/git/lyx-build/cmake/2.2.0dev/Testing/.lyx explicitly.
Is it passed via environment in ctest runs? Or is it simply not printed?
Shouldn't these options passed via command line when calling tex2lyx?

Other possible differences except the OS? :)
- version or availability of algorithm2e.sty?
- remnants of previous runs somewhere?
- mismatch of config files somewhere?

Stephan

Re: [patch] - GIT - version control for LyX documents not detected

2016-01-18 Thread Stephan Witt 
Am 19.01.2016 um 07:56 schrieb Peter Kümmel :
> 
> Am 18. Januar 2016 23:25:03 MEZ, schrieb Pavel Sanda :
> Stephan Witt wrote:
>  The attached patch fixes the broken detection of GIT version control.
>  It seems so that Qt is caching the file meta data and fools the test
>  of file emptiness. Perhaps this has changed with Qt5 and didn???t happen
>  with Qt4???
> 
> Bad news, if your analysis is correct, we might encounter the same problem
> in other parts of the code as well. I don't have easy access to qt5 to test.
> 
> Quick check says we use is FileEmpty also in:
> Buffer.cpp:   enable = (d->preview_file_).exists() && 
> !(d->preview_file_).isFileEmpty();
> LaTeX.cpp:rerun = idxfile.exists() && idxfile.isFileEmpty();
> LaTeX.cpp:if (head.haschanged(nlofile) || (nlofile.exists() && 
> nlofile.isFileEmpty()))
> 
> Pavel
> 
> I did not follow this git stuff, but I assume current implementation tries to 
> use system git calls via Qt classes, am I right?

No. It is hand crafted stuff. The problem is the temporary file to collect the 
output of system calls.
After creation it’s empty - of course. The system call changes this and the 
next call to QFileInfo::size() returns 0 on my system.
This I couldn’t debug further because of... I don’t know. In the past I’ve been 
able to step into the Qt code. 
After doing an upgrade of my OS and of the development system I have to get it 
working again :(
 
Stephan

> I really could imagine this makes problems, because of Qt. 
> 
> Afaik QtCreator tries the same, is any code used from there in LyX?
> 
> Had someone the idea to use libgit2 instead of the system git? Was it 
> evaluated?

No, this would add another external library to the list of dependencies…

Re: #9794: inset-modify tabular commands are incorrectly disabled

2016-01-18 Thread Pavel Sanda 
Scott Kostyshak wrote:
> > Scott, you might want to look over changes in LFUNs API in LyXAction.cpp
> > during 2.2dev cycle if we meant this conversion seriously.
> 
> Which conversion? I don't understand. What specifically should I look
> at?

I would say check git log -p LyXAction.cpp during 2.2 cycle, if there
are some changes which would screw up functionality of e.g. user bind files.

It also used to be good habit to hint any changes in LFUNs in RELEASE_NOTES
(adding/removing/changing semantics, this check would tell you whether the
list is up to date.)


> > That said I think bunch of LFUN changes is not easy or possible to convert
> > at all.
> 
> Do you mean that if we have changes to LFUNs then we might consider
> converting e.g. a bind file to approximate the behavior before the LFUN
> change? If I understood correctly (which I doubt), I'm not sure we
> should do that.

I think it is reasonably easy to make rename conversions (i.e. the lfun is
exactly the same, only the name changed), I wouldn't push it to the extent that
we have to preserve changes in syntax (e.g. number of parameters and similar).

In any way I am not pushing this forward; it's just that the only reason
why to keep LFUN format number is to have these kind of conversions working.
If we don't want to do those conversions we can drop the whole effort of
keeping LFUN_FORMAT in the code.

Pavel

Re: fontforge files in source package?

2016-01-18 Thread Pavel Sanda 
Georg Baum wrote:
> the existing one. I suggest to remove the existing one, since the .sfd files 
> are not used in our build and only needed in very rare cases, and they are 
> not small files.

+1
P

Re: [patch] - GIT - version control for LyX documents not detected

2016-01-18 Thread Pavel Sanda 
Stephan Witt wrote:
> The attached patch fixes the broken detection of GIT version control.
> It seems so that Qt is caching the file meta data and fools the test
> of file emptiness. Perhaps this has changed with Qt5 and didn???t happen
> with Qt4???

Bad news, if your analysis is correct, we might encounter the same problem
in other parts of the code as well. I don't have easy access to qt5 to test.

Quick check says we use is FileEmpty also in:
Buffer.cpp:   enable = (d->preview_file_).exists() && 
!(d->preview_file_).isFileEmpty();
LaTeX.cpp:rerun = idxfile.exists() && idxfile.isFileEmpty();
LaTeX.cpp:if (head.haschanged(nlofile) || (nlofile.exists() && 
nlofile.isFileEmpty()))

Pavel

Re: #9794: inset-modify tabular commands are incorrectly disabled

2016-01-18 Thread Scott Kostyshak 
On Mon, Jan 18, 2016 at 01:45:58PM -0800, Pavel Sanda wrote:
> Scott Kostyshak wrote:
> > > Scott, you might want to look over changes in LFUNs API in LyXAction.cpp
> > > during 2.2dev cycle if we meant this conversion seriously.
> > 
> > Which conversion? I don't understand. What specifically should I look
> > at?
> 
> I would say check git log -p LyXAction.cpp during 2.2 cycle, if there
> are some changes which would screw up functionality of e.g. user bind files.
> 
> It also used to be good habit to hint any changes in LFUNs in RELEASE_NOTES
> (adding/removing/changing semantics, this check would tell you whether the
> list is up to date.)

Ah yes this is a good idea. We do still document changes in LFUNs. I
like the idea of looking at git log -p LyXAction.cpp.

> > > That said I think bunch of LFUN changes is not easy or possible to convert
> > > at all.
> > 
> > Do you mean that if we have changes to LFUNs then we might consider
> > converting e.g. a bind file to approximate the behavior before the LFUN
> > change? If I understood correctly (which I doubt), I'm not sure we
> > should do that.
> 
> I think it is reasonably easy to make rename conversions (i.e. the lfun is
> exactly the same, only the name changed), I wouldn't push it to the extent 
> that
> we have to preserve changes in syntax (e.g. number of parameters and similar).
> 
> In any way I am not pushing this forward; it's just that the only reason
> why to keep LFUN format number is to have these kind of conversions working.
> If we don't want to do those conversions we can drop the whole effort of
> keeping LFUN_FORMAT in the code.

Indeed, good point. I definitely agree with the rename conversions.

Scott


signature.asc
Description: PGP signature

Re: Test results for 2.2.0dev on Mac

2016-01-18 Thread Stephan Witt 
Am 18.01.2016 um 21:48 schrieb Kornel Benko :
> 
> Am Montag, 18. Januar 2016 um 15:26:06, schrieb Scott Kostyshak 
> 
>> On Mon, Jan 18, 2016 at 09:23:47PM +0100, Stephan Witt wrote:
>>> Running ctest there are 16 failed tests in tex2lyx. 
>>> Is this to be expected? 
>> 
>> I don't think so. All of the tex2lyx tests pass for me.
> 
> Here too.
> 
>>> Where are the details to analyze it further?
>> 
>> In the CMake build directory, look at
>> 
>> Testing/Temporary/LastTest.log
> 
> To compare with my results, please try (in the build directory)
>   # ctest -R tex2lyx
> too.

Ok, I did it. Here you are.

Stephan



LastTest.log
Description: Binary data


LastTestsFailed.log
Description: Binary data

Re: [patch] - GIT - version control for LyX documents not detected

2016-01-18 Thread Pavel Sanda 
Richard Heck wrote:
> And, as I think is said there, we've seen issues with this, when using 
> filesystems with
> significant latency, e.g., over NFS. It'd be worth adding a comment to 
> isFileEmpty() so
> this question doesn't keep arising.

Committed. P

Re: Test results for 2.2.0dev on Mac

2016-01-18 Thread Scott Kostyshak 
On Mon, Jan 18, 2016 at 09:23:47PM +0100, Stephan Witt wrote:
> Running ctest there are 16 failed tests in tex2lyx. 
> Is this to be expected? 

I don't think so. All of the tex2lyx tests pass for me.

> Where are the details to analyze it further?

In the CMake build directory, look at

Testing/Temporary/LastTest.log

Scott


signature.asc
Description: PGP signature

Test results for 2.2.0dev on Mac

2016-01-18 Thread Stephan Witt 
Running ctest there are 16 failed tests in tex2lyx. 
Is this to be expected? 
Where are the details to analyze it further?

Stephan



$ (cd lyx-build/cmake/2.2.0dev;ctest -C debug )
...
92% tests passed, 16 tests failed out of 202

Label Time Summary:
cmplyx   =  21.99 sec (14 tests)
layout   =   5.35 sec (114 tests)
lyx2lyx  =   0.06 sec (1 test)
module   =   4.68 sec (51 tests)
roundtrip=  13.03 sec (14 tests)

Total Test time (real) =  45.54 sec

The following tests FAILED:
  8 - tex2lyx/roundtrip/algo2e.tex (Failed)
  9 - tex2lyx/cmplyx/algo2e.tex (Failed)
 12 - tex2lyx/roundtrip/CJK.tex (Failed)
 13 - tex2lyx/cmplyx/CJK.tex (Failed)
 14 - tex2lyx/roundtrip/CJKutf8.tex (Failed)
 15 - tex2lyx/cmplyx/CJKutf8.tex (Failed)
 16 - tex2lyx/roundtrip/test-insets-basic.tex (Failed)
 17 - tex2lyx/cmplyx/test-insets-basic.tex (Failed)
 18 - tex2lyx/roundtrip/test-insets.tex (Failed)
 19 - tex2lyx/cmplyx/test-insets.tex (Failed)
 20 - tex2lyx/roundtrip/test-memoir.tex (Failed)
 21 - tex2lyx/cmplyx/test-memoir.tex (Failed)
 24 - tex2lyx/roundtrip/test-refstyle-theorems.tex (Failed)
 25 - tex2lyx/cmplyx/test-refstyle-theorems.tex (Failed)
 32 - tex2lyx/roundtrip/XeTeX-polyglossia.tex (Failed)
 33 - tex2lyx/cmplyx/XeTeX-polyglossia.tex (Failed)
Errors while running CTest

Re: Test results for 2.2.0dev on Mac

2016-01-18 Thread Kornel Benko 
Am Montag, 18. Januar 2016 um 15:26:06, schrieb Scott Kostyshak 

> On Mon, Jan 18, 2016 at 09:23:47PM +0100, Stephan Witt wrote:
> > Running ctest there are 16 failed tests in tex2lyx. 
> > Is this to be expected? 
> 
> I don't think so. All of the tex2lyx tests pass for me.

Here too.

> > Where are the details to analyze it further?
> 
> In the CMake build directory, look at
> 
> Testing/Temporary/LastTest.log

To compare with my results, please try (in the build directory)
# ctest -R tex2lyx
too.

> Scott

Kornel

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