Re: C++ "good practices" regarding constifying a function parameter?

[Vincent van Ravesteijn]

Op 6 aug. 2016 11:26 schreef "Abdelrazak Younes" :
>
> Hi Scott,
>
> Too late already but my 2 cents below :-)
>
>
> On 27/07/2016 02:54, Scott Kostyshak wrote:
>>
>> The attached patch constifies a function parameter. My question is
>> whether this patch causes more pain to other developers than it does
>> good to the code.
>>
>> The patch modifies a header that is included in many of our .cpp files,
>> so will cause a significant amount of recompilation.
>>
>> I think I will come across this scenario in the future so I am curious:
>> what are your preferences?
>>
>> (1) Do not commit any part of the patch because it is so minor.
>
>
> This is my preference because it doesn't bring anything and it can create
confusion for the beginner when compared with const reference. The C++
beginner could be tempted to add a "&" here...
>
> I think it was in the coding style document somewhere that POD parameter
(except big structure of course) should be passed by copy.
>
> Conclusion: I'd prefer the coding style to actually forbids this actually
:-)
> The coding style should also say that function parameter shall not be
changed in the function. Create your own local copy if you need it.
>
> Thanks,
> Abdel.
>

Hi Abdel,

I remember the same coding rule and was therefore tempted to reply in the
same line. However, when I looked into the code, I saw that this function
was very very long, and therefore it is not easy to always see that this
variable is actually a function parameter.

But, I guess the coding standard says that functions shouldn't be longer
than something like half a screen.

Vincent

Re: [LyX/master] Fix display of branch buttons and tooltips.

[Vincent van Ravesteijn]

On Sat, Jul 30, 2016 at 4:58 AM, Richard Heck  wrote:
> commit cbbae06c9bb735759a611bad483d3a1c01d3aed7
> Author: Richard Heck 
> Date: Fri Jul 29 22:58:03 2016 -0400
>
> Fix display of branch buttons and tooltips.

[..]

> - if (isOpen(bv))
> - return heading;

Hi Richard,

Do you find it useful to show the inset content in the tooltip when the
branch is actually opened ?

> - return toolTipText(heading + from_ascii("\n"));
[..]
> + return toolTipText(heading);

We do really need the newline here, because now the inset content is added
to the end: "insetstatus: onblablabla" for a branch inset with content
"blablabla".

Vincent

Re: [RFC] Staging Branches and Trac

[Vincent van Ravesteijn]

Op 16 apr. 2016 21:50 schreef "Richard Heck" :
>
>
> As Scott pointed out, my previous suggestions for how fixes committed to
> the staging branches should be handled in trac was silly. We can't reuse
> "fixedinmaster" for 2.3-staging. I'm also not sure that we want to
> introduce a new status "fixedinstaging" for such a short time.
>

First of all, 2.3-staging should be master, and current master should be
2.2.x. (see another thread)

Besides that, what is wrong with a keyword fixedinmaster and a milestone
2.3 for things in 2.3-staging ? It looks perfectly fine to me: the bug will
be fixed in 2.3, but is not fixed for 2.2.x.

Vincent

Re: Staging Branches [REVISED]

[Vincent van Ravesteijn]

>
> We should already be on 2.2 and not on master, which is the future: 2.3
>

Yes, that was also my proposal.

However, people appear to be afraid to not have the 2.2.0 tag in master.

But note that if the 2.2-branch in this scenario is merged back into master
after the release, it is equivalent to merging 2.3-staging to master in the
current proposal. In both ways the tag ends up in master, and there is not
a real difference between merging A into B anhd  merging B into A.

2.2.1-staging is not necessary as all changes are so important that they
can probably go to 2.2.0 as well. Changes for 2.2.2 can be cherry-picked
from 2.3-staging (or master) when 2.1.1 is released.

Vincent

Re: master is locked for 2.2.0rc1 preparation

[Vincent van Ravesteijn]

On Wed, Apr 13, 2016 at 11:20 AM, Pavel Sanda  wrote:
> Scott Kostyshak wrote:
>> B) Branch 2.2.x from master and continue "unstable" development on
>> master.
>>
>> To me it does not feel right that the commits in-between 2.2.0rc1 and
>> 2.2.0 final would not *necessarily* be in master's commit history. I
>
> I would prefer to see 2.2.0 final commit in master, reason being
> history searches via git log etc.
>

git log $(git merge-base HEAD 2.2.0)..HEAD

Vincent

Re: master is locked for 2.2.0rc1 preparation

[Vincent van Ravesteijn]

Op 12 apr. 2016 22:07 schreef "Vincent van Ravesteijn" <v...@lyx.org>:
>
>
> Op 12 apr. 2016 21:29 schreef "Jean-Marc Lasgouttes" <lasgout...@lyx.org>:
>
> >
> > Le 12/04/16 18:45, Scott Kostyshak a écrit :
> >
> >> So in the commit history of master we will not see the final 2.2.0
> >> release (e.g. fde16219 for 2.1.0)?
> >>
> >> Have we done this before in this way?
> >
> >
> > No Vincent did not want that. But since he is away, we can be naughty.
>

Hmm, maybe I just didn't want or was not allowed to break with history too
much.

In my opinion, release management and branches should be done as follows:

- all development for 2.3.0 can be done at master.
- all development for 2.2.0 can be done at a 2.2.x branch

- do the release for 2.2.0Rc1 at a "release" branch based on the 2.2.x
branch at that moment (no need of closing/reopening branch anymore). This
means that the commits for 2.2.0rc1 that shouldn't be part of 2.3.0 do not
have to be reverted afterwards. E.g. this avoids changing version from dev
to Rc1 and back in the next commit.

- Continue development and periodically merge the 2.2.x branch into master
(besides weird exceptions, all commits that go into 2.2.0 will be in the
master that will be the start of 2.3.0)

- when Rc2 is to be released, merge 2.2.x into "release", change Rc1 to Rc2
and tag.

- Continue until 2.2.0 is released.

Afterwards I would try to avoid cherry-picking as well as I hate the double
commit policy. However, the 2.2.x will be a dead branch eventually, so to
avoid git management we could continue like we always did.

Conclusion: development can continue on master and still all commits that
form 2.2.0 are in the "new" master for 2.3.0, (except for the
version-change-like commits that are decoration).

Vincent

Re: master is locked for 2.2.0rc1 preparation

[Vincent van Ravesteijn]

Op 12 apr. 2016 21:29 schreef "Jean-Marc Lasgouttes" :
>
> Le 12/04/16 18:45, Scott Kostyshak a écrit :
>
>> So in the commit history of master we will not see the final 2.2.0
>> release (e.g. fde16219 for 2.1.0)?
>>
>> Have we done this before in this way?
>
>
> No Vincent did not want that. But since he is away, we can be naughty.

Huh, what?

Vincent

Re: [LyX/master] Fix 480937a103708a651/lyxgit. See also #9740.

[Vincent van Ravesteijn]

On Fri, Nov 13, 2015 at 11:35 AM, Guenter Milde  wrote:
> On 2015-11-12, Kornel Benko wrote:
>> Am Donnerstag, 12. November 2015 um 16:18:12, schrieb Guenter Milde
>
>>> As a proof of concept, I also changed lib/doc/el/Intro.lyx to use
>>> DejaVu as non-TeX font. A similar approach might fix also other "*systemF"
>>> tests.
>
>>> We should, however, get a consensus on the "multiscript non-TeX font" for
>>> our manuals. It should be free, widely available, and have a good
>>> coverage for non-Latin scripts. DejaVu is just my suggestion, an
>>> alternative would be "Linux Libertine" or "Free Serif".
>
>> We use it already at export tests. (default is
>> FreeSerif,FreeSans,FreeMono, for some languages we select Dejavu or
>> FreeFarsi etc.)
>
> OK. However, instead of hiding this in the test logic, we can now make the
> documents robust by setting these fonts in the source.
>
>

Yes. Tests shouldn't adjust the lyx files to be able to export just
because it has to pass the test.

Vincent

Re: [PATCH] Bug #9854 "Dataloss after git merge with change tracking"

[Vincent van Ravesteijn]

On Thu, Nov 12, 2015 at 8:12 PM, Georg Baum
<georg.b...@post.rwth-aachen.de> wrote:
> Vincent van Ravesteijn wrote:
>
>> I doubt whether it is a good thing to start fiddling with the document
>> when we read in a corrupt file.
>>
>> Version control systems can corrupt a file in so many ways.. do we
>> really want to raise the impression we could read it in properly but
>> in the mean time things are lost.
>
> In general I agree. However, this is a very special case, because LyX
> currently actively provokes wrong merges, by removing \author lines if no
> change of this author remains in the document. Unfortunately there is a good
> reason for this behaviour: If LyX would not do that, then unused \author
> lines could easily accumulate: If I accept all changes of my co-author, and
> he never edits the file again, then his \author line will remain in the file
> forever. This should be prevented IMHO.

Yes. And if we implement an option to keep the old authors (to be vcs
friendly), we should be aware of privacy issues. Storing someone's
name and e-mail address in a document, while there is no visible
remnant left anymore might cause unwanted issues. For instance,
someone puts the lyx document on the internet, after having accepted
all changes, etc.

>
> I don't know if there is a solution for the messed up \author lines, but I
> think the other part of the patch (creating a dummy author if no author is
> present) is a good thing: It replaces one way of dealing with a corrupt
> document with a better one. If we wanted to be strict, then the current
> behaviour of throwing away the changes is as bad as the proposed patch, and
> we should refuse to load the file and force the user to fix the broken
> merge.

Yes. Completely true.

Why do we store the author list in the list ? Apparently, the author
list is composed of all authors having changes in the document. This
doesn't need to be stored in the file then, because this duplicates
info. It probably is there only to store the name and e-mail in one
place to where can be refered in the rest of the document. Adding a
dummy author isn't very useful then, because it doesn't add info.
Then, if the author line is not present, we just don't show the author
name and email address in the gui.

We could also add a preference "Anonymous change tracking", instead of
using the user's name and e-mail.

I just don't like changing the document while reading it.

>
> Unfortunately there is another cause of corrupt merges: LyX files can have
> many copies of a few identical lines, e.g. (taken from the user guide)
>
>
>
> This can easily lead to wrong merges if two authors edit nearby parts of the
> document, where the VCS thinks that the merge was OK, although it is not.
> This should be prevented by changing the file format so that it does not
> contain so many repetitions.

I believe that 'git' can have custom merge filter/script for certain
file types. Maybe the community would like a special LyX-merger script
that can be used by the vcs to reduce merge errors as much as
possible.

Vincent

Re: [PATCH] Bug #9854 "Dataloss after git merge with change tracking"

[Vincent van Ravesteijn]

On Thu, Nov 12, 2015 at 4:41 PM, Jean-Marc Lasgouttes
 wrote:
> Le 11/11/2015 23:12, Guillaume Munch a écrit :
>>
>> Dear list,
>>
>>
>> The patch below fixes bug #9854. ()
>> Find more details in the commit log.
>>
>> I have two questions:
>>
>> * I had to remove a const qualifier in Text::readParToken (see patch
>> below). Do I need to put it back? If so, what's the proper way of
>> adding the dummy author?
>
>
> I would say that bparams was const here because we could do it. If you need
> it to be non-const, that's OK too.
>
> JMarc

I doubt whether it is a good thing to start fiddling with the document
when we read in a corrupt file.

Version control systems can corrupt a file in so many ways.. do we
really want to raise the impression we could read it in properly but
in the mean time things are lost.

Vincent

Re: We now include both png and svgz?

[Vincent van Ravesteijn]

On Wed, Nov 11, 2015 at 1:02 PM, Jean-Marc Lasgouttes
<lasgout...@lyx.org> wrote:
> Le 10/11/2015 10:02, Vincent van Ravesteijn a écrit :
>>
>> At the moment you cannot use LyX with Qt4 because it cannot read svgz
>> files, and the code is not correctly falling back to png files.
>>
>> So yes, we need both, otherwise we will have to require newer versions of
>> Qt.
>
>
> My copy of lyx 2.2 with qt4.8 handles svg icons fine. Could it be a
> cmake/qt4 issue? (I have no idea how cmake checking works). The difference
> is only whether we link against QtSvg, I think.
>
> JMarc
>

That could be yes.

In any case, the logic is a bit strange. The icon names are defined
with the extension {png,svgz} so that any one matched, and getPixmap
checks whether the file can be loaded or not. However, iconName then
already decides on whether it is png or svgz just based on existence,
not on whether it can be loaded.

So, either we make QtSvg a "required" dependency, and cmake/autotools
should check for it, or we improve the logic to decide whether we lood
the png or svgz variant.

Vincent

Re: We now include both png and svgz?

[Vincent van Ravesteijn]

On Tue, Nov 10, 2015 at 4:13 AM, Scott Kostyshak  wrote:
> When experimenting with building the tar balls, I noticed a significant
> difference in size between 2.2.0dev and 2.1.4.
>
> lyx-2.1.4.tar.gz is 20.8 MB
> lyx-2.2.0dev.tar.gz is 24.8 MB
>
> A quick check seems to show that most of the change comes from now
> including .svgz (in addition to .png). Why do we include both?
>
> I just wanted to check that this is expected.
>
> Scott

At the moment you cannot use LyX with Qt4 because it cannot read svgz
files, and the code is not correctly falling back to png files.

So yes, we need both, otherwise we will have to require newer versions of Qt.

Vincent

Re: Plan for the current testing situation

[Vincent van Ravesteijn]

>> Ideally, I would like for commits that break tests to be on a separate
git
>> branch. Once the bugs exposed by a commit are fixed or the tests are
fixed, or
>> the .lyx files are fixed, then the branch could be merged to master. This
>> allows us to presere a "0 failing tests" situation on the master branch
so it
>> is extremely easy to catch regressions. So my preferred policy would be:
if a
>> commit is found to have broken a test, either the situation is resolved
within
>> a day (i.e. the bug is fixed or the test is fixed) or the commit is
reverted
>> (and perhaps pushed to a separate remote branch).
>
>
> A small remark: imposing a 1-day rule seems ad hoc to me. Do we even have
such rules for compilation warnings? For compilation failures? For the
latter, I imagine that people want it solved ASAP, but this arises more out
of social pressure, not an ad hoc rule. However I like the idea of having a
"candidate" remote branch, which would open up possibilities. If that's
really needed.
>

Yes, the 1-day rule might lead to frustrated developers and increases the
noise in master branch even more.

And yes of course there is an implicit rule that when your commit breaks
something or has problems whatsoever you are expected to fix it within a
reasonable timeframe.

I already proposed to have a "staging" branch where commits are pushed to
first. If there are no breaking tests and no other comments they would be
merged to master after n days. The problems with such a  construction are:
- devs are not eager to have to learn/understand/use an even more complex
git-o-cratic workflow,
- there will be merge conflicts, people have to make sure to indicate which
commit depends on which (or use feature branches which takes us back to the
first point),
- you unavoidably need some sort of maintainer to decide what gets merged
when and who resolves merge conflicts and is reasonably always present (or
to try to use some autocomplex scripting).

Vincent

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

[Vincent van Ravesteijn]

> Democracy is not the point IMHO: The point is not to further delay the
> release. Implementing a small and safe file format change where everybody
> agrees that it is useful does not produce a significant delay. Discussing
a
> controversal change where no easy solution is in sight has the potential
of
> delaying the release (at least if the possibility of implementing the
change
> before the release is seriously considered). Therefore I think that it is
> not the right time right now to have this discussion.
>

Is it really a file format change? If we do not change the physical
appearance of the file format, and if we do not change the document output
of a certain file, is it then still forbidden to change in a minor release?

I mean, it's just a GUI change basically.

Vincent

Re: Two Shortcut Changes

[Vincent van Ravesteijn]

Op 5 nov. 2015 21:48 schreef "Jean-Marc Lasgouttes" :
>
> Le 05/11/15 21:34, Richard Heck a écrit :
>
>>> I've used PSTricks extensively with LyX. Having a shortcut to ps
>>> output has been very convenient.
>>
>>
>> This seems like a case where you should set the default output format to
>> Postscript, no?
>
>
> I'd say the same. I am not sure what the use case is, except for people
who want to typeset the same document in multiple formats repeatedly.
>
> Anyway, it was not a good idea to steal C-S-T without stealing C-T too.
>
> JMarc

Should we have a shortcut to export to the last chosen format. So, when I
use the toolbar to export to ps, this shortcut let me repeatedly export to
ps. If I then choose to export to pdf, this shortcut would export to pdf.

Ps, I never liked a document setting indicating the default output format.

Vincent

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

[Vincent van Ravesteijn]

On Fri, Nov 6, 2015 at 10:08 AM, Jean-Marc Lasgouttes
 wrote:
> Le 06/11/2015 10:06, Stephan Witt a écrit :
>>
>> In this sense there is no need to reduce the likely-hood of merge
>> conflicts
>> with the state of change tracking. It's not a setting to toggle often,
>> IMHO.
>
>
> Well, since some people do change it often (if only to piss off their
> co-author :), we could try to see how to mitigate the problem IMO.
>
> JMarc
>

Using change tracking continuously will make a huge mess of your
document. Imagine moving a float one paragraph down, none of your
co-authors cares probably (as the float is floating anyway), but the
on the screen it clutters everything. I always have to take care to
accept the stuff not really relevant for my co-authors to review, such
that they focus on the parts that changed meaning or not. I often
disable change tracking when fixing small things, when incorporating
previous feedback from co-authors, when doing LyX/LaTeX special stuff,
when writing a large new paragraph (it hurts the eyes looking at that
as change) and afterwards I will either cut and paste it to show that
it is added or my coauthors will know that that part is new.

Then, the LyX documentation is supposed to be _the_ workflow in which
the current setting of track changes is optimal. Looking in Math.lyx,
and UserGuide.lyx in master and in 2.1.x, they all have
"\track_changes false". So, it is not working like it is now.

I'm not against having a document setting whether the document is
using track changes or not, I'm just against storing whether I
accidentally had it enabled or not when I saved the document.

Vincent

Re: make lyxdist giving me an error

[Vincent van Ravesteijn]

On Thu, Nov 5, 2015 at 9:57 AM, Scott Kostyshak  wrote:
> I have been reading up on the release process at various sources,
> including http://wiki.lyx.org/Devel/ReleaseProcedure.
>
> The following command
> ./autogen.sh && ./configure --enable-build-type=pre && make lyxdist
> gives me an error:
>
> make[3]: *** No rule to make target 'test/test-insets-basic.lyx', needed
> by 'distdir'.  Stop.
>

It is a type in src/tex2lyx/Makefile:

-   test/test-insets-basic.lyx \
+  test/test-insets-basic.tex \


Vincent

Re: make lyxdist giving me an error

[Vincent van Ravesteijn]

On Thu, Nov 5, 2015 at 10:31 AM, Vincent van Ravesteijn <v...@lyx.org> wrote:
> On Thu, Nov 5, 2015 at 9:57 AM, Scott Kostyshak <skost...@lyx.org> wrote:
>> I have been reading up on the release process at various sources,
>> including http://wiki.lyx.org/Devel/ReleaseProcedure.
>>
>> The following command
>> ./autogen.sh && ./configure --enable-build-type=pre && make lyxdist
>> gives me an error:
>>
>> make[3]: *** No rule to make target 'test/test-insets-basic.lyx', needed
>> by 'distdir'.  Stop.
>>
>
> It is a type in src/tex2lyx/Makefile:

typo: type->typo ;)

Vincent

Re: [ALPHA] Change Toggling Bug

[Vincent van Ravesteijn]

Op 5 nov. 2015 22:44 schreef "Richard Heck" :
>
> On 11/05/2015 04:02 PM, Jean-Marc Lasgouttes wrote:
>>
>> Le 05/11/15 21:41, Richard Heck a écrit :
>>>
>>> Trivial fix:
>>
>>
>> >  case LFUN_CHANGES_TRACK:
>> >  buffer_.params().track_changes =
>> > !buffer_.params().track_changes;
>> > +   buffer().markDirty();
>>
>> Va de retro, satanas! Never ever call marDirty explicitly!
>>
>> Trivial fix is to have a proper proper recordUndo call, which will as an
collateral benefit mark the buffer dirty.
>>
>> Better fix would be to move this to Buffer::dispatch too, since it
certainly does not require a bufferview.
>
>
> OK, try this one.
>
> Richard
>

The fact that the setting was set in BufferView, the fact that it didn't
call markDirty or recordUndo, all tell me that this setting was not
supposed to be a document property. It probably was stored in the file,
because there is no easy machinery at hand to store a document-specific
user preference.

Vincent

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

[Vincent van Ravesteijn]

Op 6 nov. 2015 05:44 schreef "Pavel Sanda" :
>
> Guillaume Munch wrote:
> > That "CT lock" feature, instead of imposing such a strict constraint
> > (that could always be circumvented one way or the other...), could maybe
> > display instead a message like "Pavel Sanda has requested that changes
> > be tracked. Are you sure that you want to disable change tracking?".
> >
> > But I would like to read more suggestions from you and Günter given that
> > you know better than us what you need.
>
> No need for locking. I just want to setup defaults which holds for people
> receiving the document without me explaining how they should edit it.
> If they know what they are doing (or how to do it:) they are free to
disable it.
>
> Pavel

What actually makes sense is to have a document setting like
"under_version_control". When the user opens such a document (for the first
time?) we turn on change tracking.

Important is to not save the current state of change tracking.

Vincent

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

[Vincent van Ravesteijn]

Op 4-11-2015 om 21:06 schreef Georg Baum:

Guillaume Munch wrote:


Le 03/11/2015 21:16, Georg Baum a écrit :

I don't think there is an easy solution, because it depends on the use
case. For example, in our documentation workflows \tracking_changes needs
to be the same for all users, so this should not go into the preferences.
For the other two I am not sure.


For context:

\track_changes : whether the track changes button is enabled (does not
affect the existing contents)

But it affects what happens if a change is made to the document. One author
using change tracking and the next one making changes without change
tracking is a very special case IMO. The usual case is that either all
authors or nobody uses change tracking for a particular document. For
example, in our own docs, we require everybody to use change tracking so
that the translations can be updated. Therefore it should be switched on all
the time.
I think that a regular use-case is that one author writes, and the other 
one provides feedback using track changes.


Toggling track_changes does not even mark the document as changed, so 
you cannot save it. So, when I'm ready writing and I want my 
collaborator to use track changes, I'll have turn on track changes, make 
a change, undo the change, and save.


Vincent

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

[Vincent van Ravesteijn]

On Thu, Nov 5, 2015 at 8:27 AM, Guenter Milde  wrote:
> On 2015-11-04, Georg Baum wrote:
>> Guenter Milde wrote:
>
>>> On 2015-10-30, Georg Baum wrote:
 Kornel Benko wrote:
>
 These directories are clearly not suitable for pure test files, so I'll
 need to add a new one. Would lib/tests be OK?
>
>>> If you use such a generic name, it should have sub-directories for
>
>>> * unittests
>
>> unit tests are sources which need to be compiled (except for the lyx2lyx
>> ones which do already have an own directory). I think these do not belong
>> under lib, but somewhere under src/.
>
> Agreed. OTOH, I would prefer to have tests separated from src/, so maybe
>
> lib/
> src/
> tests/
>   unittests/
>   export-tests/
>   functional/
>  tests-scripts
>  input/
>  expected/ # expected output
>  output/   # just a dir for the output, no content in the repo
>

+1

>> For now I'll simply put all files in lib/test/export (I only plan to add
>> export test for now), once we have 20 or 30 files in there we can create
>> sub-directories, and then it might also be clear how to name these.

"lib" sounds like the things we distribute as the Resource folder.

Vincent

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

[Vincent van Ravesteijn]

On Thu, Nov 5, 2015 at 7:12 AM, Pavel Sanda <sa...@lyx.org> wrote:
> Vincent van Ravesteijn wrote:
>> > I consider it also document, not user, setting. It would cause confusions
>> > if this setting is not transfered to my collaborators within the document.
>>
>> I disagree. There is no confusion possible.
>
> It is. When the document circles I want the CT be part of document
> setting not dependent whether this or another collaborator forgot
> to switch CT.
>

Maybe that could be a new feature: "Editing this document is only
allowed with track changes on. Track changes can only be turned off by
the one that "locked" the file".

Vincent

Re: [LyX/master] Math.lyx: replace tables by formal ones - final part 7/7

[Vincent van Ravesteijn]

Op 4-11-2015 om 20:15 schreef Guenter Milde:

On 2015-11-04, Kornel Benko wrote:


[-- Type: text/plain, Encoding: quoted-printable --]
Am Dienstag, 3. November 2015 um 00:23:47, schrieb Uwe Stöhr 


commit 279d0849460aac82c3adeac42d3f0e255274e7c8
Author: Uwe Stöhr 
Date:   Tue Nov 3 00:23:41 2015 +0100
 Math.lyx: replace tables by formal ones - final part 7/7



With this commit there are new failing export tests.
export/doc/Math_dvi3_texF
export/doc/Math_pdf5_texF
export/doc/de/Math_dvi3_texF
export/doc/de/Math_pdf5_texF
export/doc/es/Math_dvi3_texF
export/doc/es/Math_pdf5_texF
export/doc/fr/Math_dvi3_texF
export/doc/fr/Math_pdf5_texF
Apparently, we need more failing ...

This is both luatex export, what is the error message:

   ! Argument of \__str_case_end:nw has an extra }.
   
   \par
   l.573 \chemgreek_drop_symbols:
   
   Runaway argument?

   ! Paragraph ended before \__str_case_end:nw was complete.
   
   \par
   l.573 \chemgreek_drop_symbols:

Familiar from the XeTeX export. Same reason, incompatibility of
the chemgreek package (used by mhchem) with Xe/LuaTeX.

Math.lyx with Xe/LuaTeX is a candidate for suspension.

Günter
Besides suspending the test, we should create a specific test that tests 
the compatibility of chemgreek with Xe/LuaTeX and invert that test.


This documents the incompatibility we found, and the test will report 
whenever the incompatibility is solved.


Vincent

Re: Unit testing

[Vincent van Ravesteijn]

> If there is no known advantage of gtest, I suggest using one of
> boost::test or QTest, as these come from sources we already rely on.
>

The major advantage of "gtest" is that I only have to type "git push"
and we have the
framework up and running.

A downside of boost::test is, according someone on the internet, that
it heavily relies
on templates. This makes it slightly more difficult to debug, and
maybe slightly more
advanced usage.

All living souls on the planet already rely on Google anyhow... ;)

> However, I would also count as advantage, if there is someone familiar with
> the framework and willing to do the setup and lend a helping hand to others.
> (Maybe, the toolkit with the most developers willing to work on should win.)
>

We have discussed this topic several times, and no one ever stood up
with a strong
preference for, or claimed to have a lot of experience with one of the
frameworks.

Vincent

Re: status update on the export tests

[Vincent van Ravesteijn]

> In my view, suspension is orthogonal to reversion:
>
> - normal:  we want the test to pass
>   revert:  we want the test to fail

You mean: revert is that "it is known to fail", but we haven't fixed it yet.

>
> - normal:  run the test
>   suspend: skip the test temporarily
>   ignore:  skip the test permanently
>

Suspending means: "The outcome is noisy, so skip it until someone
looks into it and makes the test better."

Ignore: Skipping a test permanently is the same as just removing the test.. ??

Vincent

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

[Vincent van Ravesteijn]

On Wed, Nov 4, 2015 at 1:50 AM, Guillaume Munch  wrote:
> Le 03/11/2015 21:16, Georg Baum a écrit :
>>
>> Guillaume Munch wrote:
>>
>>> 
>>>
>>> I am bringing this to the list due to the timing, due to the fact that
>>> it is a file format change, and due to the fact that it looks severe in
>>> the above context.
>>>
>>> I suggest moving these settings to the user preferences.
>>>
>>> Can we agree on the issue? On the solution? Is it easy to do?
>>
>>
>> I don't think there is an easy solution, because it depends on the use
>> case.
>> For example, in our documentation workflows \tracking_changes needs to be
>> the same for all users, so this should not go into the preferences. For
>> the
>> other two I am not sure.
>>
>
> For context:
>
> \justification : whether justification is displayed in the LyX window (does
> not affect output)

user preference.

>
> \track_changes : whether the track changes button is enabled (does not
> affect the existing contents)

user-per-document preference.

>
> \output_changes : whether the changes are displayed in the output (I can
> agree that this one could be considered as part of the document.)
>

user-per-document preference.

> Also, is there a way to have settings which are per-user *and* per-file?
>

Yes, we write for instance the cursor position per file into the session file.

Vincent

Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file

[Vincent van Ravesteijn]

On Wed, Nov 4, 2015 at 7:26 AM, Pavel Sanda  wrote:
> Guillaume Munch wrote:
>> For \track_changes, I do not understand your rationale for making it a
>> setting of the document. It is not locked on, so the user who edits the
>> documentations has to know in any case that he should track changes (if I
>> had not been told to, then I'd have turned it off even if it was on).
>
> I consider it also document, not user, setting. It would cause confusions
> if this setting is not transfered to my collaborators within the document.
>

I disagree. There is no confusion possible.

If it was, then we should also make the cursor position a document
property, so my collaborator would not be confused where to start
writing ...

Vincent

Re: Unit testing

[Vincent van Ravesteijn]

>> Any comments ? Shall I proceed to push this to master ?
>>
>> Vincent
>>
>
> Having a unit test framework integrated is a very good idea!
>
> Why have you chosen gtest and not QTest? Does gtest has interesting
> features which QTest does not have?

I'm not very experienced with unit testing, so I cannot tell any
details. Someone proposed gtest a long time ago on the list, and I've
seen it being used in other projects. So, it must be good enough for
us.

>
> One benefit of QTest is that it ships with the Qt installation and
> no code has to be added to the repository.

True. Most of the added code is actually not used
(tests,samples,unused autotools/MacOs/msvc code, etc.).

>
> But knowing gtest (also integrating into a existing project)
> is also good for other non-Qt projects.

Yes, as I said, I've seen it around, more than QTest (no, I don't have
usage statistics).

Vincent

Re: Unit testing

[Vincent van Ravesteijn]

On Tue, Nov 3, 2015 at 2:28 PM, Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote:
> Le 02/11/2015 21:36, Vincent van Ravesteijn a écrit :
>>
>> Dear all,
>>
>> I have prepared a unit test framework based on google-test (gtest). You
>> can see the commits at
>>
>> http://git.lyx.org/?p=developers/vfr/lyx.git;a=shortlog;h=refs/heads/tests.
>> It includes gtest-1.7.0 (permitted by the license).
>
>
> Hi Vincent,
>
> What is the difference with the tests we current use (I mean the "make
> check" sort). The same but with better interface?
>
> JMarc
>

The current tests are all different executables, which is not really
optimal for speed in compilation and execution and has some overhead.
Now they all appear as different targets here and there. Using a test
framework also gives you a bunch of tools for writing tests (automatic
preparation and cleanup of objects, mocking, etc.). Then it gives you
the statistics and the ability to easily select tests you want to run,
etc.

Maybe, more importantly, having a proper framework may ignite the
spirit of creating tests, which then might become a new habit.

Vincent

Unit testing

[Vincent van Ravesteijn]

Dear all,

I have prepared a unit test framework based on google-test (gtest). You 
can see the commits at 
http://git.lyx.org/?p=developers/vfr/lyx.git;a=shortlog;h=refs/heads/tests. 
It includes gtest-1.7.0 (permitted by the license).


Unit testing can be enabled by running CMake with 
-DLYX_ENABLE_UNIT_TESTS. This will make a target gtest-main and 
unit-tests. It also create LyX.lib against which the unit testing 
executable is linked so that the functionality in the core can be tested.


I have created a first (example) test case in tests/src/Buffer.cpp, 
called "BufferTest", which has three tests and which is supposed to test 
the functionality of "lyx::Buffer".


A CMake target "unit-tests" now builds an executable running all 
unit-tests and gives an output as below. For each test case, there is 
also automatically a CTest created. This test runs "unit-tests 
--gtest_filter=BufferTest" and gives a summary. For more details, it is 
adviced to run the unit-tests executable directly (or improve CMake to 
capture the output somehow).


Any comments ? Shall I proceed to push this to master ?

Vincent

#ctest -N
Test project C:/Users/Vincent/Documents/LyX/build/lyx/tests
  Test #1: unit_test/src/BufferTest

Total Tests: 1

#ctest -R
Test project C:/Users/Vincent/Documents/LyX/build/lyx/tests
Start 1: unit_test/src/BufferTest
1/1 Test #1: unit_test/src/BufferTest .***Failed0.27 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) =   0.28 sec

The following tests FAILED:
  1 - unit_test/src/BufferTest (Failed)
Errors while running CTest

#unit-tests
Running main() from gtest_main.cc
[==] Running 3 tests from 1 test case.
[--] Global test environment set-up.
[--] 3 tests from BufferTest
[ RUN  ] BufferTest.NonExistingFile
[   OK ] BufferTest.NonExistingFile (0 ms)
[ RUN  ] BufferTest.NonExistingFileOperations
[   OK ] BufferTest.NonExistingFileOperations (0 ms)
[ RUN  ] BufferTest.UnicodeCharacters
..\..\..\source\gitlyx\tests\src\Buffer.cpp(45): error: Value of: 
string("C:/tés

t.lyx")
  Actual: "C:/t\xA8\xA6st.lyx"
Expected: fn1.absFileName()
Which is: "C:/t\xEF\xBF\xBD\xEF\xBF\xBDst.lyx"
[  FAILED  ] BufferTest.UnicodeCharacters (0 ms)
[--] 3 tests from BufferTest (0 ms total)

[--] Global test environment tear-down
[==] 3 tests from 1 test case ran. (0 ms total)
[  PASSED  ] 2 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] BufferTest.UnicodeCharacters

 1 FAILED TEST

Re: Upgrade to boost 1.59?

[Vincent van Ravesteijn]

On Sun, Nov 1, 2015 at 4:51 PM, Scott Kostyshak <skost...@lyx.org> wrote:
> On Sat, Oct 31, 2015 at 11:08:51PM +0100, Peter Kümmel wrote:
>> Am 25.10.2015 um 06:19 schrieb Scott Kostyshak:
>> >On Fri, Oct 23, 2015 at 06:13:03PM +0200, Vincent van Ravesteijn wrote:
>> >
>> >>I have it documented somewhere. Should I put it in development.lyx ?
>> >
>> >If you are able to find it easily then I would say yes, please do. Even
>> >though Peter already did the update it could be useful in the future.
>> >
>> >Scott
>> >
>>
>> Just call in boost extract.sh with the path to the new boot version,
>> then "git add --all", commit. That's it.
>
> Thanks, Peter. It is good to know it is so straightforward.
>
> Scott

It's only that simple if you have installed the bcp utility.

I have made a script that automatically downloads the latest boost,
unpacks the tar, compiles bcp, and uses it when running the extract
script. I'll share it later.

Vincent

Re: Compiling LyX on Windows with more recent Visual Studio versions

[Vincent van Ravesteijn]

Op 31-10-2015 om 14:44 schreef PhilipPirrip:

On 10/31/2015 09:27 AM, PhilipPirrip wrote:

Thanks, David. It did work with Qt 4.8.6
First thing I noticed, though, is that most icons are missing. Have to
investigate. I remember seeing a similar issue here on the list 
recently.


The errors reported in the message pane are of this kind
GuiApplication.cpp (635): Cannot load icon 
C:/LyX/lyx-install/Resources/images/thesaurus-entry.svgz please verify 
resource system!



Is there any special library, not mentioned in INSTALL.Win32 that 
needs to be copied somewhere? How can one force LyX to use png icons 
as a fallback?

Thnx



I'm already working on this issue.

The problem is that Qt 4.x cannot read svgz icon files where Qt 5.x can. 
There is some logic to fall back to png when the svgz file could not be 
read but this is poorly implemented and apparently untested.


Workaround would be to select classic icons in the preferences, or to 
change some occurences of "svgz,png" to "png" in the source code.


Vincent

Re: Many tex2lyx failing now on master

[Vincent van Ravesteijn]

Op 29-10-2015 om 18:33 schreef Kornel Benko:

The problem was, that cmake accumulated messages from runtests.py.
Now  runtests.py is called for each file separately.
Vincent, have you checked if that is OK to you?

Kornel


It indeed works much better.

I just don't understand what the following is supposed to do:

   string(REGEX REPLACE "\\." "_" _f "LyxTestFiles${_fl}")

_fl  is just the file names like "test.ltx", so the name of the test 
becomes "LyxTestFilestest.ltx". This name is does not look so nice, and 
there is never ever something replaced by the line above.


Vincent

Re: tests: file(TIMESTAMP ... ) requires CMake 2.8.11

[Vincent van Ravesteijn]

On Wed, Oct 28, 2015 at 10:47 PM, Kornel Benko <kor...@lyx.org> wrote:
> Am Mittwoch, 28. Oktober 2015 um 22:12:19, schrieb Vincent van Ravesteijn 
> <v...@lyx.org>
>> Using CMake version 2.8.10, all tex2lyx tests fail due to the use of
>>
>> file( TIMESTAMP .. )
>>
>> in runtests.cmake. The TIMESTAMP command is available since CMake 2.8.11.
>>
>> Vincent
>
> Hm, should we now increase the minimum required cmake version?
> Or is omitting reconfiguration for cmake versions < 2.8.11 better?
>

What about using:

if(file1 IS_NEWER_THAN file2)

?

https://cmake.org/cmake/help/v2.8.10/cmake.html#command:if

Vincent

Re: Many tex2lyx failing now on master

[Vincent van Ravesteijn]

Op 28-10-2015 om 17:02 schreef Kornel Benko:

It looks like the relevant code to set environment for tests added by 
add_test() command
is in the cmake-sources at lest since february 2009. Searching the net, there 
are posts
mentioning cmake2.6 with this feature.

So I cannot imagine, why the patch should break anything on linux. But it may 
help for Windows.
(new file env_custom_command.cmake belongs to src/tex2lyx/test/ dir)




It seems to work for me.

While running updatetex2lyxtest:

algo2e.tex":
  Ignoring options 'boxed' of package algorithm2e.

test-insets.tex:
  warning : Could not find included file 'Dummy Document.tex'. (2x)
  warning : Could not find included file 'Dummy"Document.tex'.
  warning : Could not find included file 'foo'. (2x)
..\..\..\source\gitlyx\src\output_latex.cpp (1193): Error in 
latexParagraphs: You should not mix title layouts with normal ones.


test-insets-basic.tex:
  warning : Could not find included file 'Dummy Document.tex'. (2x)

Besides these I get a few messages saying foo.pdf already exists, Do 
you want to overwrite ?  Shouldn't this be written automatically given 
-f flag ?


Except for the gnumeric stuff, it all seems to work. It is only a bit 
annoying that I have to wait for a long time without getting any 
feedback on the progress.


Vincent

check_lstrings fails at Windows

[Vincent van Ravesteijn]

The entries that are different from the test_lstrings reference file are 
for the inputs


{
...
1.3754937356458394574047e17,
1.3754937356458394574047e18,
1.3754937356458394574047e19,
1.3754937356458394574047e20,
...
1e42
}

and the outputs are:

{
...
137549373564583950
1375493735645839400
13754937356458394000
13754937356458395
...
10001
}

The same entries also fail for the negated case.

Vincent

tests: file(TIMESTAMP ... ) requires CMake 2.8.11

[Vincent van Ravesteijn]

Using CMake version 2.8.10, all tex2lyx tests fail due to the use of

file( TIMESTAMP .. )

in runtests.cmake. The TIMESTAMP command is available since CMake 2.8.11.

Vincent

Re: Many tex2lyx failing now on master

[Vincent van Ravesteijn]

> > It is only a bit
> > annoying that I have to wait for a long time without getting any
> > feedback on the progress.
> >
> > Vincent
> >
>
> I don't feel guilty. I don't remember anyone saying anything about the
'env' command before.
>
> What do you mean with feedback about progress?
>
> Probably memory fading.
>
> Kornel

I don't mean you.

I mean that I don't get any response while running the updatetex2lyxtests
target, which causes me to wonder whether it is doing anything. Msvc
thingie probably.

Last I removed the git ls-files warning from the source as these error
messages seem to cause the deadlock in tex2lyx.

Vincent

Re: [patch] update modernCV layout file

[Vincent van Ravesteijn]

On Tue, Oct 27, 2015 at 12:56 AM, Uwe Stöhr  wrote:
> Am 26.10.2015 um 16:51 schrieb Stephan Witt:
>
>> You missed the "Change to the build-directory." part of Kornels advice.
>>
>> I think "D:\LyXGit\Master\lib\examples" isn't your build directory or at
>> least it shouldn't be so.
>
>
> Thanks for this pointer. This works somehow but I still don't see if a test
> was passed or not. I only get this:
>
> D:\LyXGit\Master\compile-result>ctest -N
> Test project D:/LyXGit/Master/compile-result
>   Test   #1: frontends/test_biblio
>   Test   #2: support/convert
>   Test   #3: support/filetools
>   Test   #4: support/lstrings
>   Test   #5: support/trivstring
>   Test   #6: tex2lyx/roundtrip/test.ltx
>   Test   #7: tex2lyx/cmplyx/test.ltx
>   Test   #8: tex2lyx/roundtrip/algo2e.tex
> ...
>   Test #199: lyx2lyx/parser_tools
> Total Tests: 199
>
> Where is the result?

As Kornel said, "ctest -N" is to see all tests, which means that they
are not run. Next, he said to use "ctest" to run all tests.

>
> Now I want to test modernCV.lyx as proposed by Scott then I get
>
> D:\LyXGit\Master\compile-result>ctest -R "modernCV"
> Test project D:/LyXGit/Master/compile-result
> No tests were found!!!
>
> I find modernCV.lyx in a subfolder and switching to t and repeat doesn't
> help:
>
> D:\LyXGit\Master\compile-result\LYX_INSTALLED\Resources\examples>ctest -R
> "modernCV"
> Test project
> D:/LyXGit/Master/compile-result/LYX_INSTALLED/Resources/examples
> No tests were found!!!
>

If you would scroll back to the output of the "ctest -N" command, you
will find the test for modernCV:

...
Test #111: check_layout/moderncv.layout
...

If you then want to run this test you do:

"ctest -R check_layout/moderncv.layout"

As the last argument is actually interpreted as a regular expression,
you can use the shorter way:

"ctest -R moderncv"

Please note that you have to write "moderncv" in lower case, otherwise
it doesn't work. I'm not sure
why it works on linux with uppercase as well.

Besides this, I have to add "-C debug"  or "-C release" to avoid the
error "Test not available without
configuration. (Missing "-C "?)".

So, to conclude, you should be able to run the test using:

"ctest -R moderncv -C debug" or "ctest -R moderncv -C release"


>>> If things are that easy why can't they be documented? That is why we have
>>> the Development.lyx file, no? There ctest is not mentioned.

I guess Development.lyx is rather new, I've not seen it yet.

>
> The point is that nothing is documented but people tell me what I make
> wrong. I feel like sitting behind a high wall of tests hindering me
> providing new features, even simple ones like layout improvements. And that
> is frustrating! I mean I can now not even do a simple fileformat change to
> change a module because I cannot run required tests. I am an experienced
> LyXer but it was never so complicated to contribute to LyX.
> This is a bad development in my opinion because we need devels on Windows.
>

I completely agree with you: if the tests are cannot be run easily for
all of us, it is unfair to
require to run the tests before committing everything. A test suite
with 6000 tests, that runs
for several days, requiring all possible kinds of dependencies, and
using a lot of linux-specific
scripting will not be very useful as a test that all developers should
run before each commit.

On the other hand, it is fair to make developers responsible for their
own commits. So, if
it can be avoided that a bug is introduced by running a single command
from the command line,
it makes sense to expect this from the developer.

Vincent

Re: [patch] update modernCV layout file

[Vincent van Ravesteijn]

>
> The same is with updating the tex2lyx reference files. I asked on the list
> but got not reply how I can do this:
> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg189509.html
>

Yes, sorry that it took me a few days to take up the issue. The others
probably have a hard time debugging what can go wrong on Windows.

>
> p.s. please don't copy all text of previous posts to your ones, only the
> parts you are referring.

Yes, I know, but it is a very tedious job to remove pages of text
using the mobile app. And the app conveniently hides all cited text,
so I don't even see it myself.

Vincent

Re: Many tex2lyx failing now on master

[Vincent van Ravesteijn]

>>
>> Well yes, there is no "env" command on Windows.
>
> Sorry, I did not knew about this.
>
>> This is used in both  "src/tests/CMakeLists.txt"  and
>> "src/tex2lyx/CMakeLists.txt".
>
> I will look into this. Unfortunately the 'add_test()' command does hot have a 
> parameter to set the environment.
> Probably I have to create a cmake script for this :(

>From CMake version 3.0.something and higher you can use:

${CMAKE_COMMAND} -E env NAME=VALUE COMMAND (with COMMAND=python
runtests... etc.)

For lower versions of CMake (we say we support from 2.6.8 IIRC), I
didn't find a solution.

>
>> Besides that, running is a nightmare:
>> - Somehow tex2lyx often deadlocks when outputting errors,
>
> It never happened on linux. 'tex2lyx' tests are run sequentially, so I didn't 
> see possible deadlocks ...

I don't know. It just gets stuck in SystemCall::stderr ...

>
>> - I need to have python in the path,
>
> It should be the same 'python' as found in the configuration phase. Why the 
> need for PATH, I don't understand
> (I mean in the tex2lyx tests, have I lost track?)
>
>> - It complains about not finding git to run "git ls-files"
>
> Where? This command-parameter is under linux not valid. I did not see it.

During the execution of updatetex2lyxtests, it complains about git...
not a big issue, but polluting the output and it seems a bit non-sense
as I don't have a GUI. Maybe something to fix some time.

>
>> - I need ssconvert for Gnumeric

These were errors during the execution of updatetex2lyxtests. It is a
bit strange I need 3rd party dependencies for testing tex2lyx.

>> - It complains that I cannot convert fig formats to pdftex
>> - and more.

Again, these were errors during the execution of updatetex2lyxtests.

Vincent

Re: Many tex2lyx failing now on master

[Vincent van Ravesteijn]

When I try to compile this file via the console or directly in MSVC I 
get always this error:


Building Custom Rule D:/LyXGit/Master/src/tex2lyx/test/CMakeLists.txt 
CMake does not need to re-run because 
D:\LyXGit\Master\compile-result\src\tex2lyx\test\CMakeFiles\generate.stamp 
is up-to-date.

Generating LyxTestFiles
The command "env" is either misspelled or could not be found
C:\Program Files 
(x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): 
error MSB6006: "cmd.exe" was finished with code 9009


Vincent, do you perhaps have an idea?


Well yes, there is no "env" command on Windows.

This is used in both  "src/tests/CMakeLists.txt"  and 
"src/tex2lyx/CMakeLists.txt".


Besides that, running is a nightmare:
- Somehow tex2lyx often deadlocks when outputting errors,
- I need to have python in the path,
- It complains about not finding git to run "git ls-files"
- I need ssconvert for Gnumeric
- It complains that I cannot convert fig formats to pdftex
- and more.

Vincent

Re: [patch] update modernCV layout file

[Vincent van Ravesteijn]

Op 26 okt. 2015 14:10 schreef "Uwe Stöhr" :
>
> Am 26.10.2015 um 06:31 schrieb Scott Kostyshak:
>
>>> I think it is safe enough to support 2 years old features and would
>>> therefore like to put it in.
>>
>>
>> Do we have any policy on this? What have we done in the past?
>
>
> No strict one, but the feature should be at least in the current and
previous TeXLive as far as I remember.
> This is be the case here.
>
>
>>> Since a style is added, this would be a simple fileformat change.
>>>
>>> OK to go on?
>>
>>
>> Uwe have you tried to run the tests yet? Can you please navigate to your
>> build directory and run the command
>>
>> ctest -R "modernCV"
>
> >
>>
>> before and after you apply the patch. Do the results change at all?
>
>
> What does ctest do? There is nothing abut it in the Development.lyx file.
Could you please add it there?
>
> I cannot find a command ctest to execute. How can or should I execute it?
>

We have explained you this more than 2.5 years ago (see the link below).
Since then the tex2lyx and export tests have been a recurring topic on the
list.

https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg177032.html

Vincent

Re: [LyX/master] colored-boxes.lyx: new example file for the tcolorbox.module

[Vincent van Ravesteijn]

Op 25-10-2015 om 22:12 schreef Uwe Stöhr:

Am 25.10.2015 um 11:08 schrieb Georg Baum:

And if something is wrong with them, we should invest the time and 
improve

our formatted references support, instead of fiddling with the premable.


I set up
www.lyx.org/trac/ticket/9817
for this issue.

And no, using a feature of a well-known package like hyperref is not 
fiddling. I know the hyperref author personally and it was him who 
gave me the hint to use \autoref. Thus please be fair in judging me as 
"fiddler". Moreover, this preamble code is in the docs since about 10 
years.


Uwe


Why do you choose the option by which you feel offended ? Georg just 
considers to improve the support, so maybe to teach LyX about autoref, 
instead of using preamble code. He does not judge you.


Vincent

Re: Minimum compiler version

[Vincent van Ravesteijn]

Op 24-10-2015 om 7:13 schreef Peter Kümmel:



Am 23.10.2015 um 21:34 schrieb Vincent van Ravesteijn:

support of MSVC2010.


I think I don't need to tell Peter about MSVC support for
C++11 (I guess he knows better than me).

The message was really meant for you: if you introduce C++11
features that cannot compile on MSVC, you will meet some
resistance.



So only you insist on MSVC2010 support?

Peter


I thought we always wanted to support as many compilers as reasonably 
possible in order to allow newcomers to easily compile LyX and to let 
them contribute. Does it make sense to still support Qt 4.5, but to 
require the last version of the Microsoft compiler ?


Vincent

Re: back to LyX and therefore questions concerning LyX 2.2

[Vincent van Ravesteijn]

Op 24 okt. 2015 20:42 schreef "Uwe Stöhr" :
>
> Am 23.10.2015 um 10:25 schrieb Jean-Marc Lasgouttes:
>
>> If you look closely, they are not closer than the vertival line over B_V
>> is fromthe text. Seriously this is a much bigger problem
>
>
> But it still doesn't look as good as with \raisebox in my opinion.
>
>
>>> Besides this, if you prefer formal tables, no problem (the Math
>>> manual was written before this feature was available).
>>
>>
>> Yes, I would really propose that we use formal tables all over the
>> documents.
>
>
> OK, I will do this in the math manual when I find time.
>
>
>> It would be nice if the use of formal tables was described as the good
>> choice, and the culprits of normal tables with vertical lines discussed.
>> Where are these formal tables discussed, actually?
>
>
> In the EmbeddedObjects manual, sec. 2.9 and NOT in the UserGuide.
> As long as our default are non-formal tables I would not advertise formal
tables as the better solution.
> Note that the vast majority of the world's computer users are used to
Excel and Word tables and they are not formal. Even in many scientific
publications formal tables are not used. So for most users formal tables
are something special. I remember that I needed some time until I liked
them.
>
>
>>> That the tables are not floating is on purpose. I once tried floats
>>> and went crazy to get an acceptable PDF output.
>>
>>
>> Well, I am a believer in floating floats, but let's keep this point for
>> later :)
>
>
> Me too but LaTeX's float mechanism breaks if there are too many floats.
There is some literature about this topic and some suggest to omit floating
if one cannot allow the objects to float. This is the case in the math
manual.
>

Hmm we, as the experts, should not set the bad example. The fact that LyX's
docs don't use floats will be used by the unbelievers as an argument
against it.

Vincent

Re: Upgrade to boost 1.59?

[Vincent van Ravesteijn]

Op 23 okt. 2015 17:37 schreef "Jean-Marc Lasgouttes" :
>
> I think we should upgrade our local copy of boost to 1.59 before alpha
(or at least before beta).
>
> Is the procedure documented somewhere?
>
> Also, what can we do to hide the warnings related to auto_ptr? If we are
out of ideas, I propose to compile with -Wno-deprecated-functions in C++11
mode.
>
> JMarc

I have it documented somewhere. Should I put it in development.lyx ?

Vincent

Re: Minimum compiler version

[Vincent van Ravesteijn]

Op 23-10-2015 om 20:55 schreef Guillaume Munch:

Le 23/10/2015 17:55, Peter Kümmel a écrit :

I wonder to still see auto_ptr:

https://travis-ci.org/syntheticpp/lyx

Which old compiler you wanna support?

Peter




Dear Peter,


See 
and subsequent messages. The only concrete example was Jean-Marc's OSX
10.7 computer, although in this case there is a straightfoward fix
according to Google.

Another argument in favour of keeping C++98 seemed to be that
backporting from C++11 to C++98 is supposed to be effortless (which
makes me wonder why C++11 was at all invented). However the discussion
about allowing Unicode string literals clearly showed the contrary:
.

The overall discussion about C++11 was rather unconvincing, and as a
consequence I have already decided to use C++11 features without
restraint starting from 2.3, and not to make a single non-trivial effort
at possible backports into 2.2 of any of my patches. One cannot claim
one day that LyX is short in developer time, and another day that
increasing backporting efforts is without consequences. This makes me
hope that this 2.2 version will be short-lived (however impatient I am
to see it out).

Guillaume


Well, I probably can wake you from your dreams of C++11 quickly when I 
try compiling your C++11 features with MSVC2010...


Vincent

Re: back to LyX and therefore questions concerning LyX 2.2

[Vincent van Ravesteijn]

Op 23-10-2015 om 9:15 schreef Pavel Sanda:
So back to Uwe's question, it would be good you announce at some point 
- features won't change ( except of bugfixing ) - translatable strings 
are not going to be changed (except obvious bugs/typos). and maybe 
give some hint when this might occur :)


I assume that people will not start changing strings for fun when we are 
in the feature freeze phase. So I expect hardly any string changes then. 
And when there is a serious reason for changing a string, it can 
probably be adjusted anyway in the translations/docs, but maybe with a 
little more effort.


IMO, a separate hard string freeze is not needed as long as we act 
reasonable.


Vincent

Re: Minimum compiler version

[Vincent van Ravesteijn]

Op 23-10-2015 om 21:22 schreef Guillaume Munch:

Le 23/10/2015 20:16, Vincent van Ravesteijn a écrit :

Op 23-10-2015 om 20:55 schreef Guillaume Munch:

Le 23/10/2015 17:55, Peter Kümmel a écrit :

I wonder to still see auto_ptr:

https://travis-ci.org/syntheticpp/lyx

Which old compiler you wanna support?

Peter




Dear Peter,


See <http://mid.gmane.org/326d2a33-d65f-488d-9bc3-5331535a4...@lyx.org>
and subsequent messages. The only concrete example was Jean-Marc's OSX
10.7 computer, although in this case there is a straightfoward fix
according to Google.

Another argument in favour of keeping C++98 seemed to be that
backporting from C++11 to C++98 is supposed to be effortless (which
makes me wonder why C++11 was at all invented). However the discussion
about allowing Unicode string literals clearly showed the contrary:
<http://mid.gmane.org/mv8skg$jb7$1...@ger.gmane.org>.

The overall discussion about C++11 was rather unconvincing, and as a
consequence I have already decided to use C++11 features without
restraint starting from 2.3, and not to make a single non-trivial 
effort

at possible backports into 2.2 of any of my patches. One cannot claim
one day that LyX is short in developer time, and another day that
increasing backporting efforts is without consequences. This makes me
hope that this 2.2 version will be short-lived (however impatient I am
to see it out).

Guillaume


Well, I probably can wake you from your dreams of C++11 quickly when I
try compiling your C++11 features with MSVC2010...

Vincent





I think that your message was meant as an answer Peter's question 
explaining that for some reason you need the support of MSVC2010.


I think I don't need to tell Peter about MSVC support for C++11 (I guess 
he knows better than me).


The message was really meant for you: if you introduce C++11 features 
that cannot compile on MSVC, you will meet some resistance.


Vincent

Re: back to LyX and therefore questions concerning LyX 2.2

[Vincent van Ravesteijn]

On Thu, Oct 22, 2015 at 7:13 AM, Scott Kostyshak  wrote:
> On Mon, Oct 19, 2015 at 04:33:43PM +0200, Uwe Stöhr wrote:
>> Dear LyXers,
>>
>> I would like to have a beta release short after the feature-freeze.
>> During the beta and RC-cycle the docs will be updated because this
>> usually takes some weeks.
>
> Sounds good to me.

IMO, it sounds a bit weird to me to have a beta release short after a
feature freeze without considering the state of the codebase. I guess
you announce a feature freeze, after which all devs will focus on
improving the quality of the codebase until a certain level is reached
at which a beta can be released. A feature freeze is just meant to
bundle the devs' energy to focus on bugfixing and polishing existing
features, and to make sure that not one part of the devs are doing the
hard work on fixing bugs while the other half is introducing new ones.

>>
>> - Will there be a code-freeze after that strings can still be changed?
>
> Is this what is normally done? I'm new at this.

I've actually no clue what is meant with a code freeze after that
strings an be changed ?

Vincent

Re: LyX's master is now uncompilable

[Vincent van Ravesteijn]

Op 19-10-2015 om 23:36 schreef Guillaume Munch:

Le 19/10/2015 21:59, Vincent van Ravesteijn a écrit :


Op 19 okt. 2015 22:51 schreef "Guillaume Munch" <g...@lyx.org
<mailto:g...@lyx.org>>:
 >
 > Le 19/10/2015 21:34, Georg Baum a écrit :
 >>
 >>
 >> The message on the list is related to commit e948caf6, which is
supposed to
 >> fix exactly this issue. What I do not understand it why the fix 
does not
 >> work for your recent changes. Maybe you forgot to include 
docstream.h

 >> somewhere or got the include order wrong?
 >
 >
 > The former. If we are supposed to include support/docstream.h to use
odocstringstream, shouldn't the latter be defined in docstream.h instead
of strfwd.h? (or the fix be moved to strfwd.h which is already included
by docstream.h via docstring.h?)
 >
 > I am tempted to do the proper fix, but since I do not own MSVC,
people would have to bear with me if this breaks compilation 
temporarily.

 >

If you post the fix to the list here, I will try it tomorrow, and if it
works, I will commit.


Unfortunately, the patch doesn't work.

"docstring.h" includes "strfwd.h", which now includes 
"numpunct_lyx_char_type.h", which uses "from_ascii", which is defined in 
"docstring.h".


Vincent

Re: LyX's master is now uncompilable

[Vincent van Ravesteijn]

Op 20-10-2015 om 20:06 schreef Georg Baum:

Guillaume Munch wrote:


I'll let Vincent decide whether he wants to make this change.

Sure, our messages crossed each other, I would not have suggested that if I
knew that he had time to test.

The compilation error could btw easily be fixed by moving the implementation
of the methods in a .cpp file (I would suggest to use
src/support/docstream.cpp where id is already implemented, since adding a
new .cpp would not be trivial: It would not need to be compiled on unix for
example).


Ok, that's what I did.

Vincent

Re: When to court Qt 5.6?

[Vincent van Ravesteijn]

Op 15 okt. 2015 08:37 schreef "Jean-Marc Lasgouttes" :
>
> Le 15/10/15 01:06, Scott Kostyshak a écrit :
>
>> LyX 2.2.0 and the following 2.2.x releases will still continue to work
>> well with Qt 4.8.6 but will also support Qt 5.6, which brings some
>> advantages most notably for users with HiDPI displays. Note that if you
>> compile LyX with a Qt 5 release before 5.6 you are likely to run into
>> several regressions with respect to Qt 4.8.6. See #9215 for a list of
>> bugs related to compiling LyX with different versions of Qt.
>
>
> The minimum Qt version is actually 4.5, although I do not know who is
able to check that. I could try to test it in a virtual machine, though.
>
> JMarc
>

I use Qt 4.8.? but I have problems with the code to read icons. I cannot
read svgz pixmaps, and GuiApplication::iconName only looks whether a file
exists but does not take into account whether a certain file is readable.

I want to fix this soon.

Vincent

Re: When to court Qt 5.6?

[Vincent van Ravesteijn]

Op 20 okt. 2015 02:32 schreef "Uwe Stöhr" :
>
> Am 15.10.2015 um 01:18 schrieb Scott Kostyshak:
>
>> Uwe can you confirm that shipping our alpha with Qt 5.6 beta is
>> feasible for you?
>
>
> Hi Scott,
>
> I am open for anything. I think that i will need in any case some help
from Vincent - in the past some Win-only changes were required to be able
to compile with new Qt versions.
>
> Besides this I am still using MSVC 2010. I need to update to MSVC 2012 or
newer and this is another challenge. I already tested MSVC 2012 with Qt 5.5
with success. Let's see what Qt 5.6 supports and if I can then still
compile LyX 2.1.x with Qt 4.x and MSVC 2010 on the same PC.
>
> regards Uwe

Why do you need to update to MSVC 2012 ? Qt 5.5 was still released with
2010 libraries. Given the fact that some of our dependencies are also built
with 2010, it looks safest not to switch versions right now.

Vincent

Re: When to court Qt 5.6?

[Vincent van Ravesteijn]

Op 20 okt. 2015 20:35 schreef "Georg Baum" :
>
> Uwe Stöhr wrote:
>
> > Besides this I am still using MSVC 2010. I need to update to MSVC 2012
> > or newer and this is another challenge. I already tested MSVC 2012 with
> > Qt 5.5 with success. Let's see what Qt 5.6 supports and if I can then
> > still compile LyX 2.1.x with Qt 4.x and MSVC 2010 on the same PC.
>
> I would suggest to use the newest stable version, with is currently MSVC
> 2015. Then you need to update and adjust to changes look and feel less
> often.
>
> In general, installing two MSVC versions in parallel is no problem, the
same
> is true for qt. The only thing you need to make sure is that none of these
> versions is listed in the PATH or other environment variables. Then you
can
> use two build.bat files for the two versions, and set all needed
environment
> variables (e.g. adding the qt bin dir to PATH for moc etc) separate in
these
> two files.
>
> Furthermore, a new MSVC version requires a new dependency package. As I
> already wrote to David Hyde (who wants to compile LyX with a newer MSVC),
I
> think that the current procedure of providing the binaries for a sepcific
> MSVC version produces too much work in the long run. Instead, a python or
> cmake script to download the sources of the dependencies and compile them
> should be written. This is more effort initially, but pays off in the long
> term, and also removes some pressure from you, since others can then
create
> the dependencies they need without manual work for you.
>
>
> Georg
>

First, it looks like that the 2010 libraries can work with at least MSVC
2012. Is that because MSVC 2010 is or was also installed on the same
machine? If so, releasing such a hybrid might give troubles that won't be
foreseen. So, better to warn Uwe as he claims to have tested with MSVC 2012
and Qt 5.5.

Second, I guess it's up to me to figure out compiling the dependencies. I
remember that Joost had manually changed gettext to be able to make
suitable libraries. Did we get rid of gettext libs completely or do we
still need it (besides the msgmerge and friends applications) ?

It's a good idea to update cmake to download the sources.

Vincent

Re: Where is the script that posts to lyx-cvs?

[Vincent van Ravesteijn]

On Mon, Oct 19, 2015 at 1:38 PM, Jean-Marc Lasgouttes
 wrote:
>
> The title says it all. I'd like to add some header in there that the lyx-cvs
> list can use to allow the message, instead of restricting to subscribers.
>
> JMarc

It is in a git hook in a script called .git/hooks/post-receive or
post-commit or something like that. This is in the .git directory on
the server.

Vincent

Re: LyX's master is now uncompilable

[Vincent van Ravesteijn]

Op 19 okt. 2015 22:51 schreef "Guillaume Munch" :
>
> Le 19/10/2015 21:34, Georg Baum a écrit :
>>
>>
>> The message on the list is related to commit e948caf6, which is supposed
to
>> fix exactly this issue. What I do not understand it why the fix does not
>> work for your recent changes. Maybe you forgot to include docstream.h
>> somewhere or got the include order wrong?
>
>
> The former. If we are supposed to include support/docstream.h to use
odocstringstream, shouldn't the latter be defined in docstream.h instead of
strfwd.h? (or the fix be moved to strfwd.h which is already included by
docstream.h via docstring.h?)
>
> I am tempted to do the proper fix, but since I do not own MSVC, people
would have to bear with me if this breaks compilation temporarily.
>

If you post the fix to the list here, I will try it tomorrow, and if it
works, I will commit.

Vincent

Re: [LyX/master] cmake: Put updatetex2lyxtests in an appropriate folder

[Vincent van Ravesteijn]

Op 19-10-2015 om 18:45 schreef Kornel Benko:

Am Montag, 19. Oktober 2015 um 18:02:02, schrieb Vincent van Ravesteijn 
<v...@lyx.org>

commit 92b7c5a92f21956f6da19c8ac783cd9132ca82b9
Author: Vincent van Ravesteijn <v...@lyx.org>
Date:   Mon Oct 19 17:50:59 2015 +0200

 cmake: Put updatetex2lyxtests in an appropriate folder

diff --git a/src/tex2lyx/test/CMakeLists.txt b/src/tex2lyx/test/CMakeLists.txt
index e11b345..c513d6e 100644
--- a/src/tex2lyx/test/CMakeLists.txt
+++ b/src/tex2lyx/test/CMakeLists.txt
@@ -71,3 +71,4 @@ add_custom_command(
  )
  
  add_custom_target(updatetex2lyxtests DEPENDS LyxTestFiles)

+set_target_properties(updatetex2lyxtests PROPERTIES FOLDER "tests/tex2lyx")

Why is that important? This is only a phony target ..., there should be no data in the 
specified "tests/tex2lyx" folder.
In fact, there is no such folder on my platform.

Kornel


All (phony) build targets in an MSVC solution are shown in a tree 
structure. Proper organization of the targets does not clutter everything.


Vincent

Re: LyX's master is now uncompilable

[Vincent van Ravesteijn]

Op 19-10-2015 om 19:04 schreef Uwe Stöhr:

Am 19.10.2015 um 18:26 schrieb Guillaume Munch:


I fail to see a problem with this commit after reading it again. I would
like to do some trial-and-error but not being able to reproduce makes it
complicated.


It is also not clear to me what triggers the error.


I fixed it at 10d7f6d.

Vincent

Re: [LyX/master] chkconfig.ltx: add packages supported by LyX

[Vincent van Ravesteijn]

Op 18-10-2015 om 15:21 schreef Uwe Stöhr:

commit c246ca2d43663dbce3d3052b2ae9459b45bf4acc
Author: Uwe Stöhr 
Date:   Sun Oct 18 15:21:50 2015 +0200

 chkconfig.ltx: add packages supported by LyX
 
 - also update Win installer package list (trimspaces is required by tcolorbox but not listed as required in the tcolorbox manual)


diff --git a/lib/chkconfig.ltx b/lib/chkconfig.ltx
index 86cef0c..b0f3cd4 100644
--- a/lib/chkconfig.ltx
+++ b/lib/chkconfig.ltx
@@ -268,6 +268,7 @@
  
  
  %%% Packages

+\TestPackage[a0poster}
...
+\TestPackage[sciposter}
...
+\TestPackage[wallpaper}


Uwe,

It looks to me that the rectangular brackets should be replaced by curly 
braces.


Vincent

Re: [LyX/master] Fix typo

[Vincent van Ravesteijn]

On Tue, Oct 13, 2015 at 8:45 AM, Jean-Marc Lasgouttes
 wrote:
> Le 13/10/15 02:08, Scott Kostyshak a écrit :
>>
>> On Mon, Oct 12, 2015 at 11:49:42AM +0200, Jean-Marc Lasgouttes wrote:
>>>
>>> Le 12/10/2015 11:16, Stephan Witt a écrit :

 Am 12.10.2015 um 11:04 schrieb Jean-Marc Lasgouttes
 :

> Le 10/10/2015 21:31, Stephan Witt a écrit :
>>
>> Another question with "dead store" code is in RowPainter::paintFirst:
>>
>> The y_top assignments are not used.
>> JMarc, do you know if the code block simply can be removed?
>
>
> The code was already like that in 2.1.


 Yes, it dates back to at least 2007. Earlier I couldn't "git blame"
 anymore.
>>>
>>>
>>> I found the same. Who has a good tutorial about git archeology?
>>
>>
>> How about the following?
>>
>>git log -Sy_top
>
>
> I did that, but the problem was with renames. The best I could come up with
> is
>

I don't see the problem. For me it goes back to the "Initial revision"
by LGB in 1999.



Anyway, the _usage_ of y_top was removed at:

7de76711 (http://git.lyx.org/?p=lyx.git;a=commitdiff;h=7de76711#patch35)
8c8e438e4 
(http://git.lyx.org/?p=lyx.git;a=commitdiff;h=8c8e438e4cb0d2209cd9fc1990041c17028f3ff8;hp=318bdb52f3ecfd2c2f1ef5bd9f7dcfa4a5ad8edd).

Vincent

Re: [LyX/master] Comply with rule-of-three

[Vincent van Ravesteijn]

Op 12-10-2015 om 4:17 schreef Scott Kostyshak:

On Sun, Oct 11, 2015 at 11:20:15AM +0200, Georg Baum wrote:

commit cea2d71e641e6a4023128a367d1cd5a593ed1706
Author: Georg Baum 
Date:   Sun Oct 11 11:16:09 2015 +0200

 Comply with rule-of-three
 
 The rule-of-three says that if any of virtual destructor, copy constructor

 or assignment operator needs to be manually implemented, then all three
 should be implemented. Otherwise you can get subtle bugs which can be
 difficult to find. In the changed classes, changing a copy-construction to
 an assignment would have had surprising effects. Now they all behave
 consistently.


What about declaring the unimplemented 'others' as private, but leaving 
them unimplemented (if possible) ? This prevents adding unused code to 
the codebase.


I've seen that approach to comply to the rule.

Vincent

Re: When to court Qt 5.6?

[Vincent van Ravesteijn]

Op 12 okt. 2015 15:14 schreef "Liviu Andronic" :
>
> On Mon, Oct 12, 2015 at 1:39 PM, Jean-Marc Lasgouttes
>  wrote:
> > Le 12/10/2015 12:45, Liviu Andronic a écrit :
> >>
> >> True. :) What is the current minimum Qt 5.x requirement?
> >
> >
> > I do not think that there is any strong requirement. The problem is
more in
> > Qt5 bugs that this may expose.
> >
> For what it's worth, it doesn't seem like we officially support Qt 5.x
> just yet. From the release notes:
> "Changes with respect to external programs and libraries in 2.2:
> LyX is not yet supposed to work with Qt5. It is advised to compile and
> run LyX against Qt 4.8.x. On Windows Qt 4.8.6 or newer is advised."
>
> Which means that my concerns about Qt 5.6 were a tad premature...
>

I guess that the release notes for 2.2 needs to be reconsidered anyhow.
This excerpt was just copied from the 2.1 release notes. IIRC

Vincent

Re: Failing tex2lyx tests

[Vincent van Ravesteijn]

On Wed, May 20, 2015 at 12:24 AM, Uwe Stöhr uwesto...@web.de wrote:
 Am 19.05.2015 um 21:20 schrieb Georg Baum:

 unfortunately the tex2lyx test failures increased (see attachment). Are
 you
 aware that this wastes time of developers? Did you see the questions Scott
 ansd I asked about the failing tests?


 Fiddling
 around with the command line is very annoying.
 Currently for me the most convenient way to test is to drop the TeX file
 into LyX (compiled in debug mode) and then look at the errors in LyX's
 console window.


That's the problem. The thing to be tested is not whether LyX can
import without errors, but it is that the resultant LyX file is
_identical_ to the LyX file that is in the repository.

If you add extra test cases in the tex file, you should make sure that
the accompanying LyX file (i.e. the reference) is edited such that it
resembles what the imported tex file should be in LyX.

Vincent

Re: Failing tex2lyx tests

[Vincent van Ravesteijn]

On Wed, May 20, 2015 at 12:24 AM, Uwe Stöhr  wrote:
> Am 19.05.2015 um 21:20 schrieb Georg Baum:
>
>> unfortunately the tex2lyx test failures increased (see attachment). Are
>> you
>> aware that this wastes time of developers? Did you see the questions Scott
>> ansd I asked about the failing tests?
>
>
> Fiddling
> around with the command line is very annoying.
> Currently for me the most convenient way to test is to drop the TeX file
> into LyX (compiled in debug mode) and then look at the errors in LyX's
> console window.
>

That's the problem. The thing to be tested is not whether LyX can
import without errors, but it is that the resultant LyX file is
_identical_ to the LyX file that is in the repository.

If you add extra test cases in the tex file, you should make sure that
the accompanying LyX file (i.e. the reference) is edited such that it
resembles what the imported tex file should be in LyX.

Vincent

New requirement: X11/Intrisic.h

[Vincent van Ravesteijn]

Since commit ([52fee355/lyxgit]; Fix external middle-mouse pasting
with Qt5/X11), I need X11/Intrinsic.h for which I had to install the
package libxt-devel.

Does this need a check in configure.ac ?, and/or a note in the RELEASE_NOTES ?

Vincent

Re: [LyX/master] Make RELEASE-NOTES accessible from GUI (#8616)

[Vincent van Ravesteijn]

On Tue, May 19, 2015 at 9:59 AM, Juergen Spitzmueller sp...@lyx.org wrote:
 commit 9f55ce9b04c1786c5bed52afc9028f287d28bb32
 Author: Juergen Spitzmueller sp...@lyx.org
 Date:   Tue May 19 09:57:52 2015 +0200

 Make RELEASE-NOTES accessible from GUI (#8616)

 CMake people, please check if something needs to be done to install
 lib/RELEASE-NOTES.


Shall we leave behind the original RELEASE-NOTES file with the text:
The RELEASE-NOTES can be found in lib/RELEASE-NOTES. ?

People probably are used to look for the RELEASE-NOTES in the main
directory, and we do not have the possibility of attending them to
this change by putting something in the release notes :S..

Vincent

Re: [LyX/master] Add Qt's Svg module to the list of used modules. This is required to allow the use of e.g. the QSvgRenderer class.

[Vincent van Ravesteijn]

Stephan Witt schreef op 19-5-2015 om 22:48:

commit 0933df00113ee2735699c13559ad3b6e7e9fd115
Author: Stephan Witt sw...@lyx.org
Date:   Tue May 19 08:11:01 2015 +0200

 Add Qt's Svg module to the list of used modules. This is required to allow 
the use of e.g. the QSvgRenderer class.



Is  it worth pulling in the QtSvg dependency just to show a nicer banner ?

Vincent

New requirement: X11/Intrisic.h

[Vincent van Ravesteijn]

Since commit ([52fee355/lyxgit]; "Fix external middle-mouse pasting
with Qt5/X11"), I need X11/Intrinsic.h for which I had to install the
package libxt-devel.

Does this need a check in configure.ac ?, and/or a note in the RELEASE_NOTES ?

Vincent

Re: [LyX/master] Make RELEASE-NOTES accessible from GUI (#8616)

[Vincent van Ravesteijn]

On Tue, May 19, 2015 at 9:59 AM, Juergen Spitzmueller  wrote:
> commit 9f55ce9b04c1786c5bed52afc9028f287d28bb32
> Author: Juergen Spitzmueller 
> Date:   Tue May 19 09:57:52 2015 +0200
>
> Make RELEASE-NOTES accessible from GUI (#8616)
>
> CMake people, please check if something needs to be done to install
> lib/RELEASE-NOTES.
>

Shall we leave behind the original RELEASE-NOTES file with the text:
"The RELEASE-NOTES can be found in lib/RELEASE-NOTES." ?

People probably are used to look for the RELEASE-NOTES in the main
directory, and we do not have the possibility of attending them to
this change by putting something in the release notes :S..

Vincent

Re: [LyX/master] Add Qt's Svg module to the list of used modules. This is required to allow the use of e.g. the QSvgRenderer class.

[Vincent van Ravesteijn]

Stephan Witt schreef op 19-5-2015 om 22:48:

commit 0933df00113ee2735699c13559ad3b6e7e9fd115
Author: Stephan Witt 
Date:   Tue May 19 08:11:01 2015 +0200

 Add Qt's Svg module to the list of used modules. This is required to allow 
the use of e.g. the QSvgRenderer class.



Is  it worth pulling in the QtSvg dependency just to show a nicer banner ?

Vincent

Re: 2.2

[Vincent van Ravesteijn]

Jean-Marc Lasgouttes schreef op 13-5-2015 om 10:42:


Hi there,

The ritual question: what is still needed for 2.2?

I guess we are still waiting for some python 3.3 goodness from José, 
but what else?


It seems to me that publishing a beta version soon is very desirable. 
Consider that for 2.1 we had 8 months between first beta and 2.1 release.


Vincent, are you still our release manager, or are your other 
management duties still interfering? I like the way you force us to 
fix every detail before release, I think this is needed.




Thanks for putting it in a positive way.

I often want to be back somewhat more, but before I can catch up with 
the e-mails, life seems to consume my time and energy.


I will try to see as soon as possible whether I can form an opinion 
about the current state. Also, I can share all the scripts and procedure 
documentation I gathered from last experience. In this way I can at 
least support and/or initiate the process.


I'll read the rest of the thread after a good sleep.

Vincent

Re: boost update?

[Vincent van Ravesteijn]

Georg Baum schreef op 16-5-2015 om 10:19:

Hi,

I tested LyX with boost 1.58, and it compiles and runs fine. Shall I update
the included boost? This would get rid of some compiler warnings, and since
2.2 will live for a while I guess it is good to start with a recent boost,
since a boost update for a stable release is more risky.


Georg

Last time I tried (not so long ago), I hit a lot of new compiler errors, 
which I didn't know how to fix.


Thank you for fixing those..

Vincent

Re: boost update?

[Vincent van Ravesteijn]

Op 18 mei 2015 22:20 schreef Georg Baum georg.b...@post.rwth-aachen.de:

 Vincent van Ravesteijn wrote:

  Last time I tried (not so long ago), I hit a lot of new compiler errors,
  which I didn't know how to fix.
 
  Thank you for fixing those..

 It was easy, it was only one: b596330093d. Maybe our code has some self-
 healing capabilities:-)


 Georg

I remember losing my way in many boost::next errors and ununderstandable
paragraph iterators. Let's see tomorrow whether your fix(es) solve(s) my
problems.

Vincent

Re: 2.2

[Vincent van Ravesteijn]

Jean-Marc Lasgouttes schreef op 13-5-2015 om 10:42:


Hi there,

The ritual question: what is still needed for 2.2?

I guess we are still waiting for some python 3.3 goodness from José, 
but what else?


It seems to me that publishing a beta version soon is very desirable. 
Consider that for 2.1 we had 8 months between first beta and 2.1 release.


Vincent, are you still our release manager, or are your other 
management duties still interfering? I like the way you force us to 
fix every detail before release, I think this is needed.




Thanks for putting it in a positive way.

I often want to be back somewhat more, but before I can catch up with 
the e-mails, life seems to consume my time and energy.


I will try to see as soon as possible whether I can form an opinion 
about the current state. Also, I can share all the scripts and procedure 
documentation I gathered from last experience. In this way I can at 
least support and/or initiate the process.


I'll read the rest of the thread after a good sleep.

Vincent

Re: boost update?

[Vincent van Ravesteijn]

Georg Baum schreef op 16-5-2015 om 10:19:

Hi,

I tested LyX with boost 1.58, and it compiles and runs fine. Shall I update
the included boost? This would get rid of some compiler warnings, and since
2.2 will live for a while I guess it is good to start with a recent boost,
since a boost update for a stable release is more risky.


Georg

Last time I tried (not so long ago), I hit a lot of new compiler errors, 
which I didn't know how to fix.


Thank you for fixing those..

Vincent

Re: boost update?

[Vincent van Ravesteijn]

Op 18 mei 2015 22:20 schreef "Georg Baum" <georg.b...@post.rwth-aachen.de>:
>
> Vincent van Ravesteijn wrote:
>
> > Last time I tried (not so long ago), I hit a lot of new compiler errors,
> > which I didn't know how to fix.
> >
> > Thank you for fixing those..
>
> It was easy, it was only one: b596330093d. Maybe our code has some self-
> healing capabilities:-)
>
>
> Georg
>
I remember losing my way in many boost::next errors and ununderstandable
paragraph iterators. Let's see tomorrow whether your fix(es) solve(s) my
problems.

Vincent

Re: C++ question about const

[Vincent van Ravesteijn]

Scott Kostyshak schreef op 22-4-2015 om 3:37:

My question is in regards to the patch I propose for #6173:
http://www.lyx.org/trac/attachment/ticket/6173/0001-Update-previews-when-going-to-a-bookmark-6173.patch

I move the definition of cur up because I need it before the return. I
then need to pass it to notifyCursorLeavesOrEnters(), which requires
it not to be const, so I removed the const in the definition. But what
should I do? Alternatives to what I did are: (b) use a different
definition, cur2, and leave cur alone. (c) use a const cast in the
call to notifyCursorLeavesOrEnters()?

Is there a clear correct way?



In many cases variables are defined const because they are not going to 
be changed. This does not mean that it was not allowed to be changed by 
design.


In this case, I would just remove the const.

Vincent

Re: C++ question about const

[Vincent van Ravesteijn]

Scott Kostyshak schreef op 22-4-2015 om 3:37:

My question is in regards to the patch I propose for #6173:
http://www.lyx.org/trac/attachment/ticket/6173/0001-Update-previews-when-going-to-a-bookmark-6173.patch

I move the definition of cur up because I need it before the return. I
then need to pass it to notifyCursorLeavesOrEnters(), which requires
it not to be const, so I removed the const in the definition. But what
should I do? Alternatives to what I did are: (b) use a different
definition, cur2, and leave cur alone. (c) use a const cast in the
call to notifyCursorLeavesOrEnters()?

Is there a clear correct way?



In many cases variables are defined const because they are not going to 
be changed. This does not mean that it was not allowed to be changed by 
design.


In this case, I would just remove the const.

Vincent

Re: 2 dataloss warnings after merge of remote-tracking branch

[Vincent van Ravesteijn]

On Tue, Jan 13, 2015 at 10:14 AM, Jean-Marc Lasgouttes
lasgout...@lyx.org wrote:
 Le 13/01/2015 01:22, Uwe Stöhr a écrit :

 My change allowed to set the line width to any value you like. As i had
 to set a default width I chose 0.5 because this is already a LaTeX
 default width (if I remember correctly).
 Anyway, the thickness must be a float to allow full control of the line
 width.


 You can use whatever you want, but pixels are pixels. At the end the width
 of the line will be an integer. The only reason why QPen::setWidthF exists
 is that one may have transformed the painter space so that, for example the
 unit is millimeter (think printer). This is not the case here obviously.


I guess that when you use AntiAliasing, you would be able to actually
draw non-integer widths.

Don't know how Qt handles it though.

Vincent

Re: 2 dataloss warnings after merge of remote-tracking branch

[Vincent van Ravesteijn]

On Tue, Jan 13, 2015 at 11:27 AM, Jean-Marc Lasgouttes
lasgout...@lyx.org wrote:
 Le 11/01/2015 11:53, Georg Baum a écrit :

 Because they are on by default in MSVC and off by default in gcc. You can
 get similar ones with gcc by calling it with -Wconversion (but that
 outputs
 many more).


 gcc 4.9 has -Wfloat-conversion. I tried it, but it really gives many
 warnings (see below) and I am uncomfortable with using it.

 I wonder though why MSVC only gives a few of them.

 JMarc


Did you only attached a part of the output ? There are not so many
warnings in the attached and they all look like it's worth killing
them.

Vincent

Re: 2 dataloss warnings after merge of remote-tracking branch

[Vincent van Ravesteijn]

 Another thing if we use C++11 mode is that auto_ptr is deprecated. Who knows
 what to do about that?


I googled it for you: ;)

Note: This class template is deprecated as of C++11. unique_ptr is a
new facility with a similar functionality, but with improved security
(no fake copy assignments), added features (deleters) and support for
arrays. See unique_ptr for additional information.

(http://www.cplusplus.com/reference/memory/auto_ptr/)
(http://www.cplusplus.com/reference/memory/unique_ptr/)

Vincent

Re: [LyX/master] Remove direct calls of exit()

[Vincent van Ravesteijn]

Georg Baum schreef op 9-1-2015 om 21:44:

commit ca6fba31fbc44e4b4ed6457b16f3f0d2ee28b7f0
Author: Georg Baum b...@lyx.org
Date:   Fri Jan 9 21:43:45 2015 +0100

 Remove direct calls of exit()
 
 This is a preparation for using QCoreApplication.


  
@@ -1047,9 +1048,11 @@ int main(int argc, char * argv[])

cerr  Error: Could not find syntax file \syntax.default\. 
 endl;
return EXIT_FAILURE;
}
-   read_syntaxfile(system_syntaxfile);
+   if (!read_syntaxfile(system_syntaxfile))
+   return 2;
if (!syntaxfile.empty())
-   read_syntaxfile(makeAbsPath(syntaxfile));
+   if (!read_syntaxfile(makeAbsPath(syntaxfile)))
+   return 2;
  
  	// Read the encodings table.

FileName const symbols_path = libFileSearch(string(), unicodesymbols);


Anyone knows what return 2 means ? I don't see anything in the tex2lyx 
man page or whatever. Also, I don't think we use the return value 
anywhere ourselves.


Vincent

Re: 2 dataloss warnings after merge of remote-tracking branch

[Vincent van Ravesteijn]

On Tue, Jan 13, 2015 at 10:14 AM, Jean-Marc Lasgouttes
 wrote:
> Le 13/01/2015 01:22, Uwe Stöhr a écrit :
>>
>> My change allowed to set the line width to any value you like. As i had
>> to set a default width I chose 0.5 because this is already a LaTeX
>> default width (if I remember correctly).
>> Anyway, the thickness must be a float to allow full control of the line
>> width.
>
>
> You can use whatever you want, but pixels are pixels. At the end the width
> of the line will be an integer. The only reason why QPen::setWidthF exists
> is that one may have transformed the painter space so that, for example the
> unit is millimeter (think printer). This is not the case here obviously.
>

I guess that when you use AntiAliasing, you would be able to actually
draw non-integer widths.

Don't know how Qt handles it though.

Vincent

Re: 2 dataloss warnings after merge of remote-tracking branch

[Vincent van Ravesteijn]

On Tue, Jan 13, 2015 at 11:27 AM, Jean-Marc Lasgouttes
 wrote:
> Le 11/01/2015 11:53, Georg Baum a écrit :
>>
>> Because they are on by default in MSVC and off by default in gcc. You can
>> get similar ones with gcc by calling it with -Wconversion (but that
>> outputs
>> many more).
>
>
> gcc 4.9 has -Wfloat-conversion. I tried it, but it really gives many
> warnings (see below) and I am uncomfortable with using it.
>
> I wonder though why MSVC only gives a few of them.
>
> JMarc
>

Did you only attached a part of the output ? There are not so many
warnings in the attached and they all look like it's worth killing
them.

Vincent

Re: 2 dataloss warnings after merge of remote-tracking branch

[Vincent van Ravesteijn]

>
> Another thing if we use C++11 mode is that auto_ptr is deprecated. Who knows
> what to do about that?
>

I googled it for you: ;)

"Note: This class template is deprecated as of C++11. unique_ptr is a
new facility with a similar functionality, but with improved security
(no fake copy assignments), added features (deleters) and support for
arrays. See unique_ptr for additional information."

(http://www.cplusplus.com/reference/memory/auto_ptr/)
(http://www.cplusplus.com/reference/memory/unique_ptr/)

Vincent

Re: [LyX/master] Remove direct calls of exit()

[Vincent van Ravesteijn]

Georg Baum schreef op 9-1-2015 om 21:44:

commit ca6fba31fbc44e4b4ed6457b16f3f0d2ee28b7f0
Author: Georg Baum 
Date:   Fri Jan 9 21:43:45 2015 +0100

 Remove direct calls of exit()
 
 This is a preparation for using QCoreApplication.


  
@@ -1047,9 +1048,11 @@ int main(int argc, char * argv[])

cerr << "Error: Could not find syntax file \"syntax.default\"." 
<< endl;
return EXIT_FAILURE;
}
-   read_syntaxfile(system_syntaxfile);
+   if (!read_syntaxfile(system_syntaxfile))
+   return 2;
if (!syntaxfile.empty())
-   read_syntaxfile(makeAbsPath(syntaxfile));
+   if (!read_syntaxfile(makeAbsPath(syntaxfile)))
+   return 2;
  
  	// Read the encodings table.

FileName const symbols_path = libFileSearch(string(), "unicodesymbols");


Anyone knows what "return 2" means ? I don't see anything in the tex2lyx 
man page or whatever. Also, I don't think we use the return value 
anywhere ourselves.


Vincent

Re: current master uncompilable under Windows

[Vincent van Ravesteijn]

On Fri, Jan 9, 2015 at 11:19 AM, Kornel Benko kor...@lyx.org wrote:
 Am Donnerstag, 8. Januar 2015 um 20:08:35, schrieb Georg Baum 
 georg.b...@post.rwth-aachen.de
 Vincent van Ravesteijn wrote:

  On Thu, Jan 8, 2015 at 10:13 AM, Kornel Benko kor...@lyx.org wrote:
  Am Mittwoch, 7. Januar 2015 um 21:32:25, schrieb Jean-Marc Lasgouttes
  lasgout...@lyx.org
  Le 07/01/2015 02:41, Uwe Stöhr a écrit :
   compiling current master I get 2 compilation errors:
 
  This looks like a missing dependency in cmake for the check on
  ExternalTransforms...
 
  Georg? Kornel?
 
  JMarc
 
 
  Isn't it just a case of adding dummy definitions for TexRow::newline
  and friend in dummy_functions.cpp (as we did in
  src/tex2lyx/dummy_impl.cpp) ?

 The test does not depend on TexRow, but the microsoft linker is not clever
 enough to find out that no symbol from the class otexstream is used, and
 therefore it does not throw away these symbols, which the GNU linker
 obviously does (otherwise the test would not link on linux either).

 The real problem IHMO is that a class from src/support (otexstream) depends
 on a class from src (TexRow). I would very much prefer to resolve this
 dependency instead of hacking around with cmake or a dummy implementation.


 Georg

 Do you also have a suggestion to what should Uwe in the mean time do?
 (Apart from hacking around with cmake, that is)

 Kornel

That's simple. Don't compile the checkExternalTransform test.

As far as I could see, LyX itself had no problems compiling.

Vincent

Re: current master uncompilable under Windows

[Vincent van Ravesteijn]

On Fri, Jan 9, 2015 at 11:19 AM, Kornel Benko <kor...@lyx.org> wrote:
> Am Donnerstag, 8. Januar 2015 um 20:08:35, schrieb Georg Baum 
> <georg.b...@post.rwth-aachen.de>
>> Vincent van Ravesteijn wrote:
>>
>> > On Thu, Jan 8, 2015 at 10:13 AM, Kornel Benko <kor...@lyx.org> wrote:
>> >> Am Mittwoch, 7. Januar 2015 um 21:32:25, schrieb Jean-Marc Lasgouttes
>> >> <lasgout...@lyx.org>
>> >>> Le 07/01/2015 02:41, Uwe Stöhr a écrit :
>> >>> > compiling current master I get 2 compilation errors:
>> >>>
>> >>> This looks like a missing dependency in cmake for the check on
>> >>> ExternalTransforms...
>> >>>
>> >>> Georg? Kornel?
>> >>>
>> >>> JMarc
>> >
>> >
>> > Isn't it just a case of adding dummy definitions for TexRow::newline
>> > and friend in dummy_functions.cpp (as we did in
>> > src/tex2lyx/dummy_impl.cpp) ?
>>
>> The test does not depend on TexRow, but the microsoft linker is not clever
>> enough to find out that no symbol from the class otexstream is used, and
>> therefore it does not throw away these symbols, which the GNU linker
>> obviously does (otherwise the test would not link on linux either).
>>
>> The real problem IHMO is that a class from src/support (otexstream) depends
>> on a class from src (TexRow). I would very much prefer to resolve this
>> dependency instead of hacking around with cmake or a dummy implementation.
>>
>>
>> Georg
>
> Do you also have a suggestion to what should Uwe in the mean time do?
> (Apart from hacking around with cmake, that is)
>
> Kornel

That's simple. Don't compile the checkExternalTransform test.

As far as I could see, LyX itself had no problems compiling.

Vincent

Re: current master uncompilable under Windows

[Vincent van Ravesteijn]

On Thu, Jan 8, 2015 at 10:13 AM, Kornel Benko kor...@lyx.org wrote:
 Am Mittwoch, 7. Januar 2015 um 21:32:25, schrieb Jean-Marc Lasgouttes 
 lasgout...@lyx.org
 Le 07/01/2015 02:41, Uwe Stöhr a écrit :
  compiling current master I get 2 compilation errors:

 This looks like a missing dependency in cmake for the check on
 ExternalTransforms...

 Georg? Kornel?

 JMarc


Isn't it just a case of adding dummy definitions for TexRow::newline
and friend in dummy_functions.cpp (as we did in
src/tex2lyx/dummy_impl.cpp) ?

Vincent

Re: 2.2 (was: Re: Retina support)

[Vincent van Ravesteijn]

On Tue, Jan 6, 2015 at 7:58 PM, Jean-Marc Lasgouttes lasgout...@lyx.org wrote:
 Le 04/01/2015 15:00, Stephan Witt a écrit :

 Is it possible to make a 2.2 release in a foreseeable future?


 As far as I am concerned, I'd just like to land the scroll-reloaded branch
 ASAP. It will not improve any more without testing.

 Who has plans for 2.2 that have not been executed yet?

 JMarc


I understood that an important motivation for releasing 2.2 is that we
can't (or don't want to) backport the Qt5 support to 2.1.x.

If that's the case, we might want the Qt5 support fully up and running
before 2.2.

Vincent

Re: current master uncompilable under Windows

[Vincent van Ravesteijn]

On Thu, Jan 8, 2015 at 10:13 AM, Kornel Benko  wrote:
> Am Mittwoch, 7. Januar 2015 um 21:32:25, schrieb Jean-Marc Lasgouttes 
> 
>> Le 07/01/2015 02:41, Uwe Stöhr a écrit :
>> > compiling current master I get 2 compilation errors:
>>
>> This looks like a missing dependency in cmake for the check on
>> ExternalTransforms...
>>
>> Georg? Kornel?
>>
>> JMarc


Isn't it just a case of adding dummy definitions for TexRow::newline
and friend in dummy_functions.cpp (as we did in
src/tex2lyx/dummy_impl.cpp) ?

Vincent

Re: 2.2 (was: Re: Retina support)

[Vincent van Ravesteijn]

On Tue, Jan 6, 2015 at 7:58 PM, Jean-Marc Lasgouttes  wrote:
> Le 04/01/2015 15:00, Stephan Witt a écrit :
>>
>> Is it possible to make a 2.2 release in a foreseeable future?
>
>
> As far as I am concerned, I'd just like to land the scroll-reloaded branch
> ASAP. It will not improve any more without testing.
>
> Who has plans for 2.2 that have not been executed yet?
>
> JMarc
>

I understood that an important motivation for releasing 2.2 is that we
can't (or don't want to) backport the Qt5 support to 2.1.x.

If that's the case, we might want the Qt5 support fully up and running
before 2.2.

Vincent

Install package texlive-esint-type1

[Vincent van Ravesteijn]

Hi all,

To compile the User's guide, I had to manually install the package
texlive-esint-type1.

Shouldn't this be installed automatically when the lyx package is
installed ? I'm now at OpenSuse. Do other distros do install this
package ?

How can we inform the distros that this package is required ?

Vincent

[PATCH] str-metrics: Prevent clipping of chars with negative bearing

[Vincent van Ravesteijn]

JMarc,

The following fixes the clipping of characters with negative bearing,
like the f, at the end of a sentence. This happens when part of the
word is selected.

To reproduce:
1. Start a new document
2. Type af
3. Select 'a'
4. Observe that the right part of the 'f' is clipped away.

This patch uses QRegion to set a clip region that is everything except
the part that is drawn in another color.

Ok ?

Vincent


 src/frontends/qt4/GuiPainter.cpp | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/src/frontends/qt4/GuiPainter.cpp b/src/frontends/qt4/GuiPainter.cpp
index 5730819..95ab52a 100644
--- a/src/frontends/qt4/GuiPainter.cpp
+++ b/src/frontends/qt4/GuiPainter.cpp
@@ -465,15 +465,16 @@ int GuiPainter::text(int x, int y, docstring
const  str, Font const  f,
 // First the part in other color
 Color const orig = fi.realColor();
 fi.setPaintColor(other);
-setClipRect(QRect(x + xmin, y - ascent, xmax - xmin, height));
+QRegion const clip(x + xmin, y - ascent, xmax - xmin, height);
+setClipRegion(clip);
 int const textwidth = text(x, y, str, fi, rtl);

 // Then the part in normal color
-// Note that in Qt5, it is not possible to use Qt::UniteClip
+// Note that in Qt5, it is not possible to use Qt::UniteClip,
+// therefore QRegion is used.
 fi.setPaintColor(orig);
-setClipRect(QRect(x, y - ascent, xmin, height));
-text(x, y, str, fi, rtl);
-setClipRect(QRect(x + xmax, y - ascent, textwidth - xmax, height));
+QRegion region(viewport());
+setClipRegion(region - clip);
 text(x, y, str, fi, rtl);
 setClipping(false);

-- 
2.1.2

[PATCH] str-metrics: Prevent clipping of chars with negative bearing

[Vincent van Ravesteijn]

JMarc,

The following fixes the clipping of characters with negative bearing,
like the "f", at the end of a sentence. This happens when part of the
word is selected.

To reproduce:
1. Start a new document
2. Type "af"
3. Select 'a'
4. Observe that the right part of the 'f' is clipped away.

This patch uses QRegion to set a clip region that is everything except
the part that is drawn in another color.

Ok ?

Vincent


 src/frontends/qt4/GuiPainter.cpp | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/src/frontends/qt4/GuiPainter.cpp b/src/frontends/qt4/GuiPainter.cpp
index 5730819..95ab52a 100644
--- a/src/frontends/qt4/GuiPainter.cpp
+++ b/src/frontends/qt4/GuiPainter.cpp
@@ -465,15 +465,16 @@ int GuiPainter::text(int x, int y, docstring
const & str, Font const & f,
 // First the part in other color
 Color const orig = fi.realColor();
 fi.setPaintColor(other);
-setClipRect(QRect(x + xmin, y - ascent, xmax - xmin, height));
+QRegion const clip(x + xmin, y - ascent, xmax - xmin, height);
+setClipRegion(clip);
 int const textwidth = text(x, y, str, fi, rtl);

 // Then the part in normal color
-// Note that in Qt5, it is not possible to use Qt::UniteClip
+// Note that in Qt5, it is not possible to use Qt::UniteClip,
+// therefore QRegion is used.
 fi.setPaintColor(orig);
-setClipRect(QRect(x, y - ascent, xmin, height));
-text(x, y, str, fi, rtl);
-setClipRect(QRect(x + xmax, y - ascent, textwidth - xmax, height));
+QRegion region(viewport());
+setClipRegion(region - clip);
 text(x, y, str, fi, rtl);
 setClipping(false);

-- 
2.1.2

Install package texlive-esint-type1

[Vincent van Ravesteijn]

Hi all,

To compile the User's guide, I had to manually install the package
"texlive-esint-type1".

Shouldn't this be installed automatically when the lyx package is
installed ? I'm now at OpenSuse. Do other distros do install this
package ?

How can we inform the distros that this package is required ?

Vincent

Compilation with Autotools and Qt5

[Vincent van Ravesteijn]

Hi all,

Apparently we need to append the following arguments to configure to be 
able to compile with qt5 and autotools (already discussed in 
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg185551.html):


configure --enable-qt5 CPPFLAGS=-fPIC --disable-concept-checks

Should we make this the default then ?

Vincent