Re: Printer in 2.2.0alpha1

[Jean-Marc Lasgouttes]

Le 18/11/2015 17:07, Richard Heck a écrit :

I think it is good to have Ctrl+P bound to something that looks like
printing.


Excellent idea. We may need some prefs2prefs for this. I'm not sure. I
can do that if need be, or look into it.


I am not sure what we can do to mimic printing. We can think about it in 
terms of preview and maybe use the print preview icon for this action.


JMarc

Re: [LyX/master] Remove trailing space at the end of \author

[Kornel Benko]

Am Mittwoch, 18. November 2015 um 18:15:52, schrieb Jean-Marc Lasgouttes 

> Le 18/11/2015 03:52, Guillaume Munch a écrit :
> > commit 355f9a0efc9f90406c69aeab8c57220d0735154c
> > Author: Guillaume Munch 
> > Date:   Fri Nov 13 18:40:10 2015 +
> >
> >  Remove trailing space at the end of \author
> >
> >  Checked that the change is compatible with lyx2lyx (relevant lines are 
> > in
> >  lyx_2_0.py).
> 
> 
> But now we have failing tex2lyx tests...
> 
> JMarc

Only one, and the correction is really only the author line.

Kornel

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

Installation of Lyx without admin

[Weijie Chen]

Hi, is it possible that Lyx be installed on Windows without the admin 
privileges? I don't see such an installer right now and wonder if the 
developers plan to create such a thing, which will be very helpful to me and I 
believe to many others. Thank you.

Sent from Outlook

Re: [LyX/master] Remove trailing space at the end of \author

[Jean-Marc Lasgouttes]

Le 18/11/2015 03:52, Guillaume Munch a écrit :

commit 355f9a0efc9f90406c69aeab8c57220d0735154c
Author: Guillaume Munch 
Date:   Fri Nov 13 18:40:10 2015 +

 Remove trailing space at the end of \author

 Checked that the change is compatible with lyx2lyx (relevant lines are in
 lyx_2_0.py).



But now we have failing tex2lyx tests...

JMarc

Re: Printer in 2.2.0alpha1

[Richard Heck]

On 11/18/2015 09:57 AM, Jean-Marc Lasgouttes wrote:

Le 17/11/2015 18:08, Scott Kostyshak a écrit :

After reading Richard's reply, I think I misinterpreted your comment,
Miguel. So yes as Richard says, you can set this up with a converter
(the RELEASE-NOTES says this also).

By the way, please always respond to the list. And please bottom-post.


So, now that printing sup[port is gone, we could use Ctrl+P for 
Preview and assign that to View Default? Then Ctrl+R would be 
available for pdf or whatever.


I think it is good to have Ctrl+P bound to something that looks like 
printing.


Excellent idea. We may need some prefs2prefs for this. I'm not sure. I 
can do that if need be, or look into it.


Richard

Re: export test failures (was: Fix 480937a103708a651/lyxgit...)

[Guenter Milde]

On 2015-11-17, Kornel Benko wrote:
> Am Dienstag, 17. November 2015 um 20:36:42, schrieb Guenter Milde 
> 

>> >> >> > 3559:export/templates/IEEEtran-Conference_dvi3_texF
>> >> >> > 3566:export/templates/IEEEtran-Conference_pdf5_texF
>> >> >> > 3583:export/templates/IEEEtran-TransMag_dvi3_texF
>> >> >> > 3590:export/templates/IEEEtran-TransMag_pdf5_texF

>> >> >> Wrong encoding: the "experts only" option:

>> >> >> lib/templates/IEEEtran-Conference.lyx:16:\inputencoding default

>> >> >> writes in a mix of language dependent 8-bit encodings but does
>> >> >> not load inputenc nor add the encoding switch commands with
>> >> >> language changes.

>> >> >> Other instances:
> ...
> many documents ...

>> >> IMO, in all these documents:

>> >> - \inputencoding default
>> >> + \inputencoding auto


>> > OK, wait for Uwe.

>> For changes to the LyX Manual (lib/doc/*), Uwe's consent is required, I
>> don't know the responsibility for lib/examples and lib/templates, though.

> OK, I modified the tests to use 'auto' instead of 'default'
> inputencoding, 

My suggestion is not modifying tests, but to correct the documents that ship
with LyX!

> but only the 4 tests (export/templates/IEEEtran-Conference.*texF) are
> really better. All other still fail. 

Nevertheless, this would be a case of finding and correcting a bug (in
the templates, examples and one manual file) due to the export tests.


Günter

Re: [LyX/master] Cmake export tests: More tests to be reverted.

[Guenter Milde]

On 2015-11-17, Georg Baum wrote:
> Guenter Milde wrote:
>> On 2015-11-17, Georg Baum wrote:


>> I don't agree: don't make tests complicated and opaque only to test this
>> obscure combination¹ (nobody really needs it). If LyX throws an error,
>> invert the test.

¹  XeTeX + TeX fonts

> Inverting a test means: "I expect this test to fail, tell me if it does 
> not". If nobody needs the tested combination, don't run tests for it. 
> Running them although nobody cares for the result is only wasting time.

This was my first opinion, too. However, I became convinced by the
argument, that if LyX provides this export route, we should also test it.


> I made the suggestion above because it looked to me as if a lot of effort 
> was spent to make the combination XeTeX + TeX fonts work better. I think we 
> really should decide whether we care for this combination or not. If we 
> don't, then we should not spend further time with improving it, and we 
> should stop running tests which test it. 

If we don't care, we must also close this route. 

Unfortunately, I did not manage to do this, but my suggestion is to
"exclude" XeTeX (grey out the XeTeX button) for the combination 

  useNonTeXFonts == False && inputencoding != "ascii"

As none of the documents shipping with LyX has inputencoding == "ascii",
this would effectively allow us to ingore all pdf4TeXF tests.


> If we do care, then we should continue with testing, and if there are
> volunteers also with improving the code.

This is what I did after realizing I could not manage to close this route.

Günter

Re: [LyX/master] Cmake export tests: More tests to be reverted.

[Guenter Milde]

On 2015-11-17, Georg Baum wrote:

...

> Therefore I think it is a good idea to let the test machinery remove 
> comments at least for the XeTeX + TeX fonts tests, until a final decision 
> has been made whether we want to make our docs compilable for this exotic 
> combination or not.

Generally, I don't think it is a good idea to "massage" the documents
shipping with lyx in the test machinery until the tests pass.

* If the document can be made more robust (i.e. working with more than the
  default output format) without the changes standing in the way for its
  main purpose (documentation, templates, examples for LyX users), then this
  should be changes in the document itself.
  
* If the document has special needs (packages, ERT, preamble code ...)
  that make it uncompilable with some export formats, invert the test or
  ignore it - with appropriate comment. There remain enough files to
  test. 
  
  If some document in lib/... is important for testing a special
  feature/combination/... but fails for another reason, please don't 
  modify it in the test machinery, but instead convert it to a 
  *minimal working example* and put in a dedicated export test document
  folder. 
  
  This is far more easy to handle for other developers than test
  passing/failing for reasons that cannot be reproduced when compiling the
  same documents "by hand"!
  
Günter  

Re: [LyX/master] Remove trailing space at the end of \author

[Jean-Marc Lasgouttes]

Thank for fixing it.

Jmarc

Le 18 novembre 2015 18:37:42 GMT+01:00, Kornel Benko  a écrit :
>Am Mittwoch, 18. November 2015 um 18:15:52, schrieb Jean-Marc
>Lasgouttes 
>> Le 18/11/2015 03:52, Guillaume Munch a écrit :
>> > commit 355f9a0efc9f90406c69aeab8c57220d0735154c
>> > Author: Guillaume Munch 
>> > Date:   Fri Nov 13 18:40:10 2015 +
>> >
>> >  Remove trailing space at the end of \author
>> >
>> >  Checked that the change is compatible with lyx2lyx (relevant
>lines are in
>> >  lyx_2_0.py).
>> 
>> 
>> But now we have failing tex2lyx tests...
>> 
>> JMarc
>
>Only one, and the correction is really only the author line.
>
>   Kornel

Re: [patch] support for 'solution' in theorems

[Georg Baum]

Uwe Stöhr wrote:

> OK, tex2lyx forced me to add the solution environment also to the AMS
> theorem modules. Now the testfile works.

How can tex2lyx force you to touch completely unrelated modules? This looks 
like a bug in tex2lyx, which should be addressed properly.

BTW, you are hopefully aware of the current commit rules (trivial changes 
may go in directly, anything else needs to be supported by at least one 
developer)?

Changing the AMS theorem modules does not look like a trivial change to me, 
and I did not see any discussion of this change.


Georg

Re: [LyX/master] Cmake export tests: More tests to be reverted.

[Scott Kostyshak]

On Wed, Nov 18, 2015 at 06:38:42PM +, Guenter Milde wrote:
> On 2015-11-17, Georg Baum wrote:

> > Inverting a test means: "I expect this test to fail, tell me if it does 
> > not". If nobody needs the tested combination, don't run tests for it. 
> > Running them although nobody cares for the result is only wasting time.
> 
> This was my first opinion, too. However, I became convinced by the
> argument, that if LyX provides this export route, we should also test it.

+1

> > I made the suggestion above because it looked to me as if a lot of effort 
> > was spent to make the combination XeTeX + TeX fonts work better. I think we 
> > really should decide whether we care for this combination or not. If we 
> > don't, then we should not spend further time with improving it, and we 
> > should stop running tests which test it. 
> 
> If we don't care, we must also close this route. 

+1

Scott


signature.asc
Description: PGP signature

Re: [patch] support for 'solution' in theorems

[Georg Baum]

Uwe Stöhr wrote:

> Am 17.11.2015 um 20:05 schrieb Georg Baum:
> 
>> b) If the lyx2lyx conversion from the old to the new format is empty, or
>> if tex2lyx does not yet output the changed feature, you do not need any
>> further tex2lyx changes. Otherwise, search for the changed feature in
>> tex2lyx, and adjust the output according to the lyx2lyx changes.
>>
>> Now you can answer that question yourself.
> 
> Please Georg, if I would know it I wouldn't have asked.
> 
> The point is that tex2lyx reads theorems in a generic way by reading the
> \newtheorem statements from the preamble. But when using the attached
> TeX test file, the solution environment is not recognized as such and
> ERT is created. So I was asking what I should or maybe even must do.

Sorry, your question was

"Do I have to add special tex2lyx things?"

The answer to this question is "you do not need to add special tex2lyx 
things" and it can be derived from the cited part of Development.lyx.

>From your answer I see now that the question you had in mind was rather

"Do I have to add special tex2lyx things if I do not want tex2lyx to create 
ERT for the new feature?"

The answer to this question is not so easy. I would have to look in the 
sources. However, the test case you sent converts without ERT for me. Is 
that because you changed the other theorems as well?

> For now, since nobody objected and as Jürgen reviewed it I put it in.

Very good.


Georg

Re: [LyX/master] Document the export tests and other tests

[Georg Baum]

Kornel Benko wrote:

> Am Donnerstag, 29. Oktober 2015 um 22:26:27, schrieb Georg Baum
>> 
>> Therefore I would like to create some specific test cases for language
>> nesting. Pure export tests would be fine for now, we could still add a
>> comparison of the exported .tex later. With these tests it would be
>> enough to run those tests if any nesting bug is fixed to ensure that no
>> regressions are introduced. How would I add those tests? In which
>> directory? How to activate them in the test machinery?
>> 
> 
> This is easy, just add them in one of the scanned directories.
> To activate, rerun the configuration part (cmake .)
> 
> After this they are accessible with e.g.
> ctest -R 
> 
> The scanned directories (and subdirectories) are ATM
> lib/doc, lib/examples, lib/templates
> 
> Locally I have also added 'development/mathmacros'
> 
> See 'development/autotests/CMakefile.txt:141)

This is now development/autotests/ExportTests.cmake, right?

I created a new file autotests/export/languagenesting1.lyx and tried to add 
autotests/export to the list, but it did not work. Can you help me please?

BTW, I used autotests and not tests, because I learned recently that this is 
what KDE uses:

tests/... tests to be run manually
autotests/... tests to be run automatically (unit tests, functional tests 
etc)

I think it would be a good idea to follow this convention as well.


Georg

[RFC][PATCH] Get rid of some hardcoded pixel lengths

[Jean-Marc Lasgouttes]

Hi there,

The followong patch replaces the hardcoded TEXT_TO_INSET_OFFSET=4 and 
the workarea margin of 10 by respectively 1mm and 2.5mm. These values 
should be equivalent when dpi=100 and zoom=100%.


This idea was triggered by a message (a bug) saying that in HiDPI 
situations, placing the cursor was very difficult.


Please try it out. I'd be interested to know how it fares in different 
situations.


JMarc

>From a6c9f8a782d561ccea0bd5c2bb70c71527280c0e Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Thu, 12 Nov 2015 10:19:08 +0100
Subject: [PATCH] Replace hardcoded TEXT_TO_INSET_OFFSET by dynamic value

The value is counted as 1 millimeter now (the same at 100 dpi). We also ensures that it measures at least 1 pixel.

Similarly, the Workarea default margin is now 2.5mm instead of being hardcoded to 10.

This should improve the situation for HiDPI systems.
---
 src/BufferView.cpp   |  6 --
 src/RowPainter.cpp   |  2 +-
 src/frontends/qt4/GuiFontMetrics.cpp |  6 +++---
 src/frontends/qt4/GuiPainter.cpp |  4 ++--
 src/insets/Inset.cpp |  9 +
 src/insets/Inset.h   |  2 +-
 src/insets/InsetCaption.cpp  |  8 
 src/insets/InsetCollapsable.cpp  |  6 +++---
 src/insets/InsetIPA.cpp  | 12 ++--
 src/insets/InsetPhantom.cpp  |  4 ++--
 src/insets/InsetPreview.cpp  | 12 ++--
 src/insets/InsetTabular.cpp  |  4 ++--
 src/insets/InsetText.cpp | 28 ++--
 src/insets/RenderGraphic.cpp | 18 +-
 src/insets/RenderPreview.cpp |  2 +-
 15 files changed, 67 insertions(+), 56 deletions(-)

diff --git a/src/BufferView.cpp b/src/BufferView.cpp
index 0030f33..902f8a7 100644
--- a/src/BufferView.cpp
+++ b/src/BufferView.cpp
@@ -351,11 +351,13 @@ BufferView::~BufferView()
 
 int BufferView::rightMargin() const
 {
+	// THe value used to be hardcoded to 10, which is 2.5mm at 100dpi
+	int const default_margin = Length(2.5, Length::MM).inPixels(0);
 	// The additional test for the case the outliner is opened.
 	if (!full_screen_ ||
 		!lyxrc.full_screen_limit ||
-		width_ < lyxrc.full_screen_width + 20)
-			return 10;
+		width_ < lyxrc.full_screen_width + 2 * default_margin)
+			return default_margin;
 
 	return (width_ - lyxrc.full_screen_width) / 2;
 }
diff --git a/src/RowPainter.cpp b/src/RowPainter.cpp
index ce5780b..3d360d4 100644
--- a/src/RowPainter.cpp
+++ b/src/RowPainter.cpp
@@ -540,7 +540,7 @@ void RowPainter::paintLast()
 		FontMetrics const & fm = theFontMetrics(font);
 		int const size = int(0.75 * fm.maxAscent());
 		int const y = yo_ - size;
-		int const max_row_width = width_ - size - Inset::TEXT_TO_INSET_OFFSET;
+		int const max_row_width = width_ - size - Inset::textToInsetOffset();
 		int x = is_rtl ? nestMargin() + changebarMargin()
 			: max_row_width - row_.right_margin;
 
diff --git a/src/frontends/qt4/GuiFontMetrics.cpp b/src/frontends/qt4/GuiFontMetrics.cpp
index 8d0b026..d4f3585 100644
--- a/src/frontends/qt4/GuiFontMetrics.cpp
+++ b/src/frontends/qt4/GuiFontMetrics.cpp
@@ -237,9 +237,9 @@ bool GuiFontMetrics::breakAt(docstring & s, int & x, bool const rtl, bool const
 void GuiFontMetrics::rectText(docstring const & str,
 	int & w, int & ascent, int & descent) const
 {
-	static int const d = Inset::TEXT_TO_INSET_OFFSET / 2;
+	static int const d = Inset::textToInsetOffset() / 2;
 
-	w = width(str) + Inset::TEXT_TO_INSET_OFFSET;
+	w = width(str) + Inset::textToInsetOffset();
 	ascent = metrics_.ascent() + d;
 	descent = metrics_.descent() + d;
 }
@@ -250,7 +250,7 @@ void GuiFontMetrics::buttonText(docstring const & str,
 	int & w, int & ascent, int & descent) const
 {
 	rectText(str, w, ascent, descent);
-	w += Inset::TEXT_TO_INSET_OFFSET;
+	w += Inset::textToInsetOffset();
 }
 
 
diff --git a/src/frontends/qt4/GuiPainter.cpp b/src/frontends/qt4/GuiPainter.cpp
index 2b024d8..af75547 100644
--- a/src/frontends/qt4/GuiPainter.cpp
+++ b/src/frontends/qt4/GuiPainter.cpp
@@ -533,10 +533,10 @@ void GuiPainter::buttonText(int x, int y, docstring const & str,
 	FontMetrics const & fm = theFontMetrics(font);
 	fm.buttonText(str, width, ascent, descent);
 
-	static int const d = Inset::TEXT_TO_INSET_OFFSET / 2;
+	static int const d = Inset::textToInsetOffset() / 2;
 
 	button(x + d, y - ascent, width - d, descent + ascent, mouseHover);
-	text(x + Inset::TEXT_TO_INSET_OFFSET, y, str, font);
+	text(x + Inset::textToInsetOffset(), y, str, font);
 }
 
 
diff --git a/src/insets/Inset.cpp b/src/insets/Inset.cpp
index 0fce648..1d8e9f4 100644
--- a/src/insets/Inset.cpp
+++ b/src/insets/Inset.cpp
@@ -27,6 +27,7 @@
 #include "DispatchResult.h"
 #include "FuncRequest.h"
 #include "FuncStatus.h"
+#include "Length.h"
 #include "MetricsInfo.h"
 #include "output_xhtml.h"
 #include "Text.h"
@@ -617,6 +618,14 @@ ColorCode Inset::labelColor() const
 }
 
 
+int Inset::textToInsetOffset()
+{

Re: export test failures 2

[Kornel Benko]

Am Dienstag, 17. November 2015 um 19:53:35, schrieb Kornel Benko 

> The thread 'export test failures' started to be confusing.
>
> Suddenly, after updating TL2015, 2 new tests are failing
>   export/examples/powerdot-example_pdf
>   export/examples/fr/exemple-powerdot_pdf
>
> The list of failed tests nevertheless shortened to 92 cases (attached).
>

Sorry, it was an old list.

Kornel

signature.asc
Description: This is a digitally signed message part.
737:export/doc/es/EmbeddedObjects_dvi3_texF
742:export/doc/es/EmbeddedObjects_pdf4_texF
743:export/doc/es/EmbeddedObjects_pdf4_systemF
744:export/doc/es/EmbeddedObjects_pdf5_texF
809:export/doc/es/UserGuide_dvi3_texF
814:export/doc/es/UserGuide_pdf4_texF
816:export/doc/es/UserGuide_pdf5_texF
817:export/doc/es/UserGuide_pdf5_systemF
850:export/doc/fr/Additional_pdf4_texF
853:export/doc/fr/Additional_pdf5_systemF
865:export/doc/fr/Customization_pdf5_systemF
899:export/doc/fr/EmbeddedObjects_pdf4_systemF
970:export/doc/fr/UserGuide_pdf4_texF
973:export/doc/fr/UserGuide_pdf5_systemF
1245:export/doc/nb/Intro_pdf5_systemF
1333:export/doc/ru/Intro_dvi3_texF
1338:export/doc/ru/Intro_pdf4_texF
1340:export/doc/ru/Intro_pdf5_texF
1345:export/doc/ru/Tutorial_dvi3_texF
1350:export/doc/ru/Tutorial_pdf4_texF
1352:export/doc/ru/Tutorial_pdf5_texF
1365:export/doc/sk/Intro_pdf5_systemF
1568:export/examples/PDF-comment_pdf5_texF
1609:export/examples/aas_sample_dvi3_texF
1610:export/examples/aas_sample_dvi3_systemF
1616:export/examples/aas_sample_pdf5_texF
1617:export/examples/aas_sample_pdf5_systemF
1621:export/examples/achemso_dvi3_texF
1628:export/examples/achemso_pdf5_texF
1726:export/examples/europeCV_dvi3_texF
1727:export/examples/europeCV_dvi3_systemF
1733:export/examples/europeCV_pdf5_texF
1734:export/examples/europeCV_pdf5_systemF
1808:export/examples/linguistics_dvi3_systemF
1813:export/examples/linguistics_pdf4_systemF
1815:export/examples/linguistics_pdf5_systemF
1840:export/examples/modernCV_dvi3_texF
1841:export/examples/modernCV_dvi3_systemF
1845:export/examples/modernCV_pdf4_texF
1846:export/examples/modernCV_pdf4_systemF
1847:export/examples/modernCV_pdf5_texF
1848:export/examples/modernCV_pdf5_systemF
1863:export/examples/powerdot-example_pdf
1896:export/examples/seminar_pdf
1897:export/examples/seminar_pdf2
1898:export/examples/seminar_pdf3
1899:export/examples/seminar_pdf4_texF
1902:export/examples/seminar_pdf5_systemF
2548:export/examples/de/PDF-comment_dvi3_texF
2549:export/examples/de/PDF-comment_dvi3_systemF
2555:export/examples/de/PDF-comment_pdf5_texF
2725:export/examples/es/europeCV_dvi3_texF
2726:export/examples/es/europeCV_dvi3_systemF
2732:export/examples/es/europeCV_pdf5_texF
2733:export/examples/es/europeCV_pdf5_systemF
2742:export/examples/es/linguistics_pdf4_texF
2749:export/examples/es/modernCV_dvi3_texF
2750:export/examples/es/modernCV_dvi3_systemF
2756:export/examples/es/modernCV_pdf5_texF
2757:export/examples/es/modernCV_pdf5_systemF
2814:export/examples/fa/splash_dvi
2817:export/examples/fa/splash_pdf
2818:export/examples/fa/splash_pdf2
2819:export/examples/fa/splash_pdf3
2820:export/examples/fa/splash_pdf4_texF
2821:export/examples/fa/splash_pdf4_systemF
2871:export/examples/fr/Foils_pdf5_systemF
2899:export/examples/fr/PDF-comment_dvi3_texF
2900:export/examples/fr/PDF-comment_dvi3_systemF
2906:export/examples/fr/PDF-comment_pdf5_texF
2910:export/examples/fr/exemple-powerdot_pdf
2955:export/examples/fr/seminar_dvi
2958:export/examples/fr/seminar_pdf
2959:export/examples/fr/seminar_pdf2
2960:export/examples/fr/seminar_pdf3
2961:export/examples/fr/seminar_pdf4_texF
2964:export/examples/fr/seminar_pdf5_systemF
3072:export/examples/he/splash_pdf5_systemF
3247:export/examples/ko/splash_dvi3_texF
3252:export/examples/ko/splash_pdf4_texF
3254:export/examples/ko/splash_pdf5_texF
3343:export/examples/ru/splash_dvi3_texF
3348:export/examples/ru/splash_pdf4_texF
3350:export/examples/ru/splash_pdf5_texF
3439:export/examples/uk/splash_dvi3_texF
3444:export/examples/uk/splash_pdf4_texF
3446:export/examples/uk/splash_pdf5_texF
3500:export/templates/AGUTeX_dvi3_systemF
3505:export/templates/AGUTeX_pdf4_systemF
3507:export/templates/AGUTeX_pdf5_systemF

Re: Printer in 2.2.0alpha1

[Jean-Marc Lasgouttes]

Le 17/11/2015 18:08, Scott Kostyshak a écrit :

After reading Richard's reply, I think I misinterpreted your comment,
Miguel. So yes as Richard says, you can set this up with a converter
(the RELEASE-NOTES says this also).

By the way, please always respond to the list. And please bottom-post.


So, now that printing sup[port is gone, we could use Ctrl+P for Preview 
and assign that to View Default? Then Ctrl+R would be available for pdf 
or whatever.


I think it is good to have Ctrl+P bound to something that looks like 
printing.


JMarc

Re: [RFC][PATCH] Get rid of some hardcoded pixel lengths

[PhilipPirrip]

On 11/18/2015 05:57 AM, Jean-Marc Lasgouttes wrote:

Hi there,

The followong patch replaces the hardcoded TEXT_TO_INSET_OFFSET=4 and
the workarea margin of 10 by respectively 1mm and 2.5mm. These values
should be equivalent when dpi=100 and zoom=100%.

This idea was triggered by a message (a bug) saying that in HiDPI
situations, placing the cursor was very difficult.



I didn't find placing the cursor difficult, it only looked too tight. 
But now you have some insets grown vertically, they increase the line 
spacing which looks a bit messy: 
wiki.lyx.org/uploads/Playground/JML-get_rid_of_some_hardcoded_pixel_lengths.png


This is on Fedora Linux 23, HiDPI Dell XPS 3200x1800. Qt 4.8.7

Re: export test failures 2

[Kornel Benko]

Am Donnerstag, 19. November 2015 um 01:37:11, schrieb Kornel Benko 

> Am Mittwoch, 18. November 2015 um 23:39:57, schrieb Guenter Milde 
> 
> > On 2015-11-18, Kornel Benko wrote:
> >
> > >> Suddenly, after updating TL2015, 2 new tests are failing
> > >>  export/examples/powerdot-example_pdf
> > >>  export/examples/fr/exemple-powerdot_pdf
> >
> > >> The list of failed tests nevertheless shortened to 92 cases (attached).
> >
> > > Sorry, it was an old list.
> >
> >
> > 737:export/doc/es/.*_dvi3_texF
> > 742:export/doc/es/.*_pdf4_texF
> > 744:export/doc/es/.*_pdf5_texF

...

Now 57 failed left

>
> > Günter
>
Kornel669:export/doc/de/UserGuide_pdf3
1621:export/examples/achemso_dvi3_texF
1628:export/examples/achemso_pdf5_texF
1726:export/examples/europeCV_dvi3_texF
1727:export/examples/europeCV_dvi3_systemF
1733:export/examples/europeCV_pdf5_texF
1734:export/examples/europeCV_pdf5_systemF
1808:export/examples/linguistics_dvi3_systemF
1813:export/examples/linguistics_pdf4_systemF
1815:export/examples/linguistics_pdf5_systemF
1840:export/examples/modernCV_dvi3_texF
1841:export/examples/modernCV_dvi3_systemF
1845:export/examples/modernCV_pdf4_texF
1846:export/examples/modernCV_pdf4_systemF
1847:export/examples/modernCV_pdf5_texF
1848:export/examples/modernCV_pdf5_systemF
1863:export/examples/powerdot-example_pdf
1897:export/examples/seminar_pdf2
1898:export/examples/seminar_pdf3
1899:export/examples/seminar_pdf4_texF
1902:export/examples/seminar_pdf5_systemF
2548:export/examples/de/PDF-comment_dvi3_texF
2549:export/examples/de/PDF-comment_dvi3_systemF
2555:export/examples/de/PDF-comment_pdf5_texF
2725:export/examples/es/europeCV_dvi3_texF
2726:export/examples/es/europeCV_dvi3_systemF
2732:export/examples/es/europeCV_pdf5_texF
2733:export/examples/es/europeCV_pdf5_systemF
2742:export/examples/es/linguistics_pdf4_texF
2749:export/examples/es/modernCV_dvi3_texF
2750:export/examples/es/modernCV_dvi3_systemF
2756:export/examples/es/modernCV_pdf5_texF
2757:export/examples/es/modernCV_pdf5_systemF
2814:export/examples/fa/splash_dvi
2817:export/examples/fa/splash_pdf
2818:export/examples/fa/splash_pdf2
2819:export/examples/fa/splash_pdf3
2820:export/examples/fa/splash_pdf4_texF
2821:export/examples/fa/splash_pdf4_systemF
2871:export/examples/fr/Foils_pdf5_systemF
2899:export/examples/fr/PDF-comment_dvi3_texF
2900:export/examples/fr/PDF-comment_dvi3_systemF
2906:export/examples/fr/PDF-comment_pdf5_texF
2910:export/examples/fr/exemple-powerdot_pdf
2955:export/examples/fr/seminar_dvi
2958:export/examples/fr/seminar_pdf
2959:export/examples/fr/seminar_pdf2
2960:export/examples/fr/seminar_pdf3
2961:export/examples/fr/seminar_pdf4_texF
2964:export/examples/fr/seminar_pdf5_systemF
3072:export/examples/he/splash_pdf5_systemF
3247:export/examples/ko/splash_dvi3_texF
3252:export/examples/ko/splash_pdf4_texF
3254:export/examples/ko/splash_pdf5_texF
3500:export/templates/AGUTeX_dvi3_systemF
3505:export/templates/AGUTeX_pdf4_systemF
3507:export/templates/AGUTeX_pdf5_systemF


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

Re: export test failures 2

[Kornel Benko]

Am Mittwoch, 18. November 2015 um 23:39:57, schrieb Guenter Milde 

> On 2015-11-18, Kornel Benko wrote:
> 
> >> Suddenly, after updating TL2015, 2 new tests are failing
> >>export/examples/powerdot-example_pdf
> >>export/examples/fr/exemple-powerdot_pdf
> 
> >> The list of failed tests nevertheless shortened to 92 cases (attached).
> 
> > Sorry, it was an old list.
> 
> 
> 737:export/doc/es/.*_dvi3_texF
> 742:export/doc/es/.*_pdf4_texF
> 744:export/doc/es/.*_pdf5_texF
> 
> Babel-Spanish uses Babel's "strings" feature to define separate auto-strings
> using UTF-8 literals.
> 
> Babel uses the "unicode" strings if it detects XeTeX or LuaTeX.
> This is wrong for Xe/Lua with 8-bit TeX-fonts.
> (It can be overridden adding the "strings=generic" option to Babel.)
> 
> For now, invert.

Done

> 
> 743:export/doc/es/EmbeddedObjects_pdf4_systemF
> 
> 
> 817:export/doc/es/UserGuide_pdf5_systemF
> 
> * lmodern.sty
> * missing commands and missing characters
> -> invert
> 

Done

> 850:export/doc/fr/Additional_pdf4_texF
> 
> Non-ASCII in ERT
> 
> invert

Done
 
> 970:export/doc/fr/UserGuide_pdf4_texF
> 
> Non-ASCII in verbatim and index entries
> 
> invert
> 

Done

> 853:export/doc/fr/Additional_pdf5_systemF
> 865:export/doc/fr/Customization_pdf5_systemF
> 899:export/doc/fr/EmbeddedObjects_pdf4_systemF
> 973:export/doc/fr/UserGuide_pdf5_systemF
> 
> lmodern.sty? + maybe more

Done (inverted)

> 1245:export/doc/nb/Intro_pdf5_systemF
> 
> language nesting error (polyglossia) (known bug)
> 
> invert.

Done

> 1333:export/doc/ru/Intro_dvi3_texF
> 1338:export/doc/ru/Intro_pdf4_texF
> 1340:export/doc/ru/Intro_pdf5_texF
> 1345:export/doc/ru/Tutorial_dvi3_texF
> 1350:export/doc/ru/Tutorial_pdf4_texF
> 1352:export/doc/ru/Tutorial_pdf5_texF
> 
> Babel-Russian uses UTF-8 for auto-strings if it detects Xe/LuaTeX.
> This fails unless the inputencoding is set to utf-8, too.
> 
> Invert.

Done

> 1365:export/doc/sk/Intro_pdf5_systemF
> 1568:export/examples/PDF-comment_pdf5_texF
> 1609:export/examples/aas_sample_dvi3_texF
> 1610:export/examples/aas_sample_dvi3_systemF
> 1616:export/examples/aas_sample_pdf5_texF
> 1617:export/examples/aas_sample_pdf5_systemF
> 
> 
> 1621:export/examples/achemso_dvi3_texF
> 1628:export/examples/achemso_pdf5_texF
> 
> chemgreek incompatible with LuaTeX (cf. Math.lyx)
> invert for now.
> 

Done

> ...
> 
> 
> 1896:export/examples/seminar_pdf
> 
> Works here.

Moved to nonstandardTests

> 3343:export/examples/ru/splash_dvi3_texF
> 3348:export/examples/ru/splash_pdf4_texF
> 3350:export/examples/ru/splash_pdf5_texF
> 3439:export/examples/uk/splash_dvi3_texF
> 3444:export/examples/uk/splash_pdf4_texF
> 3446:export/examples/uk/splash_pdf5_texF
> 
> Russian-babel uses utf8 with xe/lua
> 
> invert.

Done

> Günter

Kornel

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

Re: export test failures (was: Fix 480937a103708a651/lyxgit...)

[Kornel Benko]

Am Mittwoch, 18. November 2015 um 18:42:52, schrieb Guenter Milde 

> > OK, I modified the tests to use 'auto' instead of 'default'
> > inputencoding, 
> 
> My suggestion is not modifying tests, but to correct the documents that ship
> with LyX!

Dear Günter, I did it locally to check if something changes. I have not 
committed anything.

> > but only the 4 tests (export/templates/IEEEtran-Conference.*texF) are
> > really better. All other still fail. 
> 
> Nevertheless, this would be a case of finding and correcting a bug (in
> the templates, examples and one manual file) due to the export tests.

Sure.

Kornel

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

Re: [LyX/master] Document the export tests and other tests

[Kornel Benko]

Am Mittwoch, 18. November 2015 um 22:35:09, schrieb Kornel Benko 

> Am Mittwoch, 18. November 2015 um 21:50:45, schrieb Georg Baum 
> 
> > Kornel Benko wrote:
> > 
> > > Am Donnerstag, 29. Oktober 2015 um 22:26:27, schrieb Georg Baum
> > >> 
> > >> Therefore I would like to create some specific test cases for language
> > >> nesting. Pure export tests would be fine for now, we could still add a
> > >> comparison of the exported .tex later. With these tests it would be
> > >> enough to run those tests if any nesting bug is fixed to ensure that no
> > >> regressions are introduced. How would I add those tests? In which
> > >> directory? How to activate them in the test machinery?
> > >> 
> > > 
> > > This is easy, just add them in one of the scanned directories.
> > > To activate, rerun the configuration part (cmake .)
> > > 
> > > After this they are accessible with e.g.
> > > ctest -R 
> > > 
> > > The scanned directories (and subdirectories) are ATM
> > > lib/doc, lib/examples, lib/templates
> > > 
> > > Locally I have also added 'development/mathmacros'
> > > 
> > > See 'development/autotests/CMakefile.txt:141)
> > 
> > This is now development/autotests/ExportTests.cmake, right?
> 
> Yes, sorry development/autotests/ExportTests.cmake:170 Agh
> 
> > I created a new file autotests/export/languagenesting1.lyx and tried to add 
> > autotests/export to the list, but it did not work. Can you help me please?
> 
> ATM, the line reads
>   'foreach(libsubfolderx lib/doc lib/examples lib/templates)'
> 
> > BTW, I used autotests and not tests, because I learned recently that this 
> > is 
> > what KDE uses:
> > 
> > tests/... tests to be run manually
> > autotests/... tests to be run automatically (unit tests, functional tests 
> > etc)
> 
> You mean development/tests ?

Ouch, I misunderstood.
Please do not name it export, it would come to name conflicts.
I name it xyzzy here:
Replace the 3 lines 'foreach()...'
foreach(libsubfolderx lib/doc lib/examples lib/templates autotests/xyzzy)
  set(LIBSUB_SRC_DIR "${TOP_SRC_DIR}/${libsubfolderx}")
  string(REGEX REPLACE "^(lib|development|autotest)/" "" libsubfolder 
"${libsubfolderx}")


Kornel

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

Re: [RFC][PATCH] Get rid of some hardcoded pixel lengths

[Scott Kostyshak]

On Wed, Nov 18, 2015 at 10:36:54PM +0100, Jean-Marc Lasgouttes wrote:
> Le 18/11/15 22:27, Scott Kostyshak a écrit :
> > From what I understand, you use a static function as opposed to a static
> >variable because it needs to be constantly recomputed in case, e.g.
> >there is a zoom. First, I do not understand why the value changes for me
> >if there is a zoom (which it does seem to do in testing) whereas the
> >value was fixed before. Since I do not have a HiDPI I did not expect a
> >difference.
> 
> Well, you can expect that the spacing is, say, half of the width of a 'm'.
> So if you zoom in, the size increases.

I just did not expect this change from your patch's description since
before, Inset::TEXT_TO_INSET_OFFSET was fixed. I thought that there
would only be improvements for HiDPI.

> >Second, if it does need to be recomputed, would it be more efficient to
> >only recompute it when triggered by certain events (e.g. a zoom) instead
> >of recomputing it every time?
> 
> I thought about it, but it remains to be proved that computing the value is
> expensive. It is just a few multiplications.

I see. Makes sense.

> Nothing compared to painting or
> measuring text

or checking whether previews need updating, as I have learned.

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Document the export tests and other tests

[Kornel Benko]

Am Mittwoch, 18. November 2015 um 21:50:45, schrieb Georg Baum 

> Kornel Benko wrote:
> 
> > Am Donnerstag, 29. Oktober 2015 um 22:26:27, schrieb Georg Baum
> >> 
> >> Therefore I would like to create some specific test cases for language
> >> nesting. Pure export tests would be fine for now, we could still add a
> >> comparison of the exported .tex later. With these tests it would be
> >> enough to run those tests if any nesting bug is fixed to ensure that no
> >> regressions are introduced. How would I add those tests? In which
> >> directory? How to activate them in the test machinery?
> >> 
> > 
> > This is easy, just add them in one of the scanned directories.
> > To activate, rerun the configuration part (cmake .)
> > 
> > After this they are accessible with e.g.
> > ctest -R 
> > 
> > The scanned directories (and subdirectories) are ATM
> > lib/doc, lib/examples, lib/templates
> > 
> > Locally I have also added 'development/mathmacros'
> > 
> > See 'development/autotests/CMakefile.txt:141)
> 
> This is now development/autotests/ExportTests.cmake, right?

Yes, sorry development/autotests/ExportTests.cmake:170 Agh

> I created a new file autotests/export/languagenesting1.lyx and tried to add 
> autotests/export to the list, but it did not work. Can you help me please?

ATM, the line reads
'foreach(libsubfolderx lib/doc lib/examples lib/templates)'

> BTW, I used autotests and not tests, because I learned recently that this is 
> what KDE uses:
> 
> tests/... tests to be run manually
> autotests/... tests to be run automatically (unit tests, functional tests 
> etc)

You mean development/tests ?
In that case the line should be expanded to:
'foreach(libsubfolderx lib/doc lib/examples lib/templates 
development/tests)'
and you are done.

> I think it would be a good idea to follow this convention as well.
> 
> 
> Georg

Kornel

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

Re: [RFC][PATCH] Get rid of some hardcoded pixel lengths

[Jean-Marc Lasgouttes]

Le 18/11/15 22:27, Scott Kostyshak a écrit :

 From what I understand, you use a static function as opposed to a static
variable because it needs to be constantly recomputed in case, e.g.
there is a zoom. First, I do not understand why the value changes for me
if there is a zoom (which it does seem to do in testing) whereas the
value was fixed before. Since I do not have a HiDPI I did not expect a
difference.


Well, you can expect that the spacing is, say, half of the width of a 
'm'. So if you zoom in, the size increases.



Second, if it does need to be recomputed, would it be more efficient to
only recompute it when triggered by certain events (e.g. a zoom) instead
of recomputing it every time?


I thought about it, but it remains to be proved that computing the value 
is expensive. It is just a few multiplications. Nothing compared to 
painting or measuring text.


JMarc

Re: export test failures 2

[Guenter Milde]

On 2015-11-18, Kornel Benko wrote:

>> Suddenly, after updating TL2015, 2 new tests are failing
>>  export/examples/powerdot-example_pdf
>>  export/examples/fr/exemple-powerdot_pdf

>> The list of failed tests nevertheless shortened to 92 cases (attached).

> Sorry, it was an old list.


737:export/doc/es/.*_dvi3_texF
742:export/doc/es/.*_pdf4_texF
744:export/doc/es/.*_pdf5_texF

Babel-Spanish uses Babel's "strings" feature to define separate auto-strings
using UTF-8 literals.

Babel uses the "unicode" strings if it detects XeTeX or LuaTeX.
This is wrong for Xe/Lua with 8-bit TeX-fonts.
(It can be overridden adding the "strings=generic" option to Babel.)

For now, invert.


743:export/doc/es/EmbeddedObjects_pdf4_systemF


817:export/doc/es/UserGuide_pdf5_systemF

* lmodern.sty
* missing commands and missing characters
-> invert


850:export/doc/fr/Additional_pdf4_texF

Non-ASCII in ERT

invert

970:export/doc/fr/UserGuide_pdf4_texF

Non-ASCII in verbatim and index entries

invert


853:export/doc/fr/Additional_pdf5_systemF
865:export/doc/fr/Customization_pdf5_systemF
899:export/doc/fr/EmbeddedObjects_pdf4_systemF
973:export/doc/fr/UserGuide_pdf5_systemF

lmodern.sty? + maybe more

1245:export/doc/nb/Intro_pdf5_systemF

language nesting error (polyglossia) (known bug)

invert.

1333:export/doc/ru/Intro_dvi3_texF
1338:export/doc/ru/Intro_pdf4_texF
1340:export/doc/ru/Intro_pdf5_texF
1345:export/doc/ru/Tutorial_dvi3_texF
1350:export/doc/ru/Tutorial_pdf4_texF
1352:export/doc/ru/Tutorial_pdf5_texF

Babel-Russian uses UTF-8 for auto-strings if it detects Xe/LuaTeX.
This fails unless the inputencoding is set to utf-8, too.

Invert.

1365:export/doc/sk/Intro_pdf5_systemF
1568:export/examples/PDF-comment_pdf5_texF
1609:export/examples/aas_sample_dvi3_texF
1610:export/examples/aas_sample_dvi3_systemF
1616:export/examples/aas_sample_pdf5_texF
1617:export/examples/aas_sample_pdf5_systemF


1621:export/examples/achemso_dvi3_texF
1628:export/examples/achemso_pdf5_texF

chemgreek incompatible with LuaTeX (cf. Math.lyx)
invert for now.


...


1896:export/examples/seminar_pdf

Works here.

3343:export/examples/ru/splash_dvi3_texF
3348:export/examples/ru/splash_pdf4_texF
3350:export/examples/ru/splash_pdf5_texF
3439:export/examples/uk/splash_dvi3_texF
3444:export/examples/uk/splash_pdf4_texF
3446:export/examples/uk/splash_pdf5_texF

Russian-babel uses utf8 with xe/lua

invert.


Günter

Re: Packagers, please upload binaries for 2.2.0alpha1

[Uwe Stöhr]

One last question before I upload: could you please send by email the
MD5 sums of the files that I should upload

Ehm, just upload the installer, the 40MB file.

 > (so in this case it will be
just the MD5 sum for the installer but for the final release I will also
want the MD5 sum for the bundle)? I'm sorry for this extra step, which I
don't think you had to do before, but I would feel much more confident
that your upload to FTP was not corrupted and my download from your FTP
was not corrupted.

Please don't make LyX development more complicated than necessary. I run lyx.de 
so what is the problem? If my installer would contain e.g. virus aa checksum 
wouldn't help anyway. We never had any problem the last years so why should we 
now?

> Ideally, you would create a PGP key and you would sign the files that
you upload.

Why should I do this? What are you afraid of? Maybe I am not educated enough to 
understand the benefit of signing files. Please explain me.

Thanks and regards Uwe 

LyX 2.2 + Qt 5.5.1 segmentation fault on Fedora 23

[PhilipPirrip]

I had a similar issue a month or so ago, what helped was a clean cloning 
of LyX source. Now even that doesn't work, and it's been like that for 2 
or 3 weeks. It might be due to newest Qt libraries that came with Fedora 
23, not sure. Can you read anything from this backtrace?



(...after installing 3GB of various debuginfos)



(gdb) run
Starting program: /xxx/xxx/xxx/build-lyx-Qt5/bin/lyx2.2
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
QList::QList (this=0x76e4b578 
) at 
../../src/corelib/tools/qlist.h:121

121 inline QList() : d(::shared_null) { d->ref.ref(); }
Missing separate debuginfos, use: dnf debuginfo-install 
bzip2-libs-1.0.6-17.fc23.x86_64 libgcc-5.1.1-4.fc23.x86_64 
libstdc++-5.1.1-4.fc23.x86_64

(gdb) bt
#0  QList::QList (this=0x76e4b578 
) at 
../../src/corelib/tools/qlist.h:121
#1  QPrinterInfoPrivate::QPrinterInfoPrivate (name=..., 
this=0x76e4b560 ) at 
painting/qprinterinfo_p.h:71
#2  __static_initialization_and_destruction_0 (__initialize_p=1, 
__priority=65535) at painting/qprinterinfo.cpp:35
#3  _GLOBAL__sub_I_qprinterinfo.cpp(void) () at 
painting/qprinterinfo.cpp:163
#4  0x77deb79a in call_init (l=, 
argc=argc@entry=1, argv=argv@entry=0x7fffdfd8, 
env=env@entry=0x7fffdfe8)

at dl-init.c:72
#5  0x77deb8ab in call_init (env=0x7fffdfe8, 
argv=0x7fffdfd8, argc=1, l=) at dl-init.c:30
#6  _dl_init (main_map=0x77ffe148, argc=1, argv=0x7fffdfd8, 
env=0x7fffdfe8) at dl-init.c:120

#7  0x77ddccba in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#8  0x0001 in ?? ()
#9  0x7fffe2d5 in ?? ()
#10 0x in ?? ()
















here's the run_cmake.sh I used
cmake /xxx/xxx/xxx/lyx  \
 -G"Unix Makefiles"  \
 -DLYX_CPACK=OFF  \
 -DLYX_LOCALVERSIONING=OFF  \
 -DLYX_INSTALL=OFF  \
 -DLYX_NLS=ON  \
 -DLYX_REQUIRE_SPELLCHECK=OFF  \
 -DLYX_ASPELL=OFF  \
 -DLYX_ENCHANT=OFF  \
 -DLYX_HUNSPELL=OFF  \
 -DLYX_DEVEL_VERSION=OFF  \
 -DLYX_RELEASE=OFF  \
 -DLYX_DEBUG=ON  \
 -DLYX_NO_OPTIMIZE=OFF  \
 -DLYX_PACKAGE_SUFFIX=ON  \
 -DLYX_PCH=OFF  \
 -DLYX_MERGE_FILES=OFF  \
 -DLYX_MERGE_REBUILD=OFF  \
 -DLYX_QUIET=OFF  \
 -DLYX_INSTALL_PREFIX=OFF  \
 -DLYX_BUNDLE=OFF  \
 -DLYX_ENABLE_URLTESTS=OFF  \
 -DLYX_ENABLE_EXPORT_TESTS=OFF  \
 -DLYX_ASAN=OFF  \
 -DLYX_USE_QT=QT5  \
 -DLYX_PROFILE=OFF  \
 -DLYX_EXTERNAL_BOOST=OFF  \
 -DLYX_PROGRAM_SUFFIX=ON  \
 -DLYX_DEBUG_GLIBC=OFF  \
 -DLYX_DEBUG_GLIBC_PEDANTIC=OFF  \
 -DLYX_STDLIB_DEBUG=OFF  \
 -DLYX_PROFILE=OFF  \
 -DLYX_ENABLE_CXX11=OFF  \





Same thing even if I go back in time, to some 9/2015 commits I know worked.
Doesn't matter if I set CXX11 to ON or OFF.

Re: [RFC][PATCH] Get rid of some hardcoded pixel lengths

[Jean-Marc Lasgouttes]

Le 19/11/2015 03:17, PhilipPirrip a écrit :

I didn't find placing the cursor difficult, it only looked too tight.


Would you say that the extra horizontal spacing is nevertheless useful?


But now you have some insets grown vertically, they increase the line
spacing which looks a bit messy:
wiki.lyx.org/uploads/Playground/JML-get_rid_of_some_hardcoded_pixel_lengths.png


Yes, that's pretty bad. THis has to be addressed indeed.

JMarc

Re: LyX 2.2 + Qt 5.5.1 segmentation fault on Fedora 23

[Stephan Witt]

Am 19.11.2015 um 04:00 schrieb PhilipPirrip :

> I had a similar issue a month or so ago, what helped was a clean cloning of 
> LyX source. Now even that doesn't work, and it's been like that for 2 or 3 
> weeks. It might be due to newest Qt libraries that came with Fedora 23, not 
> sure. Can you read anything from this backtrace?

I've redirected it to developers list.

> Reading symbols from ./bin/lyx2.2...done.
> (gdb) run
> Starting program: /build-lyx-Qt5/bin/lyx2.2
> Missing separate debuginfos, use: dnf debuginfo-install 
> glibc-2.22-5.fc23.x86_64
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x76305204 in _GLOBAL__sub_I_qprinterinfo.cpp () from 
> /lib64/libQtGui.so.4

What is that (libQtGui.so.4)? Are you sure your linking with Qt5 at runtime?

> Missing separate debuginfos, use: dnf debuginfo-install 
> aspell-0.60.6.1-12.fc23.x86_64 bzip2-libs-1.0.6-17.fc23.x86_64 
> expat-2.1.0-12.fc23.x86_64 fontconfig-2.11.94-4.fc23.x86_64 
> freetype-2.6.0-3.fc23.x86_64 glib2-2.46.1-2.fc23.x86_64 
> graphite2-1.2.4-5.fc23.x86_64 harfbuzz-1.0.6-1.fc23.x86_64 
> libdrm-2.4.65-1.fc23.x86_64 libffi-3.1-8.fc23.x86_64 
> libgcc-5.1.1-4.fc23.x86_64 libICE-1.0.9-3.fc23.x86_64 
> libicu-54.1-5.fc23.x86_64 libpng-1.6.17-2.fc23.x86_64 
> libselinux-2.4-4.fc23.x86_64 libSM-1.2.2-3.fc23.x86_64 
> libstdc++-5.1.1-4.fc23.x86_64 libuuid-2.27.1-1.fc23.x86_64 
> libX11-1.6.3-2.fc23.x86_64 libXau-1.0.8-5.fc23.x86_64 
> libxcb-1.11.1-1.fc23.x86_64 libXcursor-1.1.14-4.fc23.x86_64 
> libXdamage-1.1.4-7.fc23.x86_64 libXext-1.3.3-3.fc23.x86_64 
> libXfixes-5.0.1-5.fc23.x86_64 libXi-1.7.4-3.fc23.x86_64 
> libXinerama-1.1.3-5.fc23.x86_64 libXrandr-1.5.0-2.fc23.x86_64 
> libXrender-0.9.9-2.fc23.x86_64 libxshmfence-1.2-2.fc23.x86_64 
> libXxf86vm-1.1.4-2.fc23.x86_64 mesa-libGL-11.0.4-1.20151105.fc23.x86_64 
> mesa-libglapi-11.0.4-1.20151105.fc23.x86_64 pcre-8.37-5.fc23.x86_64 
> qt-4.8.7-3.fc23.x86_64 qt5-qtbase-5.5.1-8.fc23.x86_64 
> qt5-qtbase-gui-5.5.1-8.fc23.x86_64 qt5-qtsvg-5.5.1-2.fc23.x86_64 
> qt-x11-4.8.7-3.fc23.x86_64 zlib-1.2.8-9.fc23.x86_64
> (gdb) bt
> #0  0x76305204 in _GLOBAL__sub_I_qprinterinfo.cpp () from 
> /lib64/libQtGui.so.4
> #1  0x77deb79a in call_init.part () from /lib64/ld-linux-x86-64.so.2
> #2  0x77deb8ab in _dl_init () from /lib64/ld-linux-x86-64.so.2
> #3  0x77ddccba in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
> #4  0x0001 in ?? ()
> #5  0x7fffe2d5 in ?? ()
> #6  0x in ?? ()
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> here's the run_cmake.sh I used
> cmake /xxx/xxx/xxx/lyx  \
> -G"Unix Makefiles"  \
> -DLYX_CPACK=OFF  \
> -DLYX_LOCALVERSIONING=OFF  \
> -DLYX_INSTALL=OFF  \
> -DLYX_NLS=ON  \
> -DLYX_REQUIRE_SPELLCHECK=OFF  \
> -DLYX_ASPELL=OFF  \
> -DLYX_ENCHANT=OFF  \
> -DLYX_HUNSPELL=OFF  \
> -DLYX_DEVEL_VERSION=OFF  \
> -DLYX_RELEASE=OFF  \
> -DLYX_DEBUG=ON  \
> -DLYX_NO_OPTIMIZE=OFF  \
> -DLYX_PACKAGE_SUFFIX=ON  \
> -DLYX_PCH=OFF  \
> -DLYX_MERGE_FILES=OFF  \
> -DLYX_MERGE_REBUILD=OFF  \
> -DLYX_QUIET=OFF  \
> -DLYX_INSTALL_PREFIX=OFF  \
> -DLYX_BUNDLE=OFF  \
> -DLYX_ENABLE_URLTESTS=OFF  \
> -DLYX_ENABLE_EXPORT_TESTS=OFF  \
> -DLYX_ASAN=OFF  \
> -DLYX_USE_QT=QT5  \
> -DLYX_PROFILE=OFF  \
> -DLYX_EXTERNAL_BOOST=OFF  \
> -DLYX_PROGRAM_SUFFIX=ON  \
> -DLYX_DEBUG_GLIBC=OFF  \
> -DLYX_DEBUG_GLIBC_PEDANTIC=OFF  \
> -DLYX_STDLIB_DEBUG=OFF  \
> -DLYX_PROFILE=OFF  \
> -DLYX_ENABLE_CXX11=OFF  \
> 
> 
> 
> 
> 
> Same thing even if I go back in time, to some 9/2015 commits I know worked.

So I think it's not related to any code change. 
Perhaps there is something wrong with the runtime linker configuration
or with your Qt5 installation.

Stephan

Re: [RFC][PATCH] Get rid of some hardcoded pixel lengths

[Jean-Marc Lasgouttes]

Le 18/11/2015 23:46, Scott Kostyshak a écrit :

Well, you can expect that the spacing is, say, half of the width of a 'm'.
So if you zoom in, the size increases.


I just did not expect this change from your patch's description since
before, Inset::TEXT_TO_INSET_OFFSET was fixed. I thought that there
would only be improvements for HiDPI.


I see what you mean. Let's say that spacing is increased like spacing 
between words is increased.


JMarc

Re: Packagers, please upload binaries for 2.2.0alpha1

[Scott Kostyshak]

On Thu, Nov 19, 2015 at 12:57:42AM +0100, Uwe Stöhr wrote:
> One last question before I upload: could you please send by email the
> MD5 sums of the files that I should upload
> 
> Ehm, just upload the installer, the 40MB file.

OK. If I get a +1 from another LyX developer I will just upload it. I am
not planning to upload .sig files for it though without an MD5 sum from
you.

>  > (so in this case it will be
> just the MD5 sum for the installer but for the final release I will also
> want the MD5 sum for the bundle)? I'm sorry for this extra step, which I
> don't think you had to do before, but I would feel much more confident
> that your upload to FTP was not corrupted and my download from your FTP
> was not corrupted.
> 
> Please don't make LyX development more complicated than necessary. I run 
> lyx.de so what is the problem?

> If my installer would contain e.g. virus aa checksum wouldn't help anyway.

Agreed.

> We never had any problem the last years so why should we now?

To protect against future problems.

> > Ideally, you would create a PGP key and you would sign the files that
> you upload.
> 
> Why should I do this? What are you afraid of? Maybe I am not educated enough 
> to understand the benefit of signing files. Please explain me.

I do not think that there is a great chance that something will go wrong
without you sending the MD5 sums. I just think that it is worth the 5
minutes (after the initial fixed cost to learn how to do it).

The benefit of signing files is so that whoever downloads the file can
be confident that it is the same file that you uploaded. Downloads and
uploads are not often corrupted as they were before, but a file is made
up of many 0's and 1's which are sent through wires. All it takes is one
electric signal to turn a 0 into a 1 and there is a corrupt
upload/download. Many software do checks that the transfer was not
corrupt, but why take this risk?

There are other benefits to .sig files, but the above is a shared
benefit between checksums and .sig files.

Scott


signature.asc
Description: PGP signature