Re: #10197: Lyx 2.2 scrambles Vector graphics (and general Layout)

[Richard Heck]

On 06/06/2016 07:18 PM, Steffen Guhlemann wrote:
> On june, first i installed Lyx2.2.

I'll second Uwe's suggestion here. It's not wise to update to a new
major version at such a critical juncture. Go back to 2.1.4 for now, at
least.

> 1. exported pdf differs. Same if you export tex(pdflatex) =>
> difference on almost each line. Don't know, if backward compatibility
> is a priority for lyx, but i (just my humble option as a user, i by no
> means want to determine, where lyx should go) would prefer to be able
> to open myx diss.lyx in 10 years (with the then current lyx and tex)
> and still be able to generate almost the same pdf i generated now.

We do strive to keep export compatiblility. I have written two books
with LyX and, like you, expect to be able to open them, etc, years from
now.

I would expect that the massive differences you are seeing with the TeX
files may be just a matter of line length.

> If you like, i can send you both pdf's for a comparison and/or the lyx
> files or the exported tex-files. You can observe the differences yourself.

I'd be happy to have a look at the LyX and TeX files. Send them privately.

> 2.  All emfs are completely scrambled. 

I'm afraid we can't control this, since we depend upon external programs
to do this kind of work, and apparently there is a nasty Inkscape bug
here. That said, you can manually remove the EMF->PDF converter at
Tools> Preferences> Converters, and then the old converters will be
used. I think. (I'm not on Windows so can't test.)

> 4.  The fonts are different - so the whole line breaks / page breaks
> are different. (You can observe this from the very first pages on -
> finally Lyx 2.2. manages the squeeze the diss into 375 pages (instead
> of 390) - this is not only due to the scrambled emfs). The former
> working tex-box including -"" as a break of dashed words now is
> spelled. I have no clue, if this is a feature - but again - if
> possible i would prefer, that the converter hard specifies the old
> default fonts, when converting an old file instead of leaving those
> settings at "default".

Maybe I can clear this up when I see the files.

>
> 5. The behaviour of "-" and tex-box: with -"" changed. To my taste, it
> changed to the good (if my first experiments are correct, that you can
> now just type M-Tree and it will be automatically  broken. But again
> backward compatibility is an issue here. What worked (but was a
> workaround) in 2.1.4. now produces ugly crap: M-""Tree - it will be a
> lot of fun to find all some 1'000 places in the diss where this is used.

Unfortunately, what you do in TeX boxes isn't something LyX can predict
or do anything about. Hence the old name "Evil Red Text".

If you open the LyX file in a simple text editor, you can probably do a
search and replace to fix all this.

Richard

Re: #10197: Lyx 2.2 scrambles Vector graphics (and general Layout)

[Uwe Stöhr]

Am 07.06.2016 um 01:18 schrieb Steffen Guhlemann:


sorry for the mixup of issues,


Please separate the different issues into different bug reports and 
mailing list threads. otherwise we won#t be able to have a structured 
discussion.



For background: In the last days i was finalizing my phd thesis...


Sorry, but why do you update unnecessarily a software for such an 
important document? My personal strong advice: go back to LyX 2.1.4 and 
finish your thesis with it. After you finished it you can still play 
around with LyX 2.2.0.
If you are suffering from bugs you might update to LyX 2.1.5 (will be 
released this week) that is 2.1.4 plus bugfixes.


For the image handling please follow my advices in the bug tracker. In 
general avoid EMF - this has the typical Microsoft problem: it looks 
different on every PC and moreover many programs are not able to handle 
this format. There is also no reason to use it since you can convert it 
to a PDF (or SVG).


> The fonts are different

The example file you sent uses LaTeX' default fonts since you have not 
loaded any special font nor any special preamble code regarding fonts. 
Thus please check your LaTeX installation or attach a _SMALL_ LyX 
example file with your real font settings to a new bug report


regards Uwe

[PATCH] Inserting references to label

[Richard Heck]

On 06/06/2016 04:57 AM, Mario D wrote:
> After opening the dialog box to insert a reference to a label, when  a
> label is chosen there is a button  "Go to label" in order to check
> whether  the label is really the correct one. Good.
> After having hit this button, it is replaced with "Go back", so that I
> can get to the original point after having checked the label. Ok.
>
> The only drawback, in this, is that when I am back to the original
> point the label I checked is no longer selected, so that now I know
> whether it was the right one or not but, possibly, I don't remember
> its name...  :(
>
> Am I doing something wrong?

No, this is definitely a shortcoming. The attached patch fixes this
behavior, but it seems like a bit of a hack.

Anyone have a better idea? I could introduce a new variable for this
purpose, but that seems like overkill.

Richard

>From 302e23844b15b18d1cb0bb503ba45c4e895d973e Mon Sep 17 00:00:00 2001
From: Richard Heck 
Date: Mon, 6 Jun 2016 19:36:27 -0400
Subject: [PATCH] Restore last selected label when using the "go to label"
 feature of the reference dialog.

---
 src/frontends/qt4/GuiRef.cpp | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/frontends/qt4/GuiRef.cpp b/src/frontends/qt4/GuiRef.cpp
index 1150d58..85e3553 100644
--- a/src/frontends/qt4/GuiRef.cpp
+++ b/src/frontends/qt4/GuiRef.cpp
@@ -114,7 +114,9 @@ void GuiRef::changed_adaptor()
 
 void GuiRef::gotoClicked()
 {
+	last_reference_ = referenceED->text();
 	gotoRef();
+	last_reference_.clear();
 }
 
 
@@ -417,19 +419,18 @@ void GuiRef::redoRefs()
 		refsTW->addTopLevelItems(refsItems);
 	}
 
-	referenceED->setText(oldSelection);
-
 	// restore the last selection or, for new insets, highlight
 	// the previous selection
 	if (!oldSelection.isEmpty() || !last_reference_.isEmpty()) {
 		bool const newInset = oldSelection.isEmpty();
 		QString textToFind = newInset ? last_reference_ : oldSelection;
+		referenceED->setText(textToFind);
 		last_reference_.clear();
 		QTreeWidgetItemIterator it(refsTW);
 		while (*it) {
 			if ((*it)->text(0) == textToFind) {
 refsTW->setCurrentItem(*it);
-refsTW->setItemSelected(*it, !newInset);
+refsTW->setItemSelected(*it, true);
 //Make sure selected item is visible
 refsTW->scrollToItem(*it);
 last_reference_ = textToFind;
-- 
2.1.0

Re: Tarballs for LyX 2.2.0 are on FTP

[Guillaume Munch]

Le 07/06/2016 00:00, Richard Heck a écrit :

On 06/06/2016 06:40 PM, Guillaume Munch wrote:


The point of the proposal is to enabling the early testing and release
of *non-file-format* changes. Then for a proper master release only
file-format changes remain to be fully tested.


This assumes these aspects do not interact. Oftentimes, they do.

Our use of git would make it very easy for us to have a branch in which
new features not requiring format changes could also be put.



This solution would be fine by me too, if people agree to have three
branches.

RE: #10197: Lyx 2.2 scrambles Vector graphics (and general Layout)

[Steffen Guhlemann]

Hi,
sorry for the mixup of issues, but some of the things here definitely are bugs. 
And the behaviour definitely changed. Independend of this - i really like Lyx 
and appreciate your work a lot.
For background: In the last days i was finalizing my phd thesis. During this 
time i was using LyX 2.1.4 very frequently to polish last thinks. Before - and 
even regularly in between i updated my miktex repository. I managed to get an 
PDF/A-2b using the pdfx-package (with a lot of help and hacks of one of the 
maintainers - since this was not easy using lyx, as pdfx wants to be included 
as the very first package - and lyx places a lot of generic stuff in front of 
the user defined latex header. Finally it worked - i got an almost polished, 
390 page PDF/A-2b as veryfied by Adobe Preflight.  (Created on 30th of may 2016 
using the then latest version of miktex - at most it was a week old or so.)
On june, first i installed Lyx2.2. (this also triggered miktex update - not 
sure, whether this found something - in any case it was nothing big.) When i 
opened my diss using Lyx2.2 for the first time, it converted  the file to the 
new lyx2.2 format and created a backup copy. When compiling this for the first 
time using Lyx2.2 the result was/is a mess. The pdfs are clearly different in 
many aspects. I really have no clue, what of this is a feature and what is a 
bug, but for me it means i have to redo the polish of the last weeks from the 
scratch and i can never deliver the same version my profs saw.Can you tell me, 
what of this is a feature (which by intend or uncontiously broke backward 
compatibility) and what is a bug?
On a first glance i saw the following differences:1. exported pdf differs. Same 
if you export tex(pdflatex) => difference on almost each line. Don't know, if 
backward compatibility is a priority for lyx, but i (just my humble option as a 
user, i by no means want to determine, where lyx should go) would prefer to be 
able to open myx diss.lyx in 10 years (with the then current lyx and tex) and 
still be able to generate almost the same pdf i generated now. 
If you like, i can send you both pdf's for a comparison and/or the lyx files or 
the exported tex-files. You can observe the differences yourself.
2.  All emfs are completely scrambled. This is not a minor glitch of a new 
exporter - this is completely broken. (I could reproduce this using inkscape 
0.91. Just opening the file moves all text on top of each other into the 
topleft, saving it as pdf also destroys the lines.) The resulting images have 
nothing in common with the original picture. In the long run it might be better 
to follow your advise and transform those images to pdf, but for me this is no 
option. I have >100 emf picures. Transforming them all would take a while - and 
worse - the resulting change in image size would destroy all layout - i would 
have to fiddle with each single image again. Further - again my humble opion - 
not sure how much it counts in the big context: Lyx for me is a kind of 
convinience latex. And convinience means, i can concentrate on the content of 
my work and not the way i put "s. Picture handling is also about convinience - 
i create pictures the way that works best for me, and directly use them in lyx 
- without fiddeling how to convert them to a format usable by latex. And - 
worse - do this over and over and over as i need to slighly modify/change my 
drawings during content work. So i liked the feature of emf-support and would 
not like to have to convert everything manually.
2. The svgs differ only slightly, but they do differ. Here i am not sure, 
whether this is a bug or a feature - and - if it is a feature, whether backward 
compatibiliy was possible at all. For me the svg-handling in 2.1.4. worked - so 
the "fix" of 2.2. destroyed something. It is only minor stuff, but some 
patterns disappeared in Lyx 2.2 which were present in Lyx 2.1.4. and in the 
actual picture.
3. scaling interpretation of all vector graphics changed (svg a bit and emf a 
lot). For me (again only my humble opinion) this has up- and downsides. 
Positive: It is way more intuitive now - what was a single powerpoint page now 
is only a page wide (and not 10) - so it can be scaled to 100% instead of 5%. 
As you read - i always used the first graphics scaling option and was not 
aware, that you could also scale relative to the page width. Good to know, but 
no option for me now, as there are >100 images, and rescaling them all will 
mess all the line and page breaks.Negative: again - backward compatibiliy. I 
prefer to open a document i have worked on for quite some time, and still see 
the results in 10 years with the then current lyx version (or even now in lyx 
2.2). This is not possible, if my setting i did in lyx 2.1.4 (and which worked 
there) now leed to all graphics beeing invisbly small in Lyx 2.2. (in the 
preview and the final output). This could be handled in the program, which 
converts the old file format 

Re: Tarballs for LyX 2.2.0 are on FTP

[Richard Heck]

On 06/06/2016 06:40 PM, Guillaume Munch wrote:
>
> The point of the proposal is to enabling the early testing and release
> of *non-file-format* changes. Then for a proper master release only
> file-format changes remain to be fully tested.

This assumes these aspects do not interact. Oftentimes, they do.

Our use of git would make it very easy for us to have a branch in which
new features not requiring format changes could also be put.

Richard

Re: Tarballs for LyX 2.2.0 are on FTP

[Richard Heck]

On 06/06/2016 06:10 PM, Andrew Parsloe wrote:
> On 7/06/2016 9:50 a.m., Richard Heck wrote:
>> On 06/06/2016 03:33 PM, Georg Baum wrote:
>>> Jean-Marc Lasgouttes wrote:
>>>
 Le 05/06/2016 à 21:05, Guillaume Munch a écrit :
> Yet, most of the file format changes are very simple. I wonder
> whether
> one could introduce a single compilation variable to disable them,
> and ask developers to enclose file-format-specific code between the
> corresponding #ifdefs. (For instance in my last file format change
> all
> that was needed to be enclosed was the parsing code.) This would
> allow
> the release of "master versions without file format changes",
> either as
> nightlies or as official "x.5" versions as Pavel suggested by
> Pavel in
> another message (without having to maintain three branches in
> parallel).
 This looks too complicated to me. And eventually there will be
 changes that cannot be treated like that, and all the previous work
 on small changes will be useless.

 Note that that stable nightlies could be updated with lyx2lyx code
 for new master versions in parallel with master.
>>> Or we could add a mode that calls lyx2lyx automatically after
>>> saving, so that effectively the master version would use the old
>>> file format. This would probably work fine as long as no new
>>> features are used.
>> Yes, but do we want to warn people then not to use new features? I think
>> it would just confuse people for us to tell them to test master but not
>> to use some new features if they want to be able to go back to stable.
>>
>> Richard
>>
> As a potential user-tester I've followed this discussion with
> interest. I can't imagine downloading and installing LyX daily, but I
> can imagine doing this each month and using the resulting installation
> as my working LyX (as I did for the alphas and betas of 2.2.0),
> therefore with all features turned on and potential unreadability in
> earlier versions.

And you can always export to 2.2.x format, in the usual way.

rh

Re: Tarballs for LyX 2.2.0 are on FTP

[Guillaume Munch]

Le 06/06/2016 22:47, Richard Heck a écrit :

On 06/06/2016 04:27 PM, Guillaume Munch wrote:

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

Jean-Marc Lasgouttes wrote:


Le 05/06/2016 à 21:05, Guillaume Munch a écrit :

Yet, most of the file format changes are very simple. I wonder
whether one could introduce a single compilation variable to
disable them, and ask developers to enclose file-format-specific
code between the corresponding #ifdefs. (For instance in my last
file format change all that was needed to be enclosed was the
parsing code.) This would allow the release of "master versions
without file format changes", either as nightlies or as official
"x.5" versions as Pavel suggested by Pavel in another message
(without having to maintain three branches in parallel).


This looks too complicated to me. And eventually there will be
changes that cannot be treated like that, and all the previous
work on small changes will be useless.


The current workflow of testing master all at once before a release
has proven to be too complicated. Notice that only the input and output
of the features has to be treated with #ifdefs, not the whole changed
code. Do you have a particular example situation in mind which would be
too difficult?


The problem, as I'll elaborate below, is that the new features can't be
pulled
apart from the changed input and output (when that changes).


As far as I know the biggest file format change for 2.2 was Enrico's
work on separators. On the looks of it, preserving the previous format
with a switch was entirely doable (see c668ebf6).


I don't see how this would be possible. The new code introduces a separator
inset. There is no longer any separator style. I can imagine writing the
old layout
to a file and then having the document open properly in 2.1.x, but then
it will not
have opened properly in 2.2.x (i.e., master).


Yes, one would need to use the old layouts and therefore keep them in a 
backup dir.




The problem is even more serious with new types of inset, say. I have been
thinking about adding a proper endnote inset (to deal with some XHTML
issues).
Is the proposal just not to write it to the file? Or to disable the
feature entirely?


Yes, with disabling the input, I also meant disabling the ways to
introduce them in the interface. New Lfuns can be disabled with an early
return, and changed ones keep the old code in the #else branch.


Then it does not get tested.


The point of the proposal is to enabling the early testing and release
of *non-file-format* changes. Then for a proper master release only
file-format changes remain to be fully tested.

Re: Tarballs for LyX 2.2.0 are on FTP

[Andrew Parsloe]

On 7/06/2016 9:50 a.m., Richard Heck wrote:

On 06/06/2016 03:33 PM, Georg Baum wrote:

Jean-Marc Lasgouttes wrote:


Le 05/06/2016 à 21:05, Guillaume Munch a écrit :

Yet, most of the file format changes are very simple. I wonder whether
one could introduce a single compilation variable to disable them,
and ask developers to enclose file-format-specific code between the
corresponding #ifdefs. (For instance in my last file format change all
that was needed to be enclosed was the parsing code.) This would allow
the release of "master versions without file format changes", either as
nightlies or as official "x.5" versions as Pavel suggested by Pavel in
another message (without having to maintain three branches in parallel).

This looks too complicated to me. And eventually there will be changes that 
cannot be treated like that, and all the previous work on small changes will be 
useless.

Note that that stable nightlies could be updated with lyx2lyx code for new 
master versions in parallel with master.

Or we could add a mode that calls lyx2lyx automatically after saving, so that 
effectively the master version would use the old file format. This would 
probably work fine as long as no new features are used.

Yes, but do we want to warn people then not to use new features? I think
it would just confuse people for us to tell them to test master but not
to use some new features if they want to be able to go back to stable.

Richard

As a potential user-tester I've followed this discussion with interest. 
I can't imagine downloading and installing LyX daily, but I can imagine 
doing this each month and using the resulting installation as my working 
LyX (as I did for the alphas and betas of 2.2.0), therefore with all 
features turned on and potential unreadability in earlier versions.


Andrew

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

Re: [LyX/master] glitch in lfundoc

[Andrew Parsloe]

On 7/06/2016 7:31 a.m., Pavel Sanda wrote:

Jürgen Spitzmüller wrote:

So, am I supposed to do something?

I'd say if you know few liner patch, then fix it.
If it needs lot of work it might not be worth the effort,
these lfuns might be used by devs but never users
so it depends who are we targeting by lfuns.lyx.

Pavel


But I would love to know what they are.

Andrew


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

Re: Tarballs for LyX 2.2.0 are on FTP

[Richard Heck]

On 06/06/2016 03:33 PM, Georg Baum wrote:
> Jean-Marc Lasgouttes wrote:
>
>> Le 05/06/2016 à 21:05, Guillaume Munch a écrit :
>>> Yet, most of the file format changes are very simple. I wonder whether
>>> one could introduce a single compilation variable to disable them,
>>> and ask developers to enclose file-format-specific code between the
>>> corresponding #ifdefs. (For instance in my last file format change all
>>> that was needed to be enclosed was the parsing code.) This would allow
>>> the release of "master versions without file format changes", either as
>>> nightlies or as official "x.5" versions as Pavel suggested by Pavel in
>>> another message (without having to maintain three branches in parallel).
>> This looks too complicated to me. And eventually there will be changes that 
>> cannot be treated like that, and all the previous work on small changes will 
>> be useless.
>>
>> Note that that stable nightlies could be updated with lyx2lyx code for new 
>> master versions in parallel with master.
> Or we could add a mode that calls lyx2lyx automatically after saving, so that 
> effectively the master version would use the old file format. This would 
> probably work fine as long as no new features are used.

Yes, but do we want to warn people then not to use new features? I think
it would just confuse people for us to tell them to test master but not
to use some new features if they want to be able to go back to stable.

Richard

Re: Tarballs for LyX 2.2.0 are on FTP

[Richard Heck]

On 06/06/2016 04:27 PM, Guillaume Munch wrote:
> Le 06/06/2016 20:33, Georg Baum a écrit :
>> Jean-Marc Lasgouttes wrote:
>>
>>> Le 05/06/2016 à 21:05, Guillaume Munch a écrit :
 Yet, most of the file format changes are very simple. I wonder
 whether one could introduce a single compilation variable to
 disable them, and ask developers to enclose file-format-specific
 code between the corresponding #ifdefs. (For instance in my last
 file format change all that was needed to be enclosed was the
 parsing code.) This would allow the release of "master versions
 without file format changes", either as nightlies or as official
 "x.5" versions as Pavel suggested by Pavel in another message
 (without having to maintain three branches in parallel).
>>>
>>> This looks too complicated to me. And eventually there will be
>>> changes that cannot be treated like that, and all the previous
>>> work on small changes will be useless.
>
> The current workflow of testing master all at once before a release
> has proven to be too complicated. Notice that only the input and output
> of the features has to be treated with #ifdefs, not the whole changed
> code. Do you have a particular example situation in mind which would be
> too difficult?

The problem, as I'll elaborate below, is that the new features can't be
pulled
apart from the changed input and output (when that changes).

> As far as I know the biggest file format change for 2.2 was Enrico's
> work on separators. On the looks of it, preserving the previous format
> with a switch was entirely doable (see c668ebf6).

I don't see how this would be possible. The new code introduces a separator
inset. There is no longer any separator style. I can imagine writing the
old layout
to a file and then having the document open properly in 2.1.x, but then
it will not
have opened properly in 2.2.x (i.e., master).

The problem is even more serious with new types of inset, say. I have been
thinking about adding a proper endnote inset (to deal with some XHTML
issues).
Is the proposal just not to write it to the file? Or to disable the
feature entirely?
Then it does not get tested.

There are lots of cases like that one, such as Uwe's various additions
to the box
dialog.

Richard

Re: boost:regex & gcc

[Pavel Sanda]

Guillaume Munch wrote:
> Any reason to want to get rid of boost completely?

Well, that's a long term wish. It is not nice to pack boost lib together with
our sources and someone need to care updating boost within the source tree.

Pavel

Re: boost:regex & gcc

[Guillaume Munch]

Le 06/06/2016 20:37, Pavel Sanda a écrit :

Guillaume Munch wrote:

11. boost:regex. We have learnt the pitfalls of having two regex
libraries at the same time. However, according to a comment in the
source, gcc < 4.9.0 supports std::regex badly. Do we still care
about gcc < 4.9.0 ? (no hurry, and the patch is trivial)


I think that requesting gcc >= 4.9.0 dep is little bit rushy.



Hopefully it will not be a problem to keep boost::regex for a while now
that we have understood what special care it needs.




If we agreed on all your points, how far we are from complete
indepedence of boost?

Pavel



The diff is as follows:

--- a/3rdparty/boost/extract.sh
+++ b/3rdparty/boost/extract.sh
@@ -22,20 +22,11 @@ mkdir needed
 bcp --boost=$1 \
 boost/any.hpp \
 boost/assert.hpp \
-boost/bind.hpp \
 boost/crc.hpp \
-boost/cstdint.hpp \
-boost/function.hpp \
-boost/functional.hpp \
 boost/lexical_cast.hpp \
-boost/noncopyable.hpp \
-boost/regex.hpp \
-boost/scoped_ptr.hpp \
-boost/shared_ptr.hpp \
 boost/signal.hpp \
 boost/signals/connection.hpp \
 boost/signals/trackable.hpp \
-boost/tuple/tuple.hpp \
 \
 needed


None of the ones that remain looked straightforward to replace. Another
factor is that the libraries that are redundant with c++11 are likely to
receive less and less attention from their developers.

Any reason to want to get rid of boost completely?

Re: Tarballs for LyX 2.2.0 are on FTP

[Guillaume Munch]

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

Jean-Marc Lasgouttes wrote:


Le 05/06/2016 à 21:05, Guillaume Munch a écrit :

Yet, most of the file format changes are very simple. I wonder
whether one could introduce a single compilation variable to
disable them, and ask developers to enclose file-format-specific
code between the corresponding #ifdefs. (For instance in my last
file format change all that was needed to be enclosed was the
parsing code.) This would allow the release of "master versions
without file format changes", either as nightlies or as official
"x.5" versions as Pavel suggested by Pavel in another message
(without having to maintain three branches in parallel).


This looks too complicated to me. And eventually there will be
changes that cannot be treated like that, and all the previous
work on small changes will be useless.


The current workflow of testing master all at once before a release
has proven to be too complicated. Notice that only the input and output
of the features has to be treated with #ifdefs, not the whole changed
code. Do you have a particular example situation in mind which would be
too difficult?

As far as I know the biggest file format change for 2.2 was Enrico's
work on separators. On the looks of it, preserving the previous format
with a switch was entirely doable (see c668ebf6).



Note that that stable nightlies could be updated with lyx2lyx code
for new master versions in parallel with master.




lyx2lyx is not meant to be back and forth, and this still locks us into
the nightlies, so, this is no enough to convince me to use dailies.

In fact, to take my previous example again, it would not have been
possible to rely on lyx2lyx since it was explicitly made non roundtrip
(c668ebf6). Moreover getting lyx2lyx right is more tricky because it
seems to rely more on trial-and-error (cda00d832).



Or we could add a mode that calls lyx2lyx automatically after
saving, so that effectively the master version would use the old file
format. This would probably work fine as long as no new features are
used.



Then, do we have to still include a switch to disable the use of these
new features?

Re: [PATCH] unique_ptr and some clean-up

[Georg Baum]

Guillaume Munch wrote:

> Le 05/06/2016 12:54, Georg Baum a écrit :
>> Therefore I would vote to support MSVC 2013 and later, but nothing
>> earlier.
> 
> In light of the lack of support of unicode string literals in MSVC 2013,
> the availability of mingw and the fact that a last-minute switch to MSVC
> 2015 was already necessary for the release of lyx 2.2, I vote for
> supporting MSVC >= 2015.

Fine with me as well. I took 2013 because I did not want to diverge too far 
from your proposal;-)

>> Concerning the order of committing, I would first change the
>> --disable-cxx11 switch to --disable-cxx14, so that we do not loose
>> the infrastructure, and remove all code that is inside #ifndef
>> LYX_USE_CXX11. Afterwards, we can gradually introduce more C++11
>> features like unique_ptr. I can do the configure stuff if you like
>> btw.
> 
> Yes, please do this.

It turned out that it was too difficult to retain the stuff for some 
hypothetical future C++14 checks. I will commit the attached unless nobody 
objects. This is simply the unconditional use of C++11. After this patch it 
would be possible to get rid of parts of the included boost already.


Georg
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 8425716..104878b 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -142,7 +142,6 @@ LYX_OPTION(ENABLE_EXPORT_TESTS "Enable for export tests" OFF ALL)
 LYX_OPTION(ASAN "Use address sanitizer" OFF ALL)
 LYX_COMBO(USE_QT"Use Qt version as frontend" QT4 QT5)
 LYX_OPTION(3RDPARTY_BUILD   "Build 3rdparty libs" OFF ALL)
-LYX_COMBO(ENABLE_CXX11  "Build with options for c++11-mode" AUTO ON OFF)
 
 # GCC specific
 LYX_OPTION(PROFILE  "Build profile version" OFF GCC)
@@ -254,24 +253,10 @@ else()
 endif()
 
 
-if(LYX_ENABLE_CXX11 MATCHES "AUTO")
-  # Set to some meaningful default
-  find_package(CXX11Compiler)
-  if(NOT CXX11COMPILER_FOUND)
-set(LYX_ENABLE_CXX11 OFF CACHE TYPE STRING FORCE)
-  else()
-if(CMAKE_CXX_COMPILER_ID MATCHES "GNU")
-  execute_process(COMMAND ${CMAKE_CXX_COMPILER} -dumpversion OUTPUT_VARIABLE GCC_VERSION OUTPUT_STRIP_TRAILING_WHITESPACE)
-set(LYX_ENABLE_CXX11 ON CACHE TYPE STRING FORCE)
-else()
-  # Not a gnu compiler
-  if(CMAKE_CXX_COMPILER_ID MATCHES "^[cC]lang$")
-set(LYX_ENABLE_CXX11 ON CACHE TYPE STRING FORCE)
-  else()
-set(LYX_ENABLE_CXX11 OFF CACHE TYPE STRING FORCE)
-  endif()
-endif()
-  endif()
+# Set to some meaningful default
+find_package(CXX11Compiler)
+if(NOT CXX11COMPILER_FOUND)
+	message(FATAL_ERROR "A C++11 compatible compiler is required.")
 endif()
 set(LYX_GCC11_MODE)
 if(UNIX OR MINGW)
@@ -285,17 +270,9 @@ if(UNIX OR MINGW)
 		# see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631
 		set(LYX_USE_STD_REGEX 0)
 	else()
-		if (LYX_ENABLE_CXX11)
-			set(LYX_USE_STD_REGEX 1)
-		endif()
-	endif()
-	if (LYX_ENABLE_CXX11)
-		find_package(CXX11Compiler)
-		if(NOT CXX11COMPILER_FOUND)
-			message(FATAL_ERROR "A C++11 compatible compiler is required.")
-		endif()
-		set(LYX_GCC11_MODE "${CXX11_FLAG}")
+		set(LYX_USE_STD_REGEX 1)
 	endif()
+	set(LYX_GCC11_MODE "${CXX11_FLAG}")
 else()
 	set(LYX_USE_STD_REGEX 0)
 #	if(MSVC10)
diff --git a/config/lyxinclude.m4 b/config/lyxinclude.m4
index 9ba8a87..f6eeae3 100644
--- a/config/lyxinclude.m4
+++ b/config/lyxinclude.m4
@@ -146,30 +146,7 @@ AC_DEFUN([LYX_PROG_CLANG],
 ])
 
 
-dnl Usage: LYX_CXX_CXX11: set lyx_use_cxx11 to yes if the compiler implements
-dnl the C++11 standard.
-AC_DEFUN([LYX_CXX_CXX11],
-[AC_CACHE_CHECK([whether the compiler implements C++11],
-   [lyx_cv_cxx_cxx11],
- [save_CPPFLAGS=$CPPFLAGS
-  CPPFLAGS="$AM_CPPFLAGS $CPPFLAGS"
-  save_CXXFLAGS=$CXXFLAGS
-  CXXFLAGS="$AM_CXXFLAGS $CXXFLAGS"
-  AC_LANG_PUSH(C++)
-  AC_TRY_COMPILE([], [
-#if __cplusplus >= 201103L || defined(__GXX_EXPERIMENTAL_CXX0X__)
-	this is a c++11 compiler
-#endif
-  ],
-  [lyx_cv_cxx_cxx11=no], [lyx_cv_cxx_cxx11=yes ; lyx_flags="$lyx_flags c++11"])
- AC_LANG_POP(C++)
- CXXFLAGS=$save_CXXFLAGS
- CPPFLAGS=$save_CPPFLAGS])
- lyx_use_cxx11=$lyx_cv_cxx_cxx11
-])
-
-
-dnl Usage: LYX_CXX_USE_REGEX(cxx11_flags)
+dnl Usage: LYX_CXX_USE_REGEX(cxxstd_flags)
 dnl decide whether we want to use std::regex and set the
 dnl LYX_USE_STD_REGEX accordingly.
 dnl the extra cxx11 flags have to be passed to the preprocessor. They are
@@ -177,7 +154,6 @@ dnl not plainly added to AM_CPPFLAGS because then the objc compiler (mac)
 dnl would fail.
 AC_DEFUN([LYX_CXX_USE_REGEX],
 [lyx_std_regex=no
- if test $lyx_use_cxx11 = yes; then
save_CPPFLAGS=$CPPFLAGS
# we want to pass -std=c++11 to clang/cpp if necessary
CPPFLAGS="$AM_CPPFLAGS $1 $CPPFLAGS"
@@ -200,7 +176,6 @@ AC_DEFUN([LYX_CXX_USE_REGEX],
  fi
fi
AC_MSG_RESULT([$lyx_std_regex])
- fi
 
  if test $lyx_std_regex = yes ; then
   lyx_flags="$lyx_flags std-regex"
@@ -298,10 +273,6 @@ case $enable_optimization in
 *) lyx_optim=${enable_optimization};;
 esac
 

Re: [PATCH] unique_ptr and some clean-up

[Jean-Marc Lasgouttes]

Le 06/06/16 à 21:04, Guillaume Munch a écrit :

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

Le 05/06/2016 à 13:54, Georg Baum a écrit :

Looks good, I have only one minor comment: Please do not use _MSC_VER
in the
sources. This code is better located in config.h, like that:

#if (__cplusplus >= 201402L) || (defined(_MSC_VER)&&(_MSC_VER>=1800))
// C++14, MSVC >= 2013
#define HAVE_STD_MAKE_UNIQUE
#endif


What about testing for std::make_unique instead?



You mean during configure?


Yes. If we want, say, to be ale to compile for some intel compiler, it 
is better.


JMarc

Re: [patch] Fix lyx-2.3dev build failure in FreeBSD

[Pavel Sanda]

On Sat, May 07, 2016 at 06:45:26AM +0200, Shankar Giri Venkita Giri wrote:
> There are basically two issues on FreeBSD.
>  
> Issue #1. Standard Includes and Libs are in /usr/local/include and /
> usr/local/lib unline Linux variants. --with-extra-prefix=/usr/local
> solves this problem. FreeBSD Ports build system exports LOCALBASE to
> /usr/local and so this problem does not occur when building from
> ports. When building from source directly, --with-extra-prefix is
> necessary
> Issue #2. -lexecinfo is needed for backtrace() on FreeBSD (https://
> github.com/pelegm/google-glog/issues/214) - Patch attached.

Since you tested it, I think patch for #2 should go in to both master/branch.

> 1. Other BSDs certainly should have Issue #1, but probably need to
> check with other NetBSD, OpenBSD, DragonflyBSD users for Issue #2.
> Then the patch can be generalized to *BSD*.

Agreed, but this is really their call, I don't think any active
dev is currently running NetBSD, OpenBSD, DragonflyBSD to test that.

> 2. Do we patch code for Issue #1 or just add README.BSD and document
> the --with-extra-prefix=/usr/local argument?

If you can produce nice enough patch, we will include it.
Otherwise I would include it into RELEASE-NOTES, section with Known issues.

> 3. We can either patch in LyX or just ignore it and file a ticket in
> the FreeBSD ports system so that they add the patch in their build
> process. I prefer LyX to compile independent of build systems
> applying patches during building (that allows working and compiling
> git code directly), but its the community's call.

Agreed, but we rely on you to helps us with it.

Pavel

Re: mingw not compilable ATM

[Kornel Benko]

Am Montag, 6. Juni 2016 um 20:51:40, schrieb Georg Baum 

> Kornel Benko wrote:
> 
> > Trying to compile with 'development/cmake/scripts/xmingw' I get
> > ...
> > [ 24%] Building CXX object
> > [ src/frontends/qt4/CMakeFiles/frontend_qt.dir/_allinone_const.C.obj
> > cd /usr/BUILD/mingw/src/frontends/qt4 && /usr/bin/i686-w64-mingw32-g++  
> > -DBOOST_SIGNALS_NO_DEPRECATION_WARNING=1 -DHUNSPELL_STATIC
> > -DLYX_BUILD_QT_FRONTEND -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_GENUINE_STR
> > -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_SVG_LIB -DQT_WIDGETS_LIB
> > -DQT_WINEXTRAS_LIB -DWINVER=0x0500
> > @CMakeFiles/frontend_qt.dir/includes_CXX.rsp -Wall -Wunused-parameter
> > --std=c++11 -fno-strict-aliasing  -Wall -Wunused-parameter --std=c++11 -O2
> > -DNDEBUG   -DBOOST_USER_CONFIG="" -o
> > CMakeFiles/frontend_qt.dir/_allinone_const.C.obj -c
> > /usr/BUILD/mingw/src/frontends/qt4/_allinone_const.C In file included from
> > /usr/BUILD/mingw/src/frontends/qt4/_allinone_const.C:358:0:
> > /usr2/src/lyx/lyx-git/src/frontends/qt4/GuiApplication.cpp:127:21: fatal
> > error: xcb/xcb.h: No such file or directory
> >  #include 
> >  ^
> > compilation terminated. This is the same for master _and_ 2.2.x.
> 
> Looks like the wrong qt headers are picked up (from the host system). 
> QPA_XCB is only supposed to be defined on linux. I do not have this problem 
> with autotools and an explicitly set qtdir via --with-qt-dir=. Probably the 
> implicit qt configuratian via PATH in xmingw does not work anymore, and you 
> need to give an explicit qt dir.
> 

Looking into the xmingw script, there is qt5.5.1 used. And I was using Qt5.6.
Switching to 5.5.1 ...
Same problem, and because the qt-version is explicitly downloaded and used, I 
would not expect
a change.

And I am sure, I compiled it in the past.

> Georg

Kornel

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

boost:regex & gcc (was: [PATCH] unique_ptr and some clean-up)

[Pavel Sanda]

Guillaume Munch wrote:
> 11. boost:regex. We have learnt the pitfalls of having two regex
> libraries at the same time. However, according to a comment in the
> source, gcc < 4.9.0 supports std::regex badly. Do we still care about
> gcc < 4.9.0 ? (no hurry, and the patch is trivial)

I think that requesting gcc >= 4.9.0 dep is little bit rushy.

If we agreed on all your points, how far we are from complete
indepedence of boost?

Pavel

Re: Tarballs for LyX 2.2.0 are on FTP

[Georg Baum]

Jean-Marc Lasgouttes wrote:

> Le 05/06/2016 à 21:05, Guillaume Munch a écrit :
>> Yet, most of the file format changes are very simple. I wonder whether
>> one could introduce a single compilation variable to disable them,
>> and ask developers to enclose file-format-specific code between the
>> corresponding #ifdefs. (For instance in my last file format change all
>> that was needed to be enclosed was the parsing code.) This would allow
>> the release of "master versions without file format changes", either as
>> nightlies or as official "x.5" versions as Pavel suggested by Pavel in
>> another message (without having to maintain three branches in parallel).
> 
> This looks too complicated to me. And eventually there will be changes
> that cannot be treated like that, and all the previous work on small
> changes will be useless.
> 
> Note that that stable nightlies could be updated with lyx2lyx code for
> new master versions in parallel with master.

Or we could add a mode that calls lyx2lyx automatically after saving, so 
that effectively the master version would use the old file format. This 
would probably work fine as long as no new features are used.


Georg

Re: [LyX/master] glitch in lfundoc

[Pavel Sanda]

Jürgen Spitzmüller wrote:
> So, am I supposed to do something?

I'd say if you know few liner patch, then fix it.
If it needs lot of work it might not be worth the effort,
these lfuns might be used by devs but never users
so it depends who are we targeting by lfuns.lyx.

Pavel

Re: Tarballs for LyX 2.2.0 are on FTP

[Georg Baum]

Liviu Andronic wrote:

> We already have nightly builds for Ubuntu Linux:
> https://launchpad.net/~lyx-devel/+archive/ubuntu/daily
> 
> It's been running for couple of years (probably all through the 2.2
> development cycle), though I'm not sure it's made much of an impact in
> terms of testing and bug reports. (I still have to update the
> packaging arrangements for 2.3dev, but it should be up and running
> "soon".)

Yes, I forgot to mention that. As we see from user feedback ("which version 
do you use?" "The one from the PPA") this is very valuable, so thank you 
very much for doing that!


Georg

Re: One official build system?

[Kornel Benko]

Am Montag, 6. Juni 2016 um 20:53:47, schrieb Georg Baum 

> Kornel Benko wrote:
> 
> > Version suffix for bin and locales is already used as expected.
> 
> Very good.
> 
> > I think, there is nothing to do for windows yet, because it uses already
> > cmake.
> 
> OK (I was not sure whether the changes for linux would imply changews for 
> windows as well).
> 

I am not sure either. Have tried to not change anything for windows. But, as I 
know myself,
some bugs may well find their way ...

> Georg

Kornel

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

Re: Tarballs for LyX 2.2.0 are on FTP

[Georg Baum]

Sorry for the late reply, I somehow missed this message.


Jean-Marc Lasgouttes wrote:

> Le 31/05/2016 à 22:26, Georg Baum a écrit :
>> We need to decide: Either have a fixed schedule, and an unknown feature
>> set of the next release, or a fixed feature set, and an unknown schedule.
>> We do not have enough man power for defining both a fixed feature set and
>> a fixed release schedule.
> 
> I prefer the fixed schedule. We never know exactly when starting a
> release cycle what features will happen or not. But we can enforce when
> the release will happen.

Makes sense.

>> - Have a build server that does automatic builds on a regular basis for
>> all three platforms (Linux, OS X, windows) and makes binary packages and
>> build logs available.
> 
> Do you have a particular service in mind? I agree that this would be
> nifty.

No, I have not yet searched, but I am convinced that it pays off to invest 
some time into that. If we had it for 2.2.0 it could have saved a lot of 
work and unneeded discussions.

>> - (not related to automation) Disentangle unrelated stuff from the
>> release. For example, the current way of updating the documentation is
>> inefficient. In agile software development you write the documentation of
>> a new feature almost at the same time as you implement the fetaure (this
>> is one of the good aspects of agile software development). If we do that
>> as well we can get rid of a noticeable delay at release time.
> 
> The problem is that we are not very good at writing documentation and we
> let Uwe do all this. If he had a small team of documenters to help, life
> would be much easier.

I am not sure whether we are not good at writing docs. We should simply try 
how far we get if we encourage everybody to document his new features.


Georg

Re: One official build system?

[Kornel Benko]

Am Montag, 6. Juni 2016 um 21:03:05, schrieb Georg Baum 

> Kornel Benko wrote:
> 
> > Don't know if this helps, but I never use relative path with cmake.
> > #mkdir some_build_path
> > # cd some_build_path
> > # cmake abs_path_to_lyx_sources ...
> 
> I use relative paths, and it works fine.
> 
> 
> Georg

I meant it as a possibility for MAC.

Kornel

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

Re: One official build system?

[Georg Baum]

Kornel Benko wrote:

> Am Sonntag, 5. Juni 2016 um 20:34:38, schrieb Liviu Andronic
> 
>> On Sun, Jun 5, 2016 at 7:43 PM, Kornel Benko  wrote:
> 
> Unfortunately cmake is not able yet to produce more than one debian
> package. Recently started discussions to support components for .rpm, but
> .deb is not that far. And we have more platforms.

The .deb packages created by cmake are really simple. They lack proper 
dependencies and interfere with the distro packages (a cmake generated 
package named "lyx" is different than the official one, so other packages 
depending on lyx might not work). I would not recommend to use these 
packages.

IMHO it does not make sense to recreate all debian/ubuntu tools for .deb or 
redhat tools for .rpm in cmake. cmake should build the stuff, and packaging 
is better done by the more advanced distro specific packaging tools. If you 
look at the debian packaging it will be very simple to replace autotools by 
cmake: Simply replace the dh_auto_configure call in 
http://anonscm.debian.org/cgit/pkg-lyx/lyx.git/tree/debian/rules by a 
corresponding cmake call.

>> >> > locale: $datarootdir/locale
>> >> > tex:$datarootdir/texmf/tex/latex/$package
>> >
>> > Same here.
>> >
>> Not sure what happens in this case, though.
>> 
> 
> If we could suffix them too ...

That was my suggestion. Otherwise packages will clash.


Georg

Re: [LyX/master] glitch in lfundoc

[Jürgen Spitzmüller]

Am Montag, den 06.06.2016, 09:53 -0700 schrieb Pavel Sanda:
> > No, this was not intentional. Thanks for fixing.
> 
> Hehe, no I did not fix it ;)

So, am I supposed to do something?

Jürgen

Re: [PATCH] unique_ptr and some clean-up

[Guillaume Munch]

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

Le 05/06/2016 à 13:54, Georg Baum a écrit :

I won't comment on the other items. IMHO, discussing all these in one
message makes things more complicated. I would prefer to go step by step.


I agree with Georg on that. It would be better to have distinct threads,
at least for groups of patches that fit together.


This is not a ticket on the bug tracker. Feel free to open a new thread
by replying to the first message when you are ready to comment on the 
other patches.




I will just make one general remark: is there a reason why you use
explicitly std::bind() instead of just bind? I'd prefer to drop the
std:: prefix at places where it is possible.



An omission. I already did that for the others, I'll fix that.

Re: One official build system?

[Georg Baum]

Scott Kostyshak wrote:

> On Sun, Jun 05, 2016 at 01:59:53PM +0200, Kornel Benko wrote:
>> 
>> OK, starting on the list first. I can only comment on the cmake part.
>> 
>> [A] detection of  external  dependencies
>> cmake does full detection IMHO
>> [B] create .rpm
>> cmake creates rpm, deb,
>> [E] create window package
>> don't know, we should ask Peter
> 
> CC'ing Peter then.

This table is old stuff and not important IMHO (maybe I should have deleted 
it before adding the new one). Any opinion on continuing in the wiki or in 
Development.lyx? If we continue in the wiki we should delete the old tables.


Georg

Re: [PATCH] unique_ptr and some clean-up

[Guillaume Munch]

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

Le 05/06/2016 à 13:54, Georg Baum a écrit :

Looks good, I have only one minor comment: Please do not use _MSC_VER
in the
sources. This code is better located in config.h, like that:

#if (__cplusplus >= 201402L) || (defined(_MSC_VER)&&(_MSC_VER>=1800))
// C++14, MSVC >= 2013
#define HAVE_STD_MAKE_UNIQUE
#endif


What about testing for std::make_unique instead?



You mean during configure?

Re: One official build system?

[Georg Baum]

Kornel Benko wrote:

> Don't know if this helps, but I never use relative path with cmake.
> #mkdir some_build_path
> # cd some_build_path
> # cmake abs_path_to_lyx_sources ...

I use relative paths, and it works fine.


Georg

Re: [LyX/master] Do not duplicate jpg format

[Guillaume Munch]

Le 04/06/2016 08:23, Georg Baum a écrit :

Guillaume Munch wrote:


Why not just using a set instead of a vector if this is important?


I believe that the order matters. We prefer the first format that is
reachable with a converter. With the current solution, qt can give a
preference,


You probably know that his does not happen. But, I understand the logic 
of keeping an ordered structure if the recipient is order-sensitive.

Re: One official build system?

[Georg Baum]

Kornel Benko wrote:

> Am Sonntag, 5. Juni 2016 um 19:03:51, schrieb Kornel Benko
> 
>> Am Sonntag, 5. Juni 2016 um 18:43:03, schrieb Georg Baum
>> 
>> > Kornel Benko wrote:
>> > 
> ...
>> > The remaining directories from the second list would be located as
>> > follows:
>> > 
>> > bin:$prefix/bin
>> > fonts:  $datarootdir/fonts/truetype/$package
> 
> I am not sure about this one. Are there clashes with
> the same files installed by different lyx-version?

If the fonts would always be in a subdirectory with version suffix then you 
could not install a versioned LyX in parallel to the distro package, for 
example. Using versioned directories ensures that packages can be installed 
in parallel. Which fonts are selected at runtime is a different story (and 
IMHO not important, they do not change often).

> How should latex select the correct data?

The fonts are picked up automatically by fontconfig if they are in any 
subdirectory of $datarootdir/fonts/truetype/.

>> > locale: $datarootdir/locale
>> > tex:$datarootdir/texmf/tex/latex/$package
> 
> Same here.

Same explanation as well;-)


Georg

Re: One official build system?

[Georg Baum]

Kornel Benko wrote:

> Version suffix for bin and locales is already used as expected.

Very good.

> I think, there is nothing to do for windows yet, because it uses already
> cmake.

OK (I was not sure whether the changes for linux would imply changews for 
windows as well).


Georg

Re: mingw not compilable ATM

[Georg Baum]

Kornel Benko wrote:

> Trying to compile with 'development/cmake/scripts/xmingw' I get
> ...
> [ 24%] Building CXX object
> [ src/frontends/qt4/CMakeFiles/frontend_qt.dir/_allinone_const.C.obj
> cd /usr/BUILD/mingw/src/frontends/qt4 && /usr/bin/i686-w64-mingw32-g++  
> -DBOOST_SIGNALS_NO_DEPRECATION_WARNING=1 -DHUNSPELL_STATIC
> -DLYX_BUILD_QT_FRONTEND -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_GENUINE_STR
> -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_SVG_LIB -DQT_WIDGETS_LIB
> -DQT_WINEXTRAS_LIB -DWINVER=0x0500
> @CMakeFiles/frontend_qt.dir/includes_CXX.rsp -Wall -Wunused-parameter
> --std=c++11 -fno-strict-aliasing  -Wall -Wunused-parameter --std=c++11 -O2
> -DNDEBUG   -DBOOST_USER_CONFIG="" -o
> CMakeFiles/frontend_qt.dir/_allinone_const.C.obj -c
> /usr/BUILD/mingw/src/frontends/qt4/_allinone_const.C In file included from
> /usr/BUILD/mingw/src/frontends/qt4/_allinone_const.C:358:0:
> /usr2/src/lyx/lyx-git/src/frontends/qt4/GuiApplication.cpp:127:21: fatal
> error: xcb/xcb.h: No such file or directory
>  #include 
>  ^
> compilation terminated. This is the same for master _and_ 2.2.x.

Looks like the wrong qt headers are picked up (from the host system). 
QPA_XCB is only supposed to be defined on linux. I do not have this problem 
with autotools and an explicitly set qtdir via --with-qt-dir=. Probably the 
implicit qt configuratian via PATH in xmingw does not work anymore, and you 
need to give an explicit qt dir.


Georg

Re: [patch] Fix lyx-2.3dev build failure in FreeBSD

[Scott Kostyshak]

On Sat, May 07, 2016 at 06:45:26AM +0200, Shankar Giri Venkita Giri wrote:
> There are basically two issues on FreeBSD.
>  
> Issue #1. Standard Includes and Libs are in /usr/local/include and /
> usr/local/lib unline Linux variants. --with-extra-prefix=/usr/local
> solves this problem. FreeBSD Ports build system exports LOCALBASE to
> /usr/local and so this problem does not occur when building from
> ports. When building from source directly, --with-extra-prefix is
> necessary
> Issue #2. -lexecinfo is needed for backtrace() on FreeBSD (https://
> github.com/pelegm/google-glog/issues/214) - Patch attached.
>  
> Otherwise lyx compiles and runs just fine.
> 
> INSTALL steps in FreeBSD
> 
>  ./configure --enable-qt5 --with-extra-prefix=/usr/local
> make
> make install
> 
> Three questions:
>  
> 1. Other BSDs certainly should have Issue #1, but probably need to
> check with other NetBSD, OpenBSD, DragonflyBSD users for Issue #2.
> Then the patch can be generalized to *BSD*.
> 2. Do we patch code for Issue #1 or just add README.BSD and document
> the --with-extra-prefix=/usr/local argument?
> 3. We can either patch in LyX or just ignore it and file a ticket in
> the FreeBSD ports system so that they add the patch in their build
> process. I prefer LyX to compile independent of build systems
> applying patches during building (that allows working and compiling
> git code directly), but its the community's call.

> diff --git a/configure.ac b/configure.ac
> index 7b8b742..2b1f923 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -236,6 +236,7 @@ dnl AC_LANG_POP(C)
>  lyx_win_res=false;
>  case ${host} in
>  *mingw*|*cygwin*) lyx_win_res=true;;
> +*freebsd*) AC_SEARCH_LIBS(backtrace_symbols, [execinfo])
>  esac
>  AM_CONDITIONAL(LYX_WIN_RESOURCE, $lyx_win_res)
>  LYX_SET_VERSION_INFO


Hi,

Sorry that you haven't gotten a response. Hopefully someone will take a
look at this.

If you haven't received a response on any of your other emails, please
bump those. We would not want emails to slip through the cracks. It is
usually that we just forget to respond or assume someone else will
respond, so please be persistent until you get a response. It is not
considered impolite at all to kindly bump your emails after a certain
time if no response.

By the way, would you mind testing whether it works well to build LyX on
FreeBSD with CMake?

Best,

Scott


signature.asc
Description: PGP signature

Re: One official build system?

[Kornel Benko]

Am Montag, 6. Juni 2016 um 19:26:24, schrieb Liviu Andronic 
> On Mon, Jun 6, 2016 at 6:56 PM, Kornel Benko  wrote:
> > Am Sonntag, 5. Juni 2016 um 20:34:38, schrieb Liviu Andronic 
> > 
> >> On Sun, Jun 5, 2016 at 7:43 PM, Kornel Benko  wrote:
> >> > Am Sonntag, 5. Juni 2016 um 19:03:51, schrieb Kornel Benko 
> >> > 
> >> >> Am Sonntag, 5. Juni 2016 um 18:43:03, schrieb Georg Baum 
> >> >> 
> >> >> > Kornel Benko wrote:
> >> >> >
> >> > ...
> >> >> > The remaining directories from the second list would be located as 
> >> >> > follows:
> >> >> >
> >> >> > bin:$prefix/bin
> >> >> > fonts:  $datarootdir/fonts/truetype/$package
> >> >
> >> > I am not sure about this one. Are there clashes with
> >> > the same files installed by different lyx-version?
> >> > How should latex select the correct data?
> >> >
> >> On Ubuntu for the fonts-lyx packages I simply make them conflict with
> >> each other, meaning that the user can install only one on the same
> >> system (e.g. fonts-lyx or fonts-lyx2.2).
> >>
> >
> 
> 
> > Unfortunately cmake is not able yet to produce more than one debian 
> > package. Recently started
> > discussions to support components for .rpm, but .deb is not that far.
> > And we have more platforms.
> >
> As far as my requirements go, I do not need cmake to output debian
> packages --- Launchpad and Debian tools take care of that. I only need
> cmake to install packages in expected directories with customizable
> paths (as we discussed earlier). So I don't think this is an issue.

This is easy. 'make package' is able to create a tar file. All files are
at the correct locations.

I for one _disable_ this creation with
# cmake ... -DCPACK_BINARY_TGZ:BOOL=OFF ...
but of course we can set ' -DCPACK_BINARY_TGZ:BOOL=ON'

> Liviu
> 
 Kornel

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

Re: One official build system?

[Liviu Andronic]

On Mon, Jun 6, 2016 at 6:56 PM, Kornel Benko  wrote:
> Am Sonntag, 5. Juni 2016 um 20:34:38, schrieb Liviu Andronic 
> 
>> On Sun, Jun 5, 2016 at 7:43 PM, Kornel Benko  wrote:
>> > Am Sonntag, 5. Juni 2016 um 19:03:51, schrieb Kornel Benko 
>> >> Am Sonntag, 5. Juni 2016 um 18:43:03, schrieb Georg Baum 
>> >> 
>> >> > Kornel Benko wrote:
>> >> >
>> > ...
>> >> > The remaining directories from the second list would be located as 
>> >> > follows:
>> >> >
>> >> > bin:$prefix/bin
>> >> > fonts:  $datarootdir/fonts/truetype/$package
>> >
>> > I am not sure about this one. Are there clashes with
>> > the same files installed by different lyx-version?
>> > How should latex select the correct data?
>> >
>> On Ubuntu for the fonts-lyx packages I simply make them conflict with
>> each other, meaning that the user can install only one on the same
>> system (e.g. fonts-lyx or fonts-lyx2.2).
>>
>


> Unfortunately cmake is not able yet to produce more than one debian package. 
> Recently started
> discussions to support components for .rpm, but .deb is not that far.
> And we have more platforms.
>
As far as my requirements go, I do not need cmake to output debian
packages --- Launchpad and Debian tools take care of that. I only need
cmake to install packages in expected directories with customizable
paths (as we discussed earlier). So I don't think this is an issue.

Liviu


>>
>> >> > locale: $datarootdir/locale
>> >> > tex:$datarootdir/texmf/tex/latex/$package
>> >
>> > Same here.
>> >
>> Not sure what happens in this case, though.
>>
>
> If we could suffix them too ...
>
>> Liviu
>>
>>
>
> Kornel

Re: One official build system?

[Kornel Benko]

Am Sonntag, 5. Juni 2016 um 20:34:38, schrieb Liviu Andronic 

> On Sun, Jun 5, 2016 at 7:43 PM, Kornel Benko  wrote:
> > Am Sonntag, 5. Juni 2016 um 19:03:51, schrieb Kornel Benko 
> >> Am Sonntag, 5. Juni 2016 um 18:43:03, schrieb Georg Baum 
> >> 
> >> > Kornel Benko wrote:
> >> >
> > ...
> >> > The remaining directories from the second list would be located as 
> >> > follows:
> >> >
> >> > bin:$prefix/bin
> >> > fonts:  $datarootdir/fonts/truetype/$package
> >
> > I am not sure about this one. Are there clashes with
> > the same files installed by different lyx-version?
> > How should latex select the correct data?
> >
> On Ubuntu for the fonts-lyx packages I simply make them conflict with
> each other, meaning that the user can install only one on the same
> system (e.g. fonts-lyx or fonts-lyx2.2).
> 

Unfortunately cmake is not able yet to produce more than one debian package. 
Recently started
discussions to support components for .rpm, but .deb is not that far.
And we have more platforms.

> 
> >> > locale: $datarootdir/locale
> >> > tex:$datarootdir/texmf/tex/latex/$package
> >
> > Same here.
> >
> Not sure what happens in this case, though.
> 

If we could suffix them too ...

> Liviu
> 
> 

Kornel

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

Re: [LyX/master] glitch in lfundoc

[Pavel Sanda]

Jürgen Spitzmüller wrote:
> > I don't know whether it was your intention, but it seems that part of
> > Hidden lfuns is no more generated correctly and some lfuns are missing
> > (most probably due to the fact they don't have Syntax line).
> 
> No, this was not intentional. Thanks for fixing.

Hehe, no I did not fix it ;)
Pavel

Re: One official build system?

[Kornel Benko]

Am Sonntag, 5. Juni 2016 um 12:27:52, schrieb Stephan Witt 
> Am 05.06.2016 um 11:13 schrieb Georg Baum :
> > 
> > Scott Kostyshak wrote:
> > 
> >> On Sat, Jun 04, 2016 at 07:55:28PM +0200, Stephan Witt wrote:
> >>> 
>  Am 04.06.2016 um 10:15 schrieb Liviu Andronic :
>  
>  If moving to cmake definitively would imply losing version suffix
>  functionality, this would be a big issue for my packaging arrangements
>  for Ubuntu builds.
> >>> 
> >>> +1
> >>> 
> >>> On Mac the version suffix is essential too.
> >> 
> >> I just want to make sure you saw Kornel's reply to that. I don't know if
> >> it addresses your needs or not.
> > 
> > IMHO it does. Livius builds could be done using their current names if the 
> > boolean switch is replaced by a string version, which is easy to do as 
> > Kornel wrote.
> 
> Yes. I think so.
> 
> > 
> >>> I just tried to build a Mac application with cmake and failed.
> >> 
> >> What was the error?
> >> 
> >>> It looks like a lot of work or to learn to make this working.

Yes. Stephan could you send me the list of installed files if you install with 
automake?
I can try to use the same directories.

> >> This might be a reason to stop this discussion here. You already do a
> >> huge favor by taking care of the Mac builds. It would not make sense to
> >> make it more difficult. I was hoping that in the long-run it would
> >> actually be easier for you, but perhaps the transition would be too
> >> frustrating and time-consuming.
> > 
> > We should not yet stop the discussion. We need more information about the 
> > problems.
> 
> I didn’t want to put the discussion on hold. I hadn’t the time to write
> a mail with enough details at the moment.
> 
> I use cmake to create Xcode projects for debugging purpose. So, it’s possible
> to create a working binary with cmake. To do the packaging with cmake is 
> another
> story and - at least on Mac - not done with LyX yet. No surprise it’s not
> working though.
> 
> The packaging is done in three steps with autotools + scripts:
> 1. make install with the appropriate directory structure for Mac
> 2. adding the 3rd party components required to run LyX
> 3. create a mountable disk image and put the LyX app and some
> decorative stuff there and compress the final result.
> 
> To get the first impression how difficult it is with cmake I tried two ways:
> 1. standard cmake install (the naive way) results in a Linux like directory
> structure without an usable application.
> 2. LYX_DMG=ON cmake install (marked as experimental) is better as it copies
> the components of LyX to the appropriate directory structure for Mac.
> Therefore the 2nd one should be the default on Mac.
> 
> Nevertheless it doesn’t work ATM because of the type of the dependency on Qt.
> This is not easy to explain - but I’ll try it.
> 
> The runtime linker knows of the usual LD_LIBRARY_PATH mechanism like Unix.
> An more secure and more advanced approach is the modified RPATH mechanism.
> For system libraries one uses hard coded library references.
> 
> The problem is the RPATH mechanism. Qt frameworks (a collection of header
> files, shared libraries and documentation) are build with these. To distribute
> these frameworks they have to be placed on a fixed location for system wide 
> use
> or inside the LyX application as so called private frameworks. LyX is using
> the latter and I cannot see why this should be changed. The cmake build
> for LyX needs to be extended to copy the Qt libraries into the LyX application
> in or before the „fixup_bundle“ phase of the packaging step. I’m almost sure
> this can be done in a reliable and clean way with cmake. That’s why I said
> there is something to learn and to spend some time with.

Sorry, you are on your own here I suppose. For me the MAC is a mystery.

> Finally I want to add the concrete error log - it ends with:
> ===
> -- fixup_bundle: preparing…
> ...
> -- warning: gp_resolved_file_type non-absolute file 
> '@rpath/QtCore.framework/Versions/5/QtCore' returning type 'other' -- 
> possibly incorrect
> 
>   possible problems:
> need more directories?
> need to use InstallRequiredSystemLibraries?
> run in install tree instead of build tree?
> 
> warning: target '@rpath/QtGui.framework/Versions/5/QtGui' is not absolute...
> warning: target '@rpath/QtGui.framework/Versions/5/QtGui' does not exist...

Don't know if this helps, but I never use relative path with cmake.
#mkdir some_build_path
# cd some_build_path
# cmake abs_path_to_lyx_sources ...

> CMake Error at /opt/local/share/cmake-3.4/Modules/GetPrerequisites.cmake:800 
> (message):
>   /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolc
>   hain/usr/bin/otool failed: 1
>   
>   error:
>   /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolc
>   hain/usr/bin/otool: can't open file:
>   

Fwd: Blurry inserted figures for retina display in Lyx 2.2 Mac

[Richard Heck]

Questions like this one are better sent to the developers' list, so I'm
forwarding it there.

 Forwarded Message 
Subject:Blurry inserted figures for retina display in Lyx 2.2 Mac
Date:   Sun, 5 Jun 2016 21:05:03 -0400
From:   Zhexuan Gong 
To: lyx-us...@lists.lyx.org



Dear Lyx developers,

I've just installed the official release of Lyx 2.2 Mac version. Thanks
a lot for your team's hard work! It's really awesome and the text in the
workspace is super sharp right now. However, the display of inserted
figures in the Lyx workspace is still blurry and non-retina (see my
screenshot at http://i.imgur.com/mI849a8.jpg) on my retina display
Macbook. Are you aware of this problem and is there a plan to fix it in
a future version?

Thanks a lot!

Zhexuan

Re: Tarballs for LyX 2.2.0 are on FTP

[Jean-Marc Lasgouttes]

Le 05/06/2016 à 21:05, Guillaume Munch a écrit :

Yet, most of the file format changes are very simple. I wonder whether
one could introduce a single compilation variable to disable them,
and ask developers to enclose file-format-specific code between the
corresponding #ifdefs. (For instance in my last file format change all
that was needed to be enclosed was the parsing code.) This would allow
the release of "master versions without file format changes", either as
nightlies or as official "x.5" versions as Pavel suggested by Pavel in
another message (without having to maintain three branches in parallel).


This looks too complicated to me. And eventually there will be changes 
that cannot be treated like that, and all the previous work on small 
changes will be useless.


Note that that stable nightlies could be updated with lyx2lyx code for 
new master versions in parallel with master.



Sure. Not difficult once we have the nightlies.


Jean-Marc, have you looked into ci.inria.fr?


Not seriously, but it looks like what we want. I do not know about its 
reliability, though.



Jean-Marc, also could a new Trac version not help automating the
retargeting the release manager has to do every time? Independently,
would it not be now the time to update Trac to a newer version? (I am
assuming you are the one who knows about this.)


Trac will be updated when the whole server will be updated. We run on 
CentOS 6 right now. Presumably CentOS 7 would givce us a better trac (I 
did not check).


JMarc

Re: [PATCH] unique_ptr and some clean-up

[Jean-Marc Lasgouttes]

Le 05/06/2016 à 13:54, Georg Baum a écrit :

I won't comment on the other items. IMHO, discussing all these in one
message makes things more complicated. I would prefer to go step by step.


I agree with Georg on that. It would be better to have distinct threads, 
at least for groups of patches that fit together.


I will just make one general remark: is there a reason why you use 
explicitly std::bind() instead of just bind? I'd prefer to drop the 
std:: prefix at places where it is possible.


JMarc

Re: [PATCH] unique_ptr and some clean-up

[Jean-Marc Lasgouttes]

Le 05/06/2016 à 13:54, Georg Baum a écrit :

Looks good, I have only one minor comment: Please do not use _MSC_VER in the
sources. This code is better located in config.h, like that:

#if (__cplusplus >= 201402L) || (defined(_MSC_VER)&&(_MSC_VER>=1800))
// C++14, MSVC >= 2013
#define HAVE_STD_MAKE_UNIQUE
#endif


What about testing for std::make_unique instead?

JMarc

Re: mingw not compilable ATM

[Kornel Benko]

Am Montag, 6. Juni 2016 um 04:04:38, schrieb Scott Kostyshak 
> On Mon, Jun 06, 2016 at 08:58:35AM +0200, Kornel Benko wrote:
> > Trying to compile with 'development/cmake/scripts/xmingw' I get
> > ...
> > [ 24%] Building CXX object 
> > src/frontends/qt4/CMakeFiles/frontend_qt.dir/_allinone_const.C.obj
> > cd /usr/BUILD/mingw/src/frontends/qt4 && /usr/bin/i686-w64-mingw32-g++   
> > -DBOOST_SIGNALS_NO_DEPRECATION_WARNING=1 -DHUNSPELL_STATIC 
> > -DLYX_BUILD_QT_FRONTEND -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_GENUINE_STR 
> > -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_SVG_LIB -DQT_WIDGETS_LIB -DQT_WINEXTRAS_LIB 
> > -DWINVER=0x0500 @CMakeFiles/frontend_qt.dir/includes_CXX.rsp -Wall 
> > -Wunused-parameter --std=c++11 -fno-strict-aliasing  -Wall 
> > -Wunused-parameter --std=c++11 -O2 -DNDEBUG   
> > -DBOOST_USER_CONFIG="" -o 
> > CMakeFiles/frontend_qt.dir/_allinone_const.C.obj -c 
> > /usr/BUILD/mingw/src/frontends/qt4/_allinone_const.C
> > In file included from 
> > /usr/BUILD/mingw/src/frontends/qt4/_allinone_const.C:358:0:
> > /usr2/src/lyx/lyx-git/src/frontends/qt4/GuiApplication.cpp:127:21: fatal 
> > error: xcb/xcb.h: No such file or directory
> >  #include 
> >  ^
> > compilation terminated. This is the same for master _and_ 2.2.x.
> > 
> > Anyone else having problems?
> 
> What are the commands I should run in order to test this?

mkdir some_build_dir
cd some_build_dir
source_dir/development/cmake/scripts/xmingw source_dir

> Scott

Kornel

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

Re: mingw not compilable ATM

[Scott Kostyshak]

On Mon, Jun 06, 2016 at 08:58:35AM +0200, Kornel Benko wrote:
> Trying to compile with 'development/cmake/scripts/xmingw' I get
> ...
> [ 24%] Building CXX object 
> src/frontends/qt4/CMakeFiles/frontend_qt.dir/_allinone_const.C.obj
> cd /usr/BUILD/mingw/src/frontends/qt4 && /usr/bin/i686-w64-mingw32-g++   
> -DBOOST_SIGNALS_NO_DEPRECATION_WARNING=1 -DHUNSPELL_STATIC 
> -DLYX_BUILD_QT_FRONTEND -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_GENUINE_STR 
> -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_SVG_LIB -DQT_WIDGETS_LIB -DQT_WINEXTRAS_LIB 
> -DWINVER=0x0500 @CMakeFiles/frontend_qt.dir/includes_CXX.rsp -Wall 
> -Wunused-parameter --std=c++11 -fno-strict-aliasing  -Wall -Wunused-parameter 
> --std=c++11 -O2 -DNDEBUG   -DBOOST_USER_CONFIG="" -o 
> CMakeFiles/frontend_qt.dir/_allinone_const.C.obj -c 
> /usr/BUILD/mingw/src/frontends/qt4/_allinone_const.C
> In file included from 
> /usr/BUILD/mingw/src/frontends/qt4/_allinone_const.C:358:0:
> /usr2/src/lyx/lyx-git/src/frontends/qt4/GuiApplication.cpp:127:21: fatal 
> error: xcb/xcb.h: No such file or directory
>  #include 
>  ^
> compilation terminated. This is the same for master _and_ 2.2.x.
> 
> Anyone else having problems?

What are the commands I should run in order to test this?

Scott


signature.asc
Description: PGP signature

mingw not compilable ATM

[Kornel Benko]

Trying to compile with 'development/cmake/scripts/xmingw' I get
...
[ 24%] Building CXX object 
src/frontends/qt4/CMakeFiles/frontend_qt.dir/_allinone_const.C.obj
cd /usr/BUILD/mingw/src/frontends/qt4 && /usr/bin/i686-w64-mingw32-g++   
-DBOOST_SIGNALS_NO_DEPRECATION_WARNING=1 -DHUNSPELL_STATIC 
-DLYX_BUILD_QT_FRONTEND -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_GENUINE_STR 
-DQT_GUI_LIB -DQT_NO_DEBUG -DQT_SVG_LIB -DQT_WIDGETS_LIB -DQT_WINEXTRAS_LIB 
-DWINVER=0x0500 @CMakeFiles/frontend_qt.dir/includes_CXX.rsp -Wall 
-Wunused-parameter --std=c++11 -fno-strict-aliasing  -Wall -Wunused-parameter 
--std=c++11 -O2 -DNDEBUG   -DBOOST_USER_CONFIG="" -o 
CMakeFiles/frontend_qt.dir/_allinone_const.C.obj -c 
/usr/BUILD/mingw/src/frontends/qt4/_allinone_const.C
In file included from 
/usr/BUILD/mingw/src/frontends/qt4/_allinone_const.C:358:0:
/usr2/src/lyx/lyx-git/src/frontends/qt4/GuiApplication.cpp:127:21: fatal error: 
xcb/xcb.h: No such file or directory
 #include 
 ^
compilation terminated. This is the same for master _and_ 2.2.x.

Anyone else having problems?

Kornel


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

Re: Lyx 2.2 Mac dev build request

[Stephan Witt]

Hi Zhexuan,

thank you for using LyX and your feedback.

Yes, I’m aware of the problem of displaying graphics with non-HiDPI-resolution.

Please consider to open a bug report here: http://www.lyx.org/trac

Best regards,
Stephan

> Am 03.06.2016 um 22:56 schrieb Zhexuan Gong :
> 
> Hi Stephan,
> 
> I've just installed the official release of Lyx 2.2. Thanks a lot for your 
> team's hard work! It's really awsome. The only bug I've noticed so far is 
> that the display of graphics is still non-retina (see attached screenshot). 
> Are you aware of this problem in the final version and is there a plan to fix 
> it in the future version?
> 
> Thanks!
> 
> Zhexuan
> 
> On Sun, Nov 15, 2015 at 2:35 PM, Stephan Witt  wrote:
> Hi Zhexuan,
> 
> these are good news. Thank you for your help with testing. The scrolling 
> problem is a known one and very difficult to solve. The non-retina display of 
> figures is another tricky problem.
> 
> Best,
> Stephan
> 
> Am 15.11.2015 um 17:25 schrieb Zhexuan Gong :
> 
> > Hi Stephan,
> >
> > The version you sent me today no longer has that bug. And it also fixed the 
> > previous bug about broken display of equations when pixel map cache is 
> > enabled (although scrolling is still not smooth)! Looks like this version 
> > is much more polished. The only remaining bug I am aware of now is the 
> > non-retina display of figures, but it's no big deal. Thanks a lot for all 
> > the hard work you and your team have done!
> >
> > Best,
> >
> > Zhexuan
> >
> > On Sun, Nov 15, 2015 at 10:57 AM, Stephan Witt  wrote:
> > Hi Zhexuan,
> >
> > with the current software state I cannot reproduce your problem. But 
> > possibly it depends on the language settings or environment. In case you 
> > can reproduce the crash with the packaged software I've send you, are you 
> > able to make an example document and send it to me?
> >
> > Best,
> > Stephan
> >
> > Am 15.11.2015 um 12:18 schrieb Stephan Witt :
> >
> > > Hi Zhexuan,
> > >
> > > thank you for the report. Currently the process of making the alpha 
> > > release of LyX 2.2.0 is running. Meanwhile you may try another more 
> > > current intermediate build I've put here:
> > >
> > > https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0dev-c4ae71c%2Bqt5-x86_64-cocoa.dmg
> > > https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0dev-c4ae71c%2Bqt5-x86_64-cocoa.dmg.sig
> > >
> > > I'll try to investigate the crash you've reported soon.
> > >
> > > Best,
> > > Stephan
> > >
> > > Am 15.11.2015 um 01:11 schrieb Zhexuan Gong :
> > >
> > >> Hi Stephan,
> > >>
> > >> I have found another bug of the dev Lyx 2.2 you gave me. Whenever I copy 
> > >> a part of document that contains a float environment (float 
> > >> figure/table/etc), Lyx crashes with a message box saying "Exception: 
> > >> iconv problem in iconv_codecvt_facet initialization". You can reproduce 
> > >> this bug with just an empty document with an empty float figure.
> > >>
> > >> Best,
> > >>
> > >> Zhexuan
> > >>
> > >> On Mon, Oct 12, 2015 at 4:16 PM, Zhexuan Gong  wrote:
> > >> Hi Stephan,
> > >>
> > >> Thanks for your reply. I just tested the newer version and the missing 
> > >> character bug is still there. I also notice that this bug only happens 
> > >> to the words near the right end of the screen, as well as the words 
> > >> before an inline equation or a special formatting character (such as a 
> > >> protected space).  Changing font and display zoom ratio does not help.
> > >>
> > >> Best,
> > >>
> > >> Zhexuan
> > >>
> > >> On Mon, Oct 12, 2015 at 4:04 PM, Stephan Witt  wrote:
> > >> Am 12.10.2015 um 17:23 schrieb Zhexuan Gong :
> > >>
> > >>> Hi Stephan,
> > >>>
> > >>> Yes I actually didn't find any noticeable improvement in scrolling 
> > >>> compared to 2.1.4. The problem is not really the speed of scrolling, 
> > >>> but the smoothness of scrolling. There is a noticeable jerkiness when 
> > >>> you scroll up and down. Enabling pixel map cache will improve the 
> > >>> situation a little bit for both versions, but compared to many other OS 
> > >>> X apps (such as Safari, Preview, TeXShop etc), the scrolling experience 
> > >>> is much less satisfactory. But I think this is a relatively minor issue 
> > >>> compared to the missing character display bug I mentioned.
> > >>
> > >> Hi Zhexuan,
> > >>
> > >> thank you for the effort to compare the LyX versions. So it is at least 
> > >> not worse with 2.2.0. The scrolling speed is a long standing issue, 
> > >> unfortunately. Currently I don't know how to improve this - the way LyX 
> > >> is doing the on-screen presentation of the contents is very different 
> > >> from other programs since ages.
> > >>
> > >>> Also I find that the dev version you gave me shows a date of April 14, 
> > >>> 2014 and a Qt version of 5.4.2 in the about menu. Is there a new 
> > >>> version I could