Re: [LyX/master] Fix thinko in Buffer::preview. It is possible for this routine to be called when we do not have a cloned Buffer, namely, if we do not have EXPORT_in_THREAD defined.

[Richard Heck]

On 07/10/2016 09:53 AM, Guillaume Munch wrote:
> Le 10/07/2016 14:48, Richard Heck a écrit :
>> On 07/10/2016 05:26 AM, Andrew Parsloe wrote:
>>>
>>> I ask in near total ignorance, but "my ears pricked up" when I read
>>> "EXPORT_in_THREAD" and "It's set in the code, but can be manually
>>> unset by people who don't want the risks of background export,
>>> threading, etc." Is this a way to tackle
>>> http://www.lyx.org/trac/ticket/8346 on the problems threaded export
>>> poses for command-sequences?
>>
>> Not really, unless you just want to disable background export entirely.
>> The switch has to be set compile time.
>
> This is not essential, it is trivial to make it run-time (but is it
> really worth an interface?).

Check the bug Andrew mentioned for one reason it would be good to have this.
Basically, if you do something like:

command-sequence buffer-export someformat; buffer-reload

in an attempt to process something externally, it fails, because the
reload happens
before the export completes. I.e., it happens almost instantly.

Richard

Re: [LyX/master] Generate a proper error dialog title for XeTeX/LuaTeX

[Richard Heck]

On 07/10/2016 05:14 AM, Juergen Spitzmueller wrote:
> commit 65173b26d55ab7fe0ac15be82730e7f99e8d8aed
> Author: Juergen Spitzmueller 
> Date:   Sun Jul 10 11:14:03 2016 +0200
>
> Generate a proper error dialog title for XeTeX/LuaTeX
> 
> (see bug #10013)
> 
> Candidate for stable

OK.

rh

Re: [LyX/master] Fix thinko in Buffer::preview. It is possible for this routine to be called when we do not have a cloned Buffer, namely, if we do not have EXPORT_in_THREAD defined.

[Richard Heck]

On 07/10/2016 05:26 AM, Andrew Parsloe wrote:
>
>
> On 10/07/2016 5:42 p.m., Richard Heck wrote:
>> On 07/10/2016 01:33 AM, Scott Kostyshak wrote:
>>> On Sun, Jul 10, 2016 at 07:16:13AM +0200, Richard Heck wrote:
>>>> commit d8aab4af9e6e72c835f78ba54a46687b870c25fa
>>>> Author: Richard Heck <rgh...@lyx.org>
>>>> Date:   Sun Jul 10 01:12:42 2016 -0400
>>>>
>>>>  Fix thinko in Buffer::preview. It is possible for this routine to
>>>>  be called when we do not have a cloned Buffer, namely, if we
>>>> do not
>>>>  have EXPORT_in_THREAD defined.
>>> Thanks for fixing this. How does one set EXPORT_in_THREAD? I imagine
>>> this could be useful for debugging purposes (e.g ruling out that a bug
>>> is due to exporting in a separate thread).
>>
>> It's #defined in GuiView.cpp and GuiAlert.cpp. It's set in the code, but
>> can be manually unset by people who don't want the risks of background
>> export, threading, etc. And yes, it is useful for the purpose you
>> mentioned.
>>
>> Probably, it should be exposed via configure, etc, but no one ever
>> did that.
>>
>> Richard
>>
>
> I ask in near total ignorance, but "my ears pricked up" when I read
> "EXPORT_in_THREAD" and "It's set in the code, but can be manually
> unset by people who don't want the risks of background export,
> threading, etc." Is this a way to tackle
> http://www.lyx.org/trac/ticket/8346 on the problems threaded export
> poses for command-sequences?

Not really, unless you just want to disable background export entirely.
The switch has to be set compile time.

Richard

Re: [LyX/master] Fix thinko in Buffer::preview. It is possible for this routine to be called when we do not have a cloned Buffer, namely, if we do not have EXPORT_in_THREAD defined.

[Richard Heck]

On 07/10/2016 07:06 AM, Guillaume Munch wrote:
> Le 10/07/2016 06:42, Richard Heck a écrit :
>> On 07/10/2016 01:33 AM, Scott Kostyshak wrote:
>>> On Sun, Jul 10, 2016 at 07:16:13AM +0200, Richard Heck wrote:
>>>> commit d8aab4af9e6e72c835f78ba54a46687b870c25fa
>>>> Author: Richard Heck <rgh...@lyx.org>
>>>> Date:   Sun Jul 10 01:12:42 2016 -0400
>>>>
>>>>  Fix thinko in Buffer::preview. It is possible for this routine to
>>>>  be called when we do not have a cloned Buffer, namely, if we
>>>> do not
>>>>  have EXPORT_in_THREAD defined.
>>> Thanks for fixing this. How does one set EXPORT_in_THREAD? I imagine
>>> this could be useful for debugging purposes (e.g ruling out that a bug
>>> is due to exporting in a separate thread).
>>
>> It's #defined in GuiView.cpp and GuiAlert.cpp. It's set in the code, but
>> can be manually unset by people who don't want the risks of background
>> export, threading, etc. And yes, it is useful for the purpose you
>> mentioned.
>>
>
> Note that one of the file erroneously tests with #ifdef instead of #if,
> so I doubt that it has ever been unset. (This is fixed by my patch at
> <http://mid.gmane.org/nlbl32$hki$2...@ger.gmane.org>.)

I noticed that, too. Certainly that can be fixed independently of the
rest (which
is fine by me, too).

Richard

Re: [LyX/master] Fix thinko in Buffer::preview. It is possible for this routine to be called when we do not have a cloned Buffer, namely, if we do not have EXPORT_in_THREAD defined.

[Richard Heck]

On 07/10/2016 01:33 AM, Scott Kostyshak wrote:
> On Sun, Jul 10, 2016 at 07:16:13AM +0200, Richard Heck wrote:
>> commit d8aab4af9e6e72c835f78ba54a46687b870c25fa
>> Author: Richard Heck <rgh...@lyx.org>
>> Date:   Sun Jul 10 01:12:42 2016 -0400
>>
>> Fix thinko in Buffer::preview. It is possible for this routine to
>> be called when we do not have a cloned Buffer, namely, if we do not
>> have EXPORT_in_THREAD defined.
> Thanks for fixing this. How does one set EXPORT_in_THREAD? I imagine
> this could be useful for debugging purposes (e.g ruling out that a bug
> is due to exporting in a separate thread).

PS I just stumbled across this when looking at #9680 (Arabic filenames
changing e.g. to _.pdf on preview). I figured out what is happening
there, but it is not obvious what to do about it.

Richard

Re: [LyX/master] Fix thinko in Buffer::preview. It is possible for this routine to be called when we do not have a cloned Buffer, namely, if we do not have EXPORT_in_THREAD defined.

[Richard Heck]

On 07/10/2016 01:33 AM, Scott Kostyshak wrote:
> On Sun, Jul 10, 2016 at 07:16:13AM +0200, Richard Heck wrote:
>> commit d8aab4af9e6e72c835f78ba54a46687b870c25fa
>> Author: Richard Heck <rgh...@lyx.org>
>> Date:   Sun Jul 10 01:12:42 2016 -0400
>>
>> Fix thinko in Buffer::preview. It is possible for this routine to
>> be called when we do not have a cloned Buffer, namely, if we do not
>> have EXPORT_in_THREAD defined.
> Thanks for fixing this. How does one set EXPORT_in_THREAD? I imagine
> this could be useful for debugging purposes (e.g ruling out that a bug
> is due to exporting in a separate thread).

It's #defined in GuiView.cpp and GuiAlert.cpp. It's set in the code, but
can be manually unset by people who don't want the risks of background
export, threading, etc. And yes, it is useful for the purpose you mentioned.

Probably, it should be exposed via configure, etc, but no one ever did that.

Richard

Paragraph::id()

[Richard Heck]

If I do:
onePar.id() == otherPar.id()
will that do what I obviously want it to do? I.e., work as a proxy for:
onePar == otherPar
??

Richard

Re: [LyX/master] Added missing ipa icons to distribution

[Richard Heck]

On 07/09/2016 06:41 AM, Jürgen Spitzmüller wrote:
> Am Mittwoch, den 15.06.2016, 15:04 +0200 schrieb Kornel Benko:
>> commit 43d284e15ad6193da2508a57b5260cb85ff4cdb9
>> Author: Kornel Benko 
>> Date:   Wed Jun 15 15:03:55 2016 +0200
>>
>> Added missing ipa icons to distribution
> This should go to branch as well (also 60a1827b65).

OK.

rh

Re: Weird KDE Bug in LyX

[Richard Heck]

On 07/08/2016 04:01 PM, Richard Heck wrote:
> On 07/08/2016 03:33 PM, Guillaume Munch wrote:
>> Le 05/07/2016 21:30, Guillaume Munch a écrit :
>>>
>>> Please try the attached.
>> I'll soon commit the fix to master. This is a delicate code path so
>> even if I tried to be very careful, there will be no backport without
>> a test. 
> I'd think this is not for 2.2.1. We can commit soon after that release
> and let it get tested there.

..commit to 2.2.x, I mean. It's fine for master, as far as I'm concerned.

Richard

Re: Weird KDE Bug in LyX

[Richard Heck]

On 07/08/2016 03:33 PM, Guillaume Munch wrote:
> Le 05/07/2016 21:30, Guillaume Munch a écrit :
>>
>>
>> Please try the attached.
>
> I'll soon commit the fix to master. This is a delicate code path so
> even if I tried to be very careful, there will be no backport without
> a test. 

I'd think this is not for 2.2.1. We can commit soon after that release
and let it get tested there.

Richard

Re: Exporting compressed files

[Richard Heck]

On 07/08/2016 12:01 PM, José Abílio Matos wrote:
> On Thursday, July 7, 2016 4:05:15 PM WEST Richard Heck wrote:
>> Patch seems reasonable to me.
>>
>> Please commit to 2.2.x after 2.2.1 is released.
>>
>> Richard
> Thank you Richard. :-)
>
> Commited to master and I will do the same to 2.2.x after 2.2.1 is out.

Good, and thanks for fixing this.

rh

Re: [LyX/master] Fix incompatibility of covington and beamer.

[Richard Heck]

On 07/08/2016 04:05 AM, Juergen Spitzmueller wrote:
> commit ee14363e0ba9f9c5433509816a9d75b695b859bd
> Author: Juergen Spitzmueller 
> Date:   Fri Jul 8 10:04:24 2016 +0200
>
> Fix incompatibility of covington and beamer.
> 
> Candidate for stable.

OK.

Richard

Re: [PATCH] make string breaking faster

[Richard Heck]

On 07/07/2016 04:24 PM, Pavel Sanda wrote:

Richard Heck wrote:

Can you try if you can see difference between 2.1 and master for this
scenario:
1. set high speed rate for your keyboard: xset r rate 300 180
2. load user guide, fullscreen
3. Hold right arrow until you reach the end of the first page and count
the time
 (even approximately, the difference is quite noticeable here).

I tried this and didn't see any significant difference. I'd say master was
marginally slower (maybe 7.5sec vs 7sec).

What Qt version do you use?


4.8.6

This is on my laptop, which runs Ubuntu.

Richard

Re: [PATCH] make string breaking faster

[Richard Heck]

On 07/07/2016 01:06 PM, Pavel Sanda wrote:

Jean-Marc Lasgouttes wrote:

Le 07/07/2016 ? 18:54, Pavel Sanda a écrit :

Jean-Marc Lasgouttes wrote:

That's OK. But did you remove the PROFILE_xxx macros? They probably have
an
effect on performance.

No visible effect for me.

Can you try if you can see difference between 2.1 and master for this
scenario:
1. set high speed rate for your keyboard: xset r rate 300 180
2. load user guide, fullscreen
3. Hold right arrow until you reach the end of the first page and count
the time
(even approximately, the difference is quite noticeable here).


I tried this and didn't see any significant difference. I'd say master 
was marginally slower (maybe 7.5sec vs 7sec).


Richard

Re: Exporting compressed files

[Richard Heck]

Patch seems reasonable to me.

Please commit to 2.2.x after 2.2.1 is released.

Richard


On 07/07/2016 05:18 AM, José Abílio Matos wrote:

On Thursday, July 7, 2016 10:09:44 AM WEST Andrew Parsloe wrote:

Yes, changing > to -o results in an exported compressed file that 2.1.5
can read. Thanks for the help.

Andrew

Thank you Andrew. I still blame windows for this but in any case to use the
option -o is the right thing to do since we already know where to write. As it
is now lyx2lyx tries to guess where to write it and since no clue is offered
it writes to stdout that then it is written to $$o.

I propose the following patch to go in 2.3 (btw I think we can drop the 2.
prefix from the version ;-) ) and later this could go to 2.2.x (with x >= 2).

The patch makes the call to lyx2lyx less cryptic, e.g. to revert to the 1.3
format we have:

\converter lyx lyx13x "python -tt $$s/lyx2lyx/lyx2lyx -t 221 $$i > $$o" ""


what I propose is that instead of
python -tt $$s/lyx2lyx/lyx2lyx -t 221 $$i > $$o

we can write
python -tt $$s/lyx2lyx/lyx2lyx -V 1.3 -o $$o $$i


or we could write a longer, but more understandable form:
python -tt $$s/lyx2lyx/lyx2lyx --final_version 1.3 --output $$o $$i


FWIW I shuffled the order of the arguments just for the sake of readability,
to let $$i as the last argument.

The funny thing about this is the code is there for almost 8 years. :-)

Regards,

Re: Anonymous functions: replace bind with lambdas

[Richard Heck]

On 07/03/2016 05:36 PM, Guillaume Munch wrote:

Le 03/07/2016 20:52, Richard Heck a écrit :



One might wonder in such cases why things are being copied or passed
by reference, for example.


Unfortunately, while producing equivalent code is easy (or so it seems
so far), fully understanding the old code is hard. For instance, I trust
the old code that references are still valid when the callback is called.


Fair enough.

Richard

Re: Why does LyX not accept empty list items?

[Richard Heck]

On 07/05/2016 03:36 PM, Daniel wrote:
> On 05.07.2016 16:22, Richard Heck wrote:
>> On 07/04/2016 02:42 PM, racoon wrote:
>>> On 04.07.2016 16:16, Jean-Marc Lasgouttes wrote:
>>>> Le 04/07/2016 à 15:38, racoon a écrit :
>>>>> Thanks. Still I am wondering a bit why anything special at all is
>>>>> necessary.
>>>>
>>>> Well, I am glad I do not have dangling list items like Word gladly
>>>> creates.
>>>
>>> Thanks. Not sure what you mean exactly by "dangling list items". Is
>>> the worry that there could be a list item, say from a description,
>>> that are easily overlooked? I guess list items and indentations are
>>> more visible in LyX than in word. But still I see the point somewhat.
>>
>> Note that these sorts of things are customizable. If you really want to
>> allow empty items, do:
>>
>> Style Itemize
>> KeepEmpty 0
>> End
>>
>> Put that in local layout, or in a module you can reuse.
>
> Thanks Richard. Yes, I would like to test it in order to see what
> suits me better. However, it seems not to work as expected. I have
> added it to my local layout but empty items are still removed.
>
> And I guess it would not apply to other environments like quote, right?

Sorry, stupid typo. It should be:

Style Itemize
KeepEmpty 1
End

I.e., 1 for true.

And it should also work for quotations and any other environment,
really. Just change the name of the style. (This needs to be LyX's name
for it, not the translated name in the GUI, if you have that.)

Richard

Re: LyX 2.2.1

[Richard Heck]

On 07/05/2016 06:00 PM, Uwe Stöhr wrote:
> Am 04.07.2016 um 12:05 schrieb Jean-Marc Lasgouttes:
>
>> I'd say that only regressions could be important. Other than that, it is
>> always better to let a good release out than to wait for a perfect one.
>
> +1
>
> it seems that only http://www.lyx.org/trac/ticket/10199 should be
> fixed. Günter?

There are some others

   
http://www.lyx.org/trac/query?status=fixedinmaster=!2.3.0=0=id=summary=changetime=status=milestone=keywords=id

that are fixedinmaster and are worth a peek.

Richard

Re: [PATCH] make string breaking faster

[Richard Heck]

On 07/05/2016 10:06 AM, Jean-Marc Lasgouttes wrote:
> The attached patch implements a cache around the function
> GuiFontMetrics::breakAt, which has been identified as very slow by
> Guillaume. To this end, I use a plain QCache object.
>
> This patch is also instrumented using pmprof.h. When I load the
> UserGuide, and move along the document using Cursor-Down, I get the
> following results:
>
> * Intel(R) Xeon(R) CPU E5-1620 v3 @ 3.50GHz, ubuntu 12.04, Qt 4.8.1
>
> #pmprof# breakAt: 20.69usec, count=1651, total=34.16msec
>hit: 63%, 3.54usec, count=1052, total=3.72msec
>   miss: 36%, 50.82usec, count=599, total=30.44msec
>
>
> * Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, ubuntu 16.04, Qt 4.8.7
>
> #pmprof# breakAt: 221.85usec, count=4884, total=1083.54msec
>hit: 83%, 2.29usec, count=4063, total=9.31msec
>   miss: 16%, 1308.43usec, count=821, total=1074.22msec
>
>
> * Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, ubuntu 16.04, Qt 5.5.1
>
> #pmprof# breakAt: 4.20usec, count=16820, total=70.56msec
>hit: 96%, 1.44usec, count=16267, total=23.43msec
>   miss: 3%, 85.23usec, count=553, total=47.13msec
>
>
> One can see that the improvement between the hit and miss branches is
> x500 with Qt 4.8.7, but only x14 with Qt 4.8.1 and x60 with Qt 5.5.1.
> Note however that the miss path is much faster with Qt5 in the last
> two examples (same machine).
>
> Comments welcome. My plan is to use that for both Qt4 and Qt5 (for
> simplicity). Seeing the different behavior of Qt 4.8.1 and 4.8.7
> (albeit different machines), I suspect that the problem is elsewhere
> in the configuration.
>
> I would be glad to have numbers from your on systems.

Can you give a receipe for producing them? I'm ignorant about profiling.
(In my case, this would be on Linux.)

Richard

Re: [LyX/master] Autoconf : Try to select the correct Qt tools by using the -qt option

[Richard Heck]

On 07/05/2016 06:12 AM, Jean-Marc Lasgouttes wrote:
> Le 05/07/2016 à 12:02, Jean-Marc Lasgouttes a écrit :
>> commit d044986724e98921510c95adecb61d2688b1f598
>> Author: Jean-Marc Lasgouttes 
>> Date:   Mon Jul 4 16:22:57 2016 +0200
>>
>> Autoconf : Try to select the correct Qt tools by using the -qt
>> option
>>
>> With this change, it is now possible to configure with --enable-qt5
>> and have make use "moc -qt=qt5" automatically.
>>
>> This is done when the command qtchooser is available nd the
>> desired Qt
>> version (qt4/qt5) is available.
>>
>> This means that it is now possible to have qt4 and qt5 builds easily
>> on a same linux system.
>
> If this proves to work correctly (i.e. if --enable-qt5 is all it takes
> to switch from Qt4 to Qt5), then this should eventually go to 2.2.x
> (no hurry).

Can you plan to commit it right after 2.2.1 is released?

Richard

Re: Why does LyX not accept empty list items?

[Richard Heck]

On 07/04/2016 02:42 PM, racoon wrote:
> On 04.07.2016 16:16, Jean-Marc Lasgouttes wrote:
>> Le 04/07/2016 à 15:38, racoon a écrit :
>>> Thanks. Still I am wondering a bit why anything special at all is
>>> necessary.
>>
>> Well, I am glad I do not have dangling list items like Word gladly
>> creates.
>
> Thanks. Not sure what you mean exactly by "dangling list items". Is
> the worry that there could be a list item, say from a description,
> that are easily overlooked? I guess list items and indentations are
> more visible in LyX than in word. But still I see the point somewhat.

Note that these sorts of things are customizable. If you really want to
allow empty items, do:

Style Itemize
KeepEmpty 0
End

Put that in local layout, or in a module you can reuse.

Richard

Re: How to prevent a paragraph spanning pages?

[Richard Heck]

On 07/04/2016 06:47 PM, Steve Litt wrote:
> Hi all,
>
> I have a specific paragraph style (environment) that has TeX "Large"
> print and is used only on single sentences. I'd like to incorporate
> something in this environment's LaTeX code to prevent it breaking in
> the middle. Anyone know how to do that?

This same question was asked a couple weeks ago. Should be in the archives.

Richard

Re: Weird KDE Bug in LyX

[Richard Heck]

On 07/04/2016 10:36 AM, José Abílio Matos wrote:

On Friday, July 1, 2016 9:51:08 AM WEST Richard Heck wrote:

Add

[Development]
AutoCheckAccelerators=false
CopyWidgetText=false

to $HOME/.config/kdeglobals

Richard

Thank you Richard, when that happens it can be really annoying. Trying to
change a paragraph layout with Alt+P  and then changing an
unrelated document is really confusing and surprising.

I tested and it works.


Hopefully, it will also get fixed upstream.

Richard

Re: Anonymous functions: replace bind with lambdas

[Richard Heck]

On 07/03/2016 02:21 PM, Guillaume Munch wrote:
> Le 27/06/2016 23:15, Richard Heck a écrit :
>> On 06/27/2016 04:14 PM, Georg Baum wrote:
>>> You mean std::bind, or did I miss any remaining boost::bind?
>
> I just removed some leftover boost::function (not boost::bind).
>
>>> For me personally the patch is too big to proof-read it. I'd prefer to
>>> change simple things like
>>>
>>> -   BufferStorage::iterator it = bstore.begin();
>>> -   BufferStorage::iterator end = bstore.end();
>>> -   for (; it != end; ++it) {
>>> -   Buffer * buf = *it;
>>> +   for(Buffer * buf : bstore)
>>>
>>> which are not related to removal of std::bind first.
>>
>> Yes, that's a good idea.
>
>
> I have split the patch in two for you, and already committed the part
> that does not introduce lambda expressions. Attached is the remainder of
> the patch that replaces all remaining std::bind with lambda expressions.
>
>
>>
>>> Apart from that I am not too familiar with lambdas yet, so for me
>>> personally
>>> the new code is more difficult to read than the old one ATM, and I am
>>> probably not the only one. Your explanation to Richard is nice, but
>>> it will
>>> soon be buried in email archives, and people reading LyX sources do
>>> not see
>>> it.
>>>
>>> I am not opposed to using lambdas (I hope I can learn soemthing from
>>> you
>>> here), but I believe that our developer documentation should contain
>>> a short
>>> motivation why they are used in LyX (you basically explained already to
>>> Richard how they make code more readable), and a pointer to a more
>>> detailed
>>> introduction to lambdas. Then it should also be possible for novices
>>> or old-
>>> timers like me to understand the new hot stuff.
>>
>> It wouldn't hurt to put some comments in the code, too.
>>
>
> I am happy to explain my code to anybody who asks. However, I am not
> going to introduce a motivation for lambda expressions in the developer
> manual nor add links to introductions. The old code was already using
> anonymous functions; that lambda expressions is better for anonymous
> functions is obvious to anybody familiar with lambda expressions; and
> the documentation is not meant to be a tutorial for ISO C++.

My own view is that our code is undercommented---and I know I'm as bad
about this as anyone. That said, I often add comments to code I have to read
to fix various bugs, if only for my own benefit later.

You're right that it's clear enough what the intent is in many cases.
But I don't
think that's always true, and it wastes more time to decode something
than it
would take to comment it. Generally, cases like:
[this]() { someFunction(); }
are obviously easy to read. It's more complicated when there are various
arguments. One might wonder in such cases why things are being copied
or passed by reference, for example.

> Neither am I going to add comments to the code affected by the patch,
> because nobody felt like requiring such comments for the old code.
> Whereas the std::bind version can be hard to read for anybody, the new
> code is self-explanatory for anybody familiar with lambda expressions,
> and comments are again not meant to explain the language. 

No doubt the std::bind versions are write-only, but that only illustrates
my point: Our code is undercommented. In this case, for example:

@@ -741,7 +740,9 @@ void PreviewLoader::Impl::startLoading(bool wait)
 // Initiate the conversion from LaTeX to bitmap images files.
 ForkedCall::SignalTypePtr
 convert_ptr(new ForkedCall::SignalType);
-convert_ptr->connect(bind(::finishedGenerating, this, _1, _2));
+convert_ptr->connect([this](pid_t p, int retval) {
+finishedGenerating(p, retval);
+});
 
 ForkedCall call(buffer_.filePath());
 int ret = call.startScript(command, convert_ptr);

I'm not sure that the original author's decision not to add a comment is
a reason we shouldn't add one.

> If other developers are not familiar with lambda expressions yet, then
> it is appropriate to wait before committing. Given that I do not know
> the source of my issue with gcc 4.6, it is appropriate to wait that
> support for gcc 4.6 is dropped (probably about a year from now).

I don't have a problem with the patch's being committed. But it's worth
remembering that most of us are amateurs. We don't all keep up with the
latest developments in compiler technology. As a result, discussions
about ways to make our codebase accessible to amateurs aren't at all
uncommon. I knew almost no C++ when I started working on LyX. The
way I learned, and especially the way I learned STL, was by doing.

What was the issue with gcc 4.6?

Richard

Re: Trojan warning from Windows defender

[Richard Heck]

On 07/02/2016 07:20 PM, Pavel Sanda wrote:
> Richard Heck wrote:
>> On 07/01/2016 04:00 PM, Pavel Sanda wrote:
>>> Cyrille Artho wrote:
>>>> Without https the signatures are not very useful.
>>> I fail to follow what do you mean by this.
>> Without https, a man-in-the-middle attack is possible, and of course
>> the signatures could also be faked. But I'm not sure that makes them
>> "not very useful". It just makes them not perfect.
> Man-in-the middle for pgp signature? You stay in the middle and you send
> me whatever packet you want. However you don't have my secret key for
> the signature. So what you are going to do to fake it?

Sorry, yes, you are right.

Richard

Re: [LyX/master] Fix windows dependencies download

[Richard Heck]

On 07/02/2016 02:17 PM, Uwe Stöhr wrote:
> Am 19.06.2016 um 13:03 schrieb Georg Baum:
>
>>> The paths and servers have changed, and a MSVC 2013 version is not
>>> provided anymore.
>
> Thanks Georg for having a look.
>
> However, this ZIP-file should be put on ftp.lyx.org and be used:
>
> http://ftp.lyx.de/LyX-Windows-Deps/
>
> Richard, could you please do this?

Where does this go?

Richard

Re: 5 more compiler warnings in master

[Richard Heck]

On 07/02/2016 02:28 PM, Uwe Stöhr wrote:
> Am 02.07.2016 um 20:15 schrieb Richard Heck:
>
>> All harmless.
>>
>> In future, you can fix these sorts of warnings easily.
>
> I understand the compiler warnings but it is not easy for me to decide
> if a truncation of values was intended or not. I mean if it is
> intended one should use int(). Since this is not done, I must assume
> that this was not intended.

This sort of thing is known as an "implicit conversion". It happens all
the time. For example, consider the following:
Type * type_ptr;

if (type_ptr) {
...do something...
}
This involves an implicit conversion from Type* to a bool.

You get the warning in the case of a conversion from double to int
because, as it says, there /could/ be a loss of data. But such
conversions are still quite common.

>
>> int const y_bar = deleted() ? y - fm.maxAscent() / 3
>> : y + 2 * pi.base.solidLineOffset() +
>> pi.base.solidLineThickness();
>>
>> Here, we clearly do want to do that, since the function to which
>> we're about to
>> pass y_bar wants an int, too.
>
> That is not clear to me. How can I know that we want to floor the
> result of a division. Do we really want to get 2 if fm.maxAscent() is
> either 6, 7 or 8? That is quite strange to me. Another question arises
> if we want the truncation: why do we divide by 3 not e.g. 4?

Well, there's a comment just above:

// Calculate 1/3 height of font

Granted, one might have used rounding here. But, so far as I am aware,
no bug has been reported about the drawing of change markers. And adding
int(...) does not change behavior.

> That is why I report the warnings uncommented. It might be that it is
> obvious for others but for me they are not.

As I said, you just have to read the code. If you don't understand it,
or can't figure out what's intended, then that would be the right time
to report the warning.

Richard

LyX 2.2.1

[Richard Heck]

We have already fixed at least 43 bugs for 2.2.1, and we now also have
the possibility, thanks to Dima, to release a binary that will run on
Windows Vista. So it looks like a good time to start thinking about the
release of LyX 2.2.1.

The question at the moment is whether there is anything pressing we need
to do before that release. You can find a list of open bugs with a 2.2.1
milestone here:

   
http://www.lyx.org/trac/wiki/BugTrackerHome#Unresolvedbugstargetedtonextmaintenancerelease2.2.1

Other suggestions are also acceptable

Richard

Re: Contextual shortcuts

[Richard Heck]

On 07/02/2016 04:44 AM, Franck Vasseur wrote:
>
> Hello,
>
>  
>
> I am just discovering LyX, which seems to be a very nice tool to edit
> all kind of documents.
>
>  
>
> I am most interested by editing mathematic texts, and when using LyX,
> I have wondered if it were possible to create contextual shortcuts (as
> these used in TeXmacs).
>
> For instance, when one writes mathematics, why do they have to begin
> every shortcut with “Alt-M” ?
>
>  
>
> Moreover, some shortcuts which could be very useful in a precise
> situation are already used: with a contextual shortcut, they could be
> used in a different way.
>
> Example : you type a sum (capital sigma) and then, Up and Down arrow
> buttons will allow you to type the beginning and end of the summing.
>
>  
>
> So, the idea is to simplify and improve the speed of typing by using
> shortcuts which depend from:
>
>   * the environment (text, formula...)
>   * the previous symbol you have typed
>
> Another idea (also used in TeXmacs) is to group a few similar
> mathematical symbols: you type one of them and replace it by the next
> of the group by using “Tab”. This is a way to avoid remembering all
> the shortcuts for all the symbols of the group.
>
> Example: the symbol of multiplication is typed with “*” and displayed
> as a small space, but can be replaced by a “×”, or a “.” or even a “*”
> by using “Tab”.
>
>  
>
> Whatever you decide, thank you very much for your amazing work.
>

Please file an enhancement request for this. It's an idea that's been
suggested before, and one that would make certain things much easier.

Note that there are some cases in which keys work differently depending
upon where you are. See the documentation under Help> LyX Functions for
"command-alternatives". But this only works when some of the commands
aren't legal in certain contexts.

Richard

Re: [LyX/master] Fix CAS input on windows (bug 10262)

[Richard Heck]

On 07/02/2016 01:09 PM, Georg Baum wrote:
> Georg Baum wrote:
>
>> commit 6dfc255088ecd3393c4c5dc3d2c5357a3fbabfc0
>> Author: Georg Baum 
>> Date:   Sat Jul 2 18:58:30 2016 +0200
>>
>> Fix CAS input on windows (bug 10262)
>> 
>> This is the well known file locking problem: The TempFile class keeps
>> the created file locked for the own process, and this prevents the CAS
>> to read it.
>> ---
>>  src/mathed/MathExtern.cpp |9 +++--
>>  1 files changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/mathed/MathExtern.cpp b/src/mathed/MathExtern.cpp
>> index b3443fa..8b1e0f0 100644
>> --- a/src/mathed/MathExtern.cpp
>> +++ b/src/mathed/MathExtern.cpp
>> @@ -1001,8 +1001,13 @@ namespace {
>>  {
>>  // In order to avoid parsing problems with command interpreters
>>  // we pass input data through a file
>> -TempFile tempfile("casinput");
>> -FileName const cas_tmpfile = tempfile.name();
>> +// Since the CAS is supposed to read the temp file we 
> need
>> +// to unlock it on windows (bug 10262).
>> +unique_ptr tempfile(new TempFile("casinput"));
>> +tempfile->setAutoRemove(false);
>> +FileName const cas_tmpfile = tempfile->name();
>> +tempfile.reset();
>> +
>>  if (cas_tmpfile.empty()) {
>>  lyxerr << "Warning: cannot create temporary file."
>>  << endl;
> Richard, OK for 2.2 (with auto_ptr instead of unique_ptr)?

Yes, looks good.

Richard

Re: [LyX/master] By default, charstyles should not permit layout changes internally.

[Richard Heck]

On 07/02/2016 11:45 AM, Georg Baum wrote:
> Richard Heck wrote:
>
>> commit 152817576adaefaa1be8f124b9feecd5c2bfd7c2
>> Author: Richard Heck <rgh...@lyx.org>
>> Date:   Mon Jun 20 11:30:32 2016 -0400
>>
>> By default, charstyles should not permit layout changes internally.
>> 
>> Fixes #10237.
> This makes the tex2lyx tests fail (see attachment). I guess the new version 
> is correct?

Yes, that's right.

Richard

Re: 5 more compiler warnings in master

[Richard Heck]

On 07/02/2016 11:42 AM, Uwe Stöhr wrote:
> Since I am now able to compile master again with the latest MSVC 2015
> compiler, I get these new warnings:
>
> D:\LyXGit\Master\src\Changes.cpp(562): warning C4244: 'initializing':
> conversion from 'double' to 'int', possible loss of data
> [D:\LyXGit\Master\compile-2015\src\LyX.vcxproj]
>
> D:\LyXGit\Master\src\Changes.cpp(562): warning C4244: 'initializing':
> conversion from 'double' to 'const int', possible loss of data
> [D:\LyXGit\Master\compile-2015\src\LyX.vcxproj]
>
> D:\LyXGit\Master\src\Changes.cpp(592): warning C4244: 'argument':
> conversion from 'double' to 'int', possible loss of data
> [D:\LyXGit\Master\compile-2015\src\LyX.vcxproj]
>
> D:\LyXGit\Master\src\Changes.cpp(592): warning C4244: 'argument':
> conversion from 'const double' to 'int', possible loss of data
> [D:\LyXGit\Master\compile-2015\src\LyX.vcxproj]
>
> D:\LyXGit\Master\src\RowPainter.cpp(208): warning C4244: 'argument':
> conversion from 'double' to 'int', possible loss of data
> [D:\LyXGit\Master\compile-2015\src\LyX.vcxproj]

All harmless.

In future, you can fix these sorts of warnings easily.  For the first
one, just go to line 562 of Changes.cpp. What was there was:

int const y_bar = deleted() ? y - fm.maxAscent() / 3
: y + 2 * pi.base.solidLineOffset() + pi.base.solidLineThickness();

The compiler is complaining that y - fm.maxAscent() / 3 is a double (as
is the other expression), and it is being assigned to an int. Here, we
clearly do want to do that, since the function to which we're about to
pass y_bar wants an int, too. So the solution is just:

int const y_bar = int(deleted() ? y - fm.maxAscent() / 3
: y + 2 * pi.base.solidLineOffset() + pi.base.solidLineThickness());

I.e., we tell the compiler that we definitely do want to convert the
value to an int.

Richard

Re: Reintroduce Windows Vista compatibility for 2.2.0+

[Richard Heck]

On 07/02/2016 04:28 AM, Georg Baum wrote:
> Richard Heck wrote:
>> Now we just need an installer built this way.
> My proposal would be to release 2.2.1 soon and do not build an additional 
> 2.2.0 installer. This avoids confusion for users (why so many 2.2.0 
> installers?), contradicting news items (2.2.0 does not support vista, 2.2.0 
> supports vista), and additional testing work. Also, 2.2.1 has already 
> accumulated lots of bug fixes, including a rather important lyx2lyx bug 
> 10243 which could lead to data loss. The 2.2.1 announcement could then state 
> that vista is supported again.

I was planning to write about this early next week, anyway, so perhaps
this is the best way to go.

I'll send a "Planning for 2.2.1" email soon.

Richard

Re: Reintroduce Windows Vista compatibility for 2.2.0+

[Richard Heck]

On 07/01/2016 04:13 PM, Georg Baum wrote:

Dima Ruinskiy wrote:


As of version 2.2.0, LyX no longer works out of the box on Windows Vista,
probably because of some default settings in MSVC2015.


This patch fixes that by forcing a PSAPI version that is compatible with
Vista as well as later versions of Windows.


Tested on master and 2.2.x branches, with Vista and 8.1.

Thank you very much. I put it in master:
http://www.lyx.org/trac/changeset/03cfeae/lyxgit

Richard, OK for branch as well?


Yes, that's fine.

Did anyone add Dima to the credits?

Now we just need an installer built this way.

Richard

Re: Trojan warning from Windows defender

[Richard Heck]

On 07/01/2016 04:00 PM, Pavel Sanda wrote:

Cyrille Artho wrote:

Without https the signatures are not very useful.

I fail to follow what do you mean by this.


Without https, a man-in-the-middle attack is possible, and of course
the signatures could also be faked. But I'm not sure that makes them
"not very useful". It just makes them not perfect.

Richard

Re: Weird KDE Bug in LyX

[Richard Heck]

On 07/01/2016 05:21 AM, José Abílio Matos wrote:

On Thursday, June 30, 2016 4:26:40 PM WEST Richard Heck wrote:

For anyone running LyX 2.2.0 under KDE (or using a KDE-based window
manager, or anything of that sort):

There is an annoying new feature, KDE's "accelerator manager", that
automatically adds shortcuts. This causes conflicts and so forth in many
Qt-based programs, when those programs are run with Qt5. If you are
experiencing this issue, please see
  http://www.lyx.org/trac/ticket/10261#comment:16
for a workaround.

Richard Heck

I reported that in March:
http://permalink.gmane.org/gmane.editors.lyx.devel/160859

I would like to see a workaround since it is really annoying but I do not seem
able to access the tracker.


Add

[Development]
AutoCheckAccelerators=false
CopyWidgetText=false

to $HOME/.config/kdeglobals

Richard

Re: compilation error in branch and master

[Richard Heck]

On 06/30/2016 07:36 PM, Uwe Stöhr wrote:

compiling today's 2.2.x branch and master I get this compilation error:

  environment.cpp
D:\LyXGit\Master\src\support\environment.cpp(73): fatal error C1189: 
#error:  No environment-setting function has been defined. 
[D:\LyXGit\Master\compile-2015\src\support\support.vcxproj]


Something has changed in your build system. None of that code has been 
touched for many years.


Richard

Re: compilation warning in master

[Richard Heck]

On 06/30/2016 07:34 PM, Uwe Stöhr wrote:

Compiling today's master I get this warning:

  InsetSeparator.cpp
D:\LyXGit\Master\src\insets\InsetSeparator.cpp(213): warning C4244: 
'+=': conversion from 'double' to 'int', possible loss of data 
[D:\LyXGit\Master\compile-2015\src\insets\insets.vcxproj]


Harmless but fixed.

rh

Weird KDE Bug in LyX

[Richard Heck]

For anyone running LyX 2.2.0 under KDE (or using a KDE-based window 
manager, or anything of that sort):


There is an annoying new feature, KDE's "accelerator manager", that 
automatically adds shortcuts. This causes conflicts and so forth in many 
Qt-based programs, when those programs are run with Qt5. If you are 
experiencing this issue, please see

http://www.lyx.org/trac/ticket/10261#comment:16
for a workaround.

Richard Heck

Re: [LyX/master] Output column width info for XHTML.

[Richard Heck]

On 06/30/2016 02:24 AM, Scott Kostyshak wrote:

On Thu, Jun 30, 2016 at 12:05:18AM -0400, Richard Heck wrote:


Try this:

--- src/insets/InsetTabular.cpp
+++ src/insets/InsetTabular.cpp
@@ -2989,17 +2989,20 @@ docstring Tabular::xhtmlRow(XHTMLStream & xs,
row_type row,
  
  xs << html::StartTag("tr");

  for (col_type c = 0; c < ncols(); ++c) {
+bool didone = false;
  if (isPartOfMultiColumn(row, c) || isPartOfMultiRow(row, c))
  continue;
  
  stringstream attr;
 
  Length const cwidth = column_info[c].p_width;

-if (!cwidth.zero()) {
+if (!didone && !cwidth.zero()) {
  string const hwidth = cwidth.asHTMLString();
  attr << "style =\"width: " << hwidth << ";\" ";
  }
 
+didone = true;

+
  attr << "align='";
  switch (getAlignment(cell)) {
  case LYX_ALIGN_LEFT:

If it works, go ahead and put it in.

Richard


That doesn't work because the function is called for each row so didone
is initialized to false for each row. If the inner loop were over rows
then I think it would work (but would need to be outside of the loop).

We could do something like:

diff --git a/src/insets/InsetTabular.cpp b/src/insets/InsetTabular.cpp
index 7804232..5b76455 100644
--- a/src/insets/InsetTabular.cpp
+++ b/src/insets/InsetTabular.cpp
@@ -2995,7 +2995,7 @@ docstring Tabular::xhtmlRow(XHTMLStream & xs, row_type 
row,
 stringstream attr;
 
 Length const cwidth = column_info[c].p_width;

-   if (!cwidth.zero()) {
+   if (!cwidth.zero() && row == 0) {
 string const hwidth = cwidth.asHTMLString();
 attr << "style =\"width: " << hwidth << ";\" ";
 }

If you like that then put it in, but perhaps it is just better to stick
with your original commit. I have no idea how this would work with e.g.
multicolumns. Your call.


I thought of this, too, but I worried that it would not work properly 
with multicolumns.


Maybe better to stick with the original.

Richard

Re: [LyX/master] Output column width info for XHTML.

[Richard Heck]

On 06/29/2016 10:11 PM, Scott Kostyshak wrote:
> On Thu, Jun 30, 2016 at 03:48:01AM +0200, Richard Heck wrote:
>> commit ddc28f0374478355217f975a25e544af7dbc8ea9
>> Author: Richard Heck <rgh...@lyx.org>
>> Date:   Wed Jun 29 21:47:51 2016 -0400
>>
>> Output column width info for XHTML.
>> ---
>>  src/insets/InsetTabular.cpp |7 +++
>>  1 files changed, 7 insertions(+), 0 deletions(-)
>>
>> diff --git a/src/insets/InsetTabular.cpp b/src/insets/InsetTabular.cpp
>> index 7728a1a..7804232 100644
>> --- a/src/insets/InsetTabular.cpp
>> +++ b/src/insets/InsetTabular.cpp
>> @@ -2993,6 +2993,13 @@ docstring Tabular::xhtmlRow(XHTMLStream & xs, 
>> row_type row,
>>  continue;
>>  
>>  stringstream attr;
>> +
>> +Length const cwidth = column_info[c].p_width;
>> +if (!cwidth.zero()) {
>> +string const hwidth = cwidth.asHTMLString();
>> +attr << "style =\"width: " << hwidth << ";\" ";
>> +}
>> +
>>  attr << "align='";
>>  switch (getAlignment(cell)) {
>>  case LYX_ALIGN_LEFT:
> I just tested and it works well. Is there a reason to specify the column
> width for each row instead of just for each column? In the sample
> document at #8168, the HTML output now contains four instances of '3cm'.
> Ideally shouldn't it just contain one? For example, as specified at [1].

Try this:

--- src/insets/InsetTabular.cpp
+++ src/insets/InsetTabular.cpp
@@ -2989,17 +2989,20 @@ docstring Tabular::xhtmlRow(XHTMLStream & xs,
row_type row,
 
 xs << html::StartTag("tr");
 for (col_type c = 0; c < ncols(); ++c) {
+bool didone = false;
 if (isPartOfMultiColumn(row, c) || isPartOfMultiRow(row, c))
 continue;
 
 stringstream attr;

 Length const cwidth = column_info[c].p_width;
-if (!cwidth.zero()) {
+if (!didone && !cwidth.zero()) {
 string const hwidth = cwidth.asHTMLString();
 attr << "style =\"width: " << hwidth << ";\" ";
 }

+didone = true;
+   
 attr << "align='";
 switch (getAlignment(cell)) {
 case LYX_ALIGN_LEFT:

If it works, go ahead and put it in.

Richard

Re: ancient history, v 0.10.7 beta

[Richard Heck]

On 06/29/2016 08:32 PM, PhilipPirrip wrote:
> For those interested in ancient history of LyX: I've just found my
> first Linux distribution CD, with LyX 0.10.7 from October 1996 on it.
> Online sources I found go only about 18 years back.
> JMarc still probably has it somewhere, this is for all others:
> http://wiki.lyx.org/uploads/Devel/ancient/
>
> Happy 21st birthday, LyX!

I guess we should all have a beer.

Richard

Re: Trojan warning from Windows defender

[Richard Heck]

On 06/29/2016 12:35 AM, Cyrille Artho wrote:

Richard Heck wrote:

On 06/27/2016 03:31 PM, Henrik Kragh wrote:

Hi,

I haven't used the mailing list before so I hop eI have reached the
right one.

I have used Lyx for some and has recently upgraded to Win10. I have
downloaded the two different installers (ended up using the bundle).
However today windows defender suddently tells me that there is a
trojan in the installer(Tjojan: Win32/Varpes.M!ch) Is that something
you have seen or is it Windows defender that is iterpreting this 
wrongly ?


Thanks for reporting this. We have not had other reports of it.

I just scanned both installers with Comodo AV, and it reported no 
problems.


Did you check the signature on the files?

Richard

Good point: We host the web page on a server that supports https, yet 
the downloads are all hosted on sources that do not use authentication 
and encryption.
Is it possible to offer mirrors supporting https? Perhaps at least for 
the signatures? (Without https the signatures are not very useful.)


We could put the signatures also somewhere else, since lyx.org at least 
does support https now.


Richard

[RFC] Canceling Background Export

[Richard Heck]

I'm attaching a set of patches that allow for cancellation of background 
processes. When you start a view or update or whatever, you will get an 
extra menu entry in the Document menu. You can also use "export-cancel" 
in the minibuffer.


It's rough in various ways, such as giving misleading error messages. 
But it works. The code can also be found here:


http://git.lyx.org/?p=developers/rgheck/lyx.git;a=shortlog;h=refs/heads/bugs/CancelExport-2

Comments very welcome. Better yet, patches that fix some of the ugliness.

Richard

>From d0fb9f44ffa879d54cb0a1c8bd4664e7ecbcd2e1 Mon Sep 17 00:00:00 2001
From: Richard Heck <rgh...@lyx.org>
Date: Tue, 28 Jun 2016 16:52:29 -0400
Subject: [PATCH 1/6] LFUN and basic code to enable cancellation of background
 processes.

---
 lib/ui/stdmenus.inc   | 1 +
 lib/ui/stdtoolbars.inc| 1 +
 src/FuncCode.h| 1 +
 src/LyXAction.cpp | 9 +
 src/frontends/Application.h   | 3 ++-
 src/frontends/qt4/GuiView.cpp | 9 -
 6 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/lib/ui/stdmenus.inc b/lib/ui/stdmenus.inc
index 62ed8e2..9267718 100644
--- a/lib/ui/stdmenus.inc
+++ b/lib/ui/stdmenus.inc
@@ -530,6 +530,7 @@ Menuset
 		UpdateFormats
 		OptItem "View Master Document|M" "master-buffer-view"
 		OptItem "Update Master Document|a" "master-buffer-update"
+		OptItem "Cancel Background Process|P" "export-cancel"
 		Separator
 		Item "Compressed|o" "buffer-toggle-compression"
 		Item "Disable Editing|E" "buffer-toggle-read-only"
diff --git a/lib/ui/stdtoolbars.inc b/lib/ui/stdtoolbars.inc
index d375afa..63e7423 100644
--- a/lib/ui/stdtoolbars.inc
+++ b/lib/ui/stdtoolbars.inc
@@ -102,6 +102,7 @@ ToolbarSet
 		Item "Update" "buffer-update"
 		Item "View master document" "master-buffer-view"
 		Item "Update master document" "master-buffer-update"
+#		Item "Cancel export" "export-cancel"
 		Item "Enable Forward/Reverse Search" "buffer-toggle-output-sync"
 		Separator
 		StickyPopupMenu "view-others" "View other formats"
diff --git a/src/FuncCode.h b/src/FuncCode.h
index 40ec9d3..6daa40d 100644
--- a/src/FuncCode.h
+++ b/src/FuncCode.h
@@ -465,6 +465,7 @@ enum FuncCode
 	// 340
 	LFUN_BUFFER_MOVE_PREVIOUS,  // skostysh 20150408
 	LFUN_TABULAR_FEATURE,   // gm, 20151210
+	LFUN_EXPORT_CANCEL, // rgh, 20160627
 	LFUN_LASTACTION // end of the table
 };
 
diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index 3702810..ee53893 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -3152,6 +3152,15 @@ void LyXAction::init()
  */
 		{ LFUN_BUFFER_EXPORT_AS, "buffer-export-as", ReadOnly, Buffer },
 /*!
+ * \var lyx::FuncCode lyx::LFUN_EXPORT_CANCEL
+ * \li Action: Cancels a background export process
+ * \li Syntax: export-cancel
+ * \li Origin: rgh, 2 November 2011
+ * \endvar
+ */
+		{ LFUN_EXPORT_CANCEL, "export-cancel", ReadOnly, Buffer },
+
+/*!
  * \var lyx::FuncCode lyx::LFUN_BUFFER_IMPORT
  * \li Action: Import a given file as a lyx document.
  * \li Notion: File can be imported iff lyx file format is (transitively) reachable via
diff --git a/src/frontends/Application.h b/src/frontends/Application.h
index df0be95..a67b838 100644
--- a/src/frontends/Application.h
+++ b/src/frontends/Application.h
@@ -166,7 +166,7 @@ class Application
 {
 public:
 	///
-	Application() {}
+	Application() : cancel_export(false) {}
 	///
 	virtual ~Application() {}
 
@@ -251,6 +251,7 @@ public:
 	/// A started long operation is still in progress ?
 	virtual bool longOperationStarted() = 0;
 
+bool cancel_export;
 };
 
 /// Return the list of loadable formats.
diff --git a/src/frontends/qt4/GuiView.cpp b/src/frontends/qt4/GuiView.cpp
index 429def5..65f0168 100644
--- a/src/frontends/qt4/GuiView.cpp
+++ b/src/frontends/qt4/GuiView.cpp
@@ -1857,6 +1857,10 @@ bool GuiView::getStatus(FuncRequest const & cmd, FuncStatus & flag)
 		enable = doc_buffer != 0;
 		break;
 
+	case LFUN_EXPORT_CANCEL:
+		enable = d.processing_thread_watcher_.isRunning();
+		break;
+
 	case LFUN_BUFFER_CLOSE:
 	case LFUN_VIEW_CLOSE:
 		enable = doc_buffer != 0;
@@ -3602,6 +3606,10 @@ void GuiView::dispatch(FuncRequest const & cmd, DispatchResult & dr)
 		0, ::preview);
 			break;
 		}
+		case LFUN_EXPORT_CANCEL: {
+			theApp()->cancel_export = true;
+			break;
+		}
 		case LFUN_BUFFER_SWITCH: {
 			string const file_name = to_utf8(cmd.argument());
 			if (!FileName::isAbsolute(file_name)) {
@@ -4484,7 +4492,6 @@ Dialog * GuiView::build(string const & name)
 	return 0;
 }
 
-
 } // namespace frontend
 } // namespace lyx
 
-- 
2.5.0

>From a8e7459704decce894a133902bcf86dda261a3d3 Mon Sep 17 00:00:00 2001
From: Richard Heck <rgh...@ly

Re: europeCV and modernCV ctests sometimes failing

[Richard Heck]

On 06/28/2016 06:35 AM, Kornel Benko wrote:

Scott figured out that the failing has to do with character '_' being part
of his local path supplied to the 'Picture' style. Lyx changes the character to 
'\_',
consequently the picture is not found.

Extending the 'Picture' style with 'PassThru true' seems the right way, see 
attached.

OK for master _and_ branch2.2?


Fine for stable if someone else confirms it for master. I never use 
these layouts so can't have an opinion on the correctness of the change.


rh

Re: Trojan warning from Windows defender

[Richard Heck]

On 06/27/2016 03:31 PM, Henrik Kragh wrote:
> Hi,
>
> I haven't used the mailing list before so I hop eI have reached the
> right one.
>
> I have used Lyx for some and has recently upgraded to Win10. I have
> downloaded the two different installers (ended up using the bundle).
> However today windows defender suddently tells me that there is a
> trojan in the installer(Tjojan: Win32/Varpes.M!ch) Is that something
> you have seen or is it Windows defender that is iterpreting this wrongly ?

Thanks for reporting this. We have not had other reports of it.

I just scanned both installers with Comodo AV, and it reported no problems.

Did you check the signature on the files?

Richard

Re: Anonymous functions: replace bind with lambdas

[Richard Heck]

On 06/27/2016 04:14 PM, Georg Baum wrote:
> Guillaume Munch wrote:
>
>> Dear list,
>>
>>
>> Here is a patch that removes all uses of std::bind and boost::bind in
>> src/. I think this is something that we want in the long term, because
>> it makes the changed code much more readable and maintainable.
> You mean std::bind, or did I miss any remaining boost::bind?
>
>> I am conflicted about it, be cause I would like to be eventually able to
>> read and maintain things that have to do with concurrency, but I would
>> not like to introduce hard-to-debug crashes. It no longer crashes for
>> me, but I did not understand the cause of the previous crash.
>>
>> Any advice? Also, since this touches a lot of sensitive code it would
>> not hurt if someone offered to proof-read it.
> For me personally the patch is too big to proof-read it. I'd prefer to 
> change simple things like
>
> -   BufferStorage::iterator it = bstore.begin();
> -   BufferStorage::iterator end = bstore.end();
> -   for (; it != end; ++it) {
> -   Buffer * buf = *it;
> +   for(Buffer * buf : bstore)
>
> which are not related to removal of std::bind first.

Yes, that's a good idea.

> Apart from that I am not too familiar with lambdas yet, so for me personally 
> the new code is more difficult to read than the old one ATM, and I am 
> probably not the only one. Your explanation to Richard is nice, but it will 
> soon be buried in email archives, and people reading LyX sources do not see 
> it.
>
> I am not opposed to using lambdas (I hope I can learn soemthing from you 
> here), but I believe that our developer documentation should contain a short 
> motivation why they are used in LyX (you basically explained already to 
> Richard how they make code more readable), and a pointer to a more detailed 
> introduction to lambdas. Then it should also be possible for novices or old-
> timers like me to understand the new hot stuff.

It wouldn't hurt to put some comments in the code, too.

Richard

Re: Anonymous functions: replace bind with lambdas

[Richard Heck]

On 06/26/2016 03:20 PM, Guillaume Munch wrote:

+   auto compile = [&](std::string const & s) {
+   return clone->doExport(s, true);
+   };
+   return runAndDestroy(compile, orig, clone, format);


This one, too, and the other auto one that follows it.

rh

Re: Anonymous functions: replace bind with lambdas

[Richard Heck]

Some explanatory comments in this stuff would help, too. These complex 
constructions are nice in reducing code, but they are hard for novices 
to read without help.


rh


On 06/26/2016 03:20 PM, Guillaume Munch wrote:

+namespace {
+
+template
+typename std::result_of::type call(F f) {
+#if EXPORT_in_THREAD
+   return call_in_gui_thread(f);
+#else
+   return f();
+#endif
+}
+
+} // anon namespace
+
+
  void noAppDialog(QString const & title, QString const & msg, 
QMessageBox::Icon mode)
  {
int argc = 1;
@@ -136,13 +150,10 @@ int prompt(docstring const & title0, docstring const & 
question,
  docstring const & b1, docstring const & b2,
  docstring const & b3, docstring const & b4)
  {
-#ifdef EXPORT_in_THREAD
-   return InGuiThread().call(,
-#else
-   return doPrompt(
-#endif
-   title0, question, default_button,
-   cancel_button, b1, b2, b3, b4);
+   return call([&, default_button, cancel_button] () {
+   return doPrompt(title0, question, default_button,
+   cancel_button, b1, b2, b3, b4);
+   });
  }
  

Custom Insets on a Menu

[Richard Heck]

The attached patch almost works. (Details like the icon are not yet 
there.) There are some big problems, however, which seem to derive from 
the fact that the whole menu and toolbar setup is not really designed to 
be modified on the fly.


The problem here seems to trace to how FuncRequest objects are handled 
by our Action class. Namely, when an Action is created, it retains a 
const & to a FuncRequest. So one can't pass a temporary. This means that 
I have to create a kind of cache for these objects. The idea was to keep 
them around as long as we need them. But it turns out that we need them 
rather a long time. If you look at the FIXME in the patch, you will see 
what I mean. Clearing the menu is supposed to delete any actions it owns:


void QMenu::clear ()
Removes all the menu's actions. Actions owned by the menu and not shown 
in any other widget are deleted.


In fact, however, they seem still to be around, and if we clear the 
cache we eventually segfault. If we don't clear the cache, we are 
effectively leaking memory.


I can make this work by changing the Action class so it makes a copy of 
the FuncRequest. But I worry that this is just hiding the real problem, 
and that all these Action objects we're creating are leaking, or at 
least being retained for no good reason.


Help wanted!

Richard

>From 13a9c8f7571f4451e3ffef16dc19bdd08be86add Mon Sep 17 00:00:00 2001
From: Richard Heck <rgh...@lyx.org>
Date: Fri, 24 Jun 2016 17:47:30 -0400
Subject: [PATCH] Attempt to do the inset thing with a menu.

---
 lib/ui/stdtoolbars.inc   |   2 +
 src/frontends/qt4/GuiToolbar.cpp | 120 +++
 src/frontends/qt4/GuiToolbar.h   |  24 
 src/frontends/qt4/GuiView.cpp|   2 +-
 src/frontends/qt4/GuiView.h  |   2 +
 src/frontends/qt4/Toolbars.cpp   |   9 ++-
 src/frontends/qt4/Toolbars.h |   4 +-
 7 files changed, 160 insertions(+), 3 deletions(-)

diff --git a/lib/ui/stdtoolbars.inc b/lib/ui/stdtoolbars.inc
index d375afa..c504e4a 100644
--- a/lib/ui/stdtoolbars.inc
+++ b/lib/ui/stdtoolbars.inc
@@ -95,6 +95,8 @@ ToolbarSet
 		Item "Toggle outline" "dialog-toggle toc"
 		Item "Toggle math toolbar" "toolbar-toggle math"
 		Item "Toggle table toolbar" "toolbar-toggle table"
+		Separator
+		Insets
 	End
 
 	Toolbar "view/update" "View/Update"
diff --git a/src/frontends/qt4/GuiToolbar.cpp b/src/frontends/qt4/GuiToolbar.cpp
index 77471c9..094617d 100644
--- a/src/frontends/qt4/GuiToolbar.cpp
+++ b/src/frontends/qt4/GuiToolbar.cpp
@@ -25,19 +25,27 @@
 #include "InsertTableWidget.h"
 #include "LayoutBox.h"
 #include "qt_helpers.h"
+#include "TextClass.h"
 #include "Toolbars.h"
 
+#include "Buffer.h"
+#include "BufferParams.h"
+#include "BufferView.h"
+#include "Cursor.h"
 #include "FuncRequest.h"
 #include "FuncStatus.h"
 #include "KeyMap.h"
 #include "LyX.h"
 #include "LyXRC.h"
 #include "Session.h"
+#include "Text.h"
 
 #include "support/debug.h"
 #include "support/gettext.h"
 #include "support/lstrings.h"
 
+#include 
+
 #include 
 #include 
 #include 
@@ -263,6 +271,114 @@ void MenuButton::updateTriggered()
 }
 
 
+class InsetMenuButton::Private
+{
+	/// noncopyable
+	Private(Private const &);
+	void operator=(Private const &);
+public:
+	Private() : inset_(0)
+	{}
+
+	/// since Action retains a reference to the
+	/// FuncRequest, we need to keep these around
+	typedef std::list FuncCache;
+	///
+	DocumentClassConstPtr text_class_;
+	///
+	InsetText const * inset_;
+	///
+	FuncCache fcache_;
+};
+
+
+InsetMenuButton::InsetMenuButton(GuiToolbar * bar)
+	: QToolButton(bar), bar_(bar), d(new Private())
+{
+	setPopupMode(QToolButton::InstantPopup);
+	QString const label = qt_("Add Custom Inset");
+	setToolTip(label);
+	setStatusTip(label);
+	setText(label);
+	connect(bar, SIGNAL(iconSizeChanged(QSize)),
+		this, SLOT(setIconSize(QSize)));
+	initialize();
+}
+
+
+void InsetMenuButton::initialize()
+{
+	QString const label = qt_("Add Custom Inset");
+
+	QMenu * m = new QMenu(label, this);
+	m->setWindowTitle(label);
+	m->setTearOffEnabled(true);
+	setMenu(m);
+
+	connect(bar_, SIGNAL(updated()), this, SLOT(updateTriggered()));
+	updateTriggered();
+}
+
+
+void InsetMenuButton::updateTriggered()
+{
+	GuiView const & owner = bar_->owner();
+	BufferView const * bv = owner.currentBufferView();
+	QMenu * m = menu();
+	if (!bv) {
+		if (m)
+			m->clear();
+		setEnabled(false);
+		setMinimumWidth(sizeHint().width());
+		d->text_class_.reset();
+		d->inset_ = 0;
+			d->fcache_.clear();
+		return;
+}
+
+	// we'll only update the inset list if the text class has changed
+	// or we've moved from one inset to another
+	Docume

Re: Combo Box for Custom Insets

[Richard Heck]

On 06/26/2016 07:33 AM, Jean-Marc Lasgouttes wrote:

Le 25/06/2016 23:41, Richard Heck a écrit :

But then it doesn't work with non-LyX-provided insets, i.e., ones you
make yourself. If you had a lot of such insets, this would get very
messy, too.

I'd be happy if it were done as an icon-based menu. As I've said, I just
don't know how to do that.


I do not know either. Your solution is probably the best we can do 
right now.


Actually, I've taken up the challenge and have something that almost 
works


Richard

Re: workaround to 'git reset --hard' not working because of .gitattributes

[Richard Heck]

On 06/25/2016 08:21 PM, Scott Kostyshak wrote:

Just in case anyone else has this issue:

I keep having the following situation come up:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
   (use "git add ..." to update what will be committed)
   (use "git checkout -- ..." to discard changes in working directory)

 modified:   3rdparty/hunspell/1.3.3/src/hunspell/hunspell.dsp
 modified:   
development/Win32/packaging/installer/information/WinLangCode.htm
 modified:   development/Win32/vld/src/crtmfcpatch.h
 modified:   development/Win32/vld/src/resource.h
 modified:   development/Win32/vld/src/vld.h

no changes added to commit (use "git add" and/or "git commit -a")
$

I think this is due to the recent fixes in .gitattributes. In any case,
git reset --hard does not fix anything. But the following does work for
me:

git rm .gitattributes
git add -A
git reset --hard


Thanks, Scott. I've also seen this problem though, oddly, only in some 
copies of the repo I have checked out. Playing with core.autocrlf does 
not seem to have helped, either.


Richard

Re: new LyX 2.2.0 installer for Windows Vista is available

[Richard Heck]

On 06/25/2016 12:00 PM, Georg Baum wrote:
> Uwe Stöhr wrote:
>
>> Richard, could you please put it on ftp.lyx.org? Could you please also
>> write a news message that we now have a Vista installer but that this
>> installer should not be used for other Windows versions than Vista.
> This is not possible for legal reasons. Our own license forbids to 
> distribute binaries without corresponding source code. This includes the 
> build scripts (see https://www.lyx.org/License):
>
> "The source code for a work means the preferred form of the work for making 
> modifications to it. For an executable work, complete source code means all 
> the source code for all modules it contains, plus any associated interface 
> definition files, plus the scripts used to control compilation and 
> installation of the executable."
>
> I am preaching since years that every binary we distribute must be built in 
> a reproducible way from identifiable, publicy available sources (including 
> the build scripts).
>
> Currently only our own OS X build and the linux builds offered by Livio and 
> linux distributors are 100% reproducible. The windows installer is not, the 
> build instructions are incomplete and partially wrong, and a binary 
> dependency package is needed which contains unneeded stuff such as old MSVC 
> dlls. How this binary dependency package was produced is unknown and not 
> reproducible.
>
> Adding two binaries from a different source to the installer makes it even 
> more unreproducible. We need to go into the other direction. That is also 
> the reason why I spend lots of time for helping others with MSVC and cmake, 
> although I have zero benefit from it personally.

I'll ask again: What is the status of the mingw build? Last I heard, it
built our executables fine and the only issue was with building the
installer.

Richard

Re: Combo Box for Custom Insets

[Richard Heck]

On 06/25/2016 04:55 PM, Jean-Marc Lasgouttes wrote:
> Le 25/06/2016 22:37, Guillaume Munch a écrit :
>> Le 25/06/2016 19:15, Richard Heck a écrit :
>>>
>>> For now, the branch is here:
>>> http://git.lyx.org/?p=developers/rgheck/lyx.git;a=shortlog;h=refs/heads/features/CustomInsets
>>>
>>>
>>>
>>
>> If you are satisfied with it then you could commit it, I think.
>> What is your plan?
>
> Another possibility would be that the Insets toolbar tag inserts a
> series of icons. One would just have to provide the relevant icons.
> This is a better UI that a Combox IMO. The difficulty here is not the
> code, but providing correct icons.

But then it doesn't work with non-LyX-provided insets, i.e., ones you
make yourself. If you had a lot of such insets, this would get very
messy, too.

I'd be happy if it were done as an icon-based menu. As I've said, I just
don't know how to do that.

Richard

Re: using directives in headers

[Richard Heck]

On 06/25/2016 03:56 PM, Georg Baum wrote:
> I recently stumbled upon
>
> using std::shared_ptr;
>
> or
>
> lyx::support::FileName;
>
> in header files (e.g. TocBackend.h). The shared_ptr was introduced as part 
> of the lyx::shared_ptr removal (which did either point to boost or std), but 
> there are other hits as well. While I understand that in this particular 
> case the "using" statement avoided other changes in the headers, I consider 
> it dangerous to have "using" statements in header files in general:
>
> using foo::bar
>
> effectively forbids to use the name 'bar' in any other namespace in the 
> whole program, since simply adding or removing an #include of the 
> corresponding header subtly changes the name lookup. Therefore I'd like to 
> remove these using statements. OK?

+1

rh

Re: [LyX/master] Style.

[Richard Heck]

On 06/25/2016 02:24 PM, Scott Kostyshak wrote:
> On Sat, Jun 25, 2016 at 07:19:15PM +0100, José Abílio Matos wrote:
>> On Friday, June 24, 2016 10:02:30 PM WEST Richard Heck wrote:
>>> commit 92fae708aebf8d2f3bc393b29c54a4cebeafe730
>>> Author: Richard Heck <rgh...@lyx.org>
>>> Date:   Fri Jun 24 15:03:59 2016 -0400
>>>
>>> Style.
>>> ---
>>>  lib/lyx2lyx/LyX.py |2 +-
>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/lib/lyx2lyx/LyX.py b/lib/lyx2lyx/LyX.py
>>> index bea3d67..f1fcf2e 100644
>>> --- a/lib/lyx2lyx/LyX.py
>>> +++ b/lib/lyx2lyx/LyX.py
>>> @@ -317,7 +317,7 @@ class LyX_base:
>>>  line = trim_eol_binary(line)
>>>  decoded = line.decode('latin1')
>>>  if check_token(decoded, '\\begin_preamble'):
>>> -while 1:
>>> +while True:
>>>  line = self.input.readline()
>>>  if not line:
>>>  # eof found before end of header
>> This was a left-over from python 2.2 support. :-)
>>
>> Thank you for catching that.
> git grep 'while 1' catches more if anyone is interested.

Changed 'em.

Richard

Re: Combo Box for Custom Insets

[Richard Heck]

On 06/25/2016 01:36 PM, Guillaume Munch wrote:
> Le 25/06/2016 17:00, Richard Heck a écrit :
>> On 06/25/2016 02:58 AM, Liviu Andronic wrote:
>>> On Sat, Jun 25, 2016 at 12:23 AM, Richard Heck <rgh...@lyx.org> wrote:
>>>> Attached please find a patch that implements a combo box for custom
>>>> insets, much like the layout box. This is a very simple version. More
>>>> complicated ones might also have an InsetLayout tag that governed
>>>> whether an inset would appear here. It would also be very easy to
>>>> adapt
>>>> this also to give us a combo for charstyles.
>>>>
>>> Looks good. Couple of comments:
>>> - since unlike styles we don't always have a "default" chunk, probably
>>> the first item in the list should be something like: >> Inset>. This will also make the UI more intuitive.
>>> - using the knitr module, while I can insert Chunks without trouble,
>>> for S/R expression and Sweave Opts I get "undefined" inset
>>
>> I've fixed both these issues with the attached.
>>
>
> Hi Richard, thank you for the patch.
>
> I have:
>   warning: 4 space error ignored
>   warning: 9 lines have caused space errors
>
>
> Like Jean-Marc I think a button with an icon would be better suited
> (even though I mentioned a combo box myself at some point without
> thinking enough). This may however require some work as the current
> implementation of LayoutBox you rely on relies on a hack instead of
> defining a model for the contents of the combo box. Re-using LayoutBox
> is nice since it will make it easier to sort by categories of custom
> insets in the future.

It probably wouldn't be that hard for someone who knows what they're
doing with Qt to reimplement this as an icon with a menu. As I said,
though, I wouldn't know where to start.

For now, the branch is here:
http://git.lyx.org/?p=developers/rgheck/lyx.git;a=shortlog;h=refs/heads/features/CustomInsets

> The problem mentioned by Liviu is solved, e.g. some insets became
> "undefined" with the previous patch, e.g. Beamer notes,  but now it
> works.

The problem was that there are spaces in those inset names, so they have
to be quoted when passed as arguments to dispatch.

I removed the delete.

Richard

Re: Combo Box for Custom Insets

[Richard Heck]

On 06/25/2016 12:23 PM, Liviu Andronic wrote:
> On Sat, Jun 25, 2016 at 6:00 PM, Richard Heck <rgh...@lyx.org> wrote:
>> I've fixed both these issues with the attached.
>>
> I have trouble applying this patch. I've tried everything from patch
> -p1 < filename.patch to git apply filename.patch on a clean tree and
> it fails.

Try this one. I've rebased against current master.

Richard

>From fe86ed4936fc36b9e00c826ce46de3bdc8c76025 Mon Sep 17 00:00:00 2001
From: Richard Heck <rgh...@lyx.org>
Date: Fri, 24 Jun 2016 17:47:30 -0400
Subject: [PATCH] Initial work for inset toolbar combo.

---
 lib/ui/stdtoolbars.inc   |   2 +
 src/frontends/qt4/GuiToolbar.cpp |   9 ++
 src/frontends/qt4/GuiView.cpp|  24 -
 src/frontends/qt4/GuiView.h  |   3 +
 src/frontends/qt4/InsetCombo.cpp | 207 +++
 src/frontends/qt4/InsetCombo.h   |  56 +++
 src/frontends/qt4/Makefile.am|   2 +
 src/frontends/qt4/Toolbars.cpp   |   9 +-
 src/frontends/qt4/Toolbars.h |   4 +-
 9 files changed, 312 insertions(+), 4 deletions(-)
 create mode 100644 src/frontends/qt4/InsetCombo.cpp
 create mode 100644 src/frontends/qt4/InsetCombo.h

diff --git a/lib/ui/stdtoolbars.inc b/lib/ui/stdtoolbars.inc
index d375afa..c504e4a 100644
--- a/lib/ui/stdtoolbars.inc
+++ b/lib/ui/stdtoolbars.inc
@@ -95,6 +95,8 @@ ToolbarSet
 		Item "Toggle outline" "dialog-toggle toc"
 		Item "Toggle math toolbar" "toolbar-toggle math"
 		Item "Toggle table toolbar" "toolbar-toggle table"
+		Separator
+		Insets
 	End
 
 	Toolbar "view/update" "View/Update"
diff --git a/src/frontends/qt4/GuiToolbar.cpp b/src/frontends/qt4/GuiToolbar.cpp
index 77471c9..8958813 100644
--- a/src/frontends/qt4/GuiToolbar.cpp
+++ b/src/frontends/qt4/GuiToolbar.cpp
@@ -23,6 +23,7 @@
 #include "GuiView.h"
 #include "IconPalette.h"
 #include "InsertTableWidget.h"
+#include "InsetCombo.h"
 #include "LayoutBox.h"
 #include "qt_helpers.h"
 #include "Toolbars.h"
@@ -277,6 +278,14 @@ void GuiToolbar::add(ToolbarItem const & item)
 		action->setVisible(true);
 		break;
 	}
+	case ToolbarItem::INSETS: {
+		InsetCombo * insets = owner_.getInsetCombo();
+		QObject::connect(this, SIGNAL(iconSizeChanged(QSize)),
+			insets, SLOT(setIconSize(QSize)));
+		QAction * action = addWidget(insets);
+		action->setVisible(true);
+		break;
+	}
 	case ToolbarItem::MINIBUFFER:
 		command_buffer_ = new GuiCommandBuffer(_);
 		addWidget(command_buffer_);
diff --git a/src/frontends/qt4/GuiView.cpp b/src/frontends/qt4/GuiView.cpp
index 429def5..cc93382 100644
--- a/src/frontends/qt4/GuiView.cpp
+++ b/src/frontends/qt4/GuiView.cpp
@@ -27,6 +27,7 @@
 #include "GuiToolbar.h"
 #include "GuiWorkArea.h"
 #include "GuiProgress.h"
+#include "InsetCombo.h"
 #include "LayoutBox.h"
 #include "Menus.h"
 #include "TocModel.h"
@@ -277,7 +278,7 @@ class GuiView::GuiViewPrivate
 public:
 	GuiViewPrivate(GuiView * gv)
 		: gv_(gv), current_work_area_(0), current_main_work_area_(0),
-		layout_(0), autosave_timeout_(5000),
+		layout_(0), insets_(0), autosave_timeout_(5000),
 		in_show_(false)
 	{
 		// hardcode here the platform specific icon size
@@ -328,6 +329,7 @@ public:
 		delete splitter_;
 		delete bg_widget_;
 		delete stack_widget_;
+		delete insets_;
 	}
 
 	QMenu * toolBarPopup(GuiView * parent)
@@ -462,6 +464,7 @@ public:
 	 * to only one dialog.
 	 */
 	LayoutBox * layout_;
+	InsetCombo * insets_;
 
 	///
 	map<string, DialogPtr> dialogs_;
@@ -808,6 +811,7 @@ void GuiView::constructToolbars()
 	d.layout_ = new LayoutBox(*this);
 	d.stack_widget_->addWidget(d.layout_);
 	d.layout_->move(0,0);
+	d.insets_ = new InsetCombo(*this);
 
 	// extracts the toolbars from the backend
 	Toolbars::Infos::iterator cit = guiApp->toolbars().begin();
@@ -1344,7 +1348,8 @@ void GuiView::setBusy(bool busy)
 		return;
 	}
 	QApplication::restoreOverrideCursor();
-	updateLayoutList();	
+	updateLayoutList();
+	updateInsetCombo();
 }
 
 
@@ -1535,6 +1540,12 @@ LayoutBox * GuiView::getLayoutDialog() const
 }
 
 
+InsetCombo * GuiView::getInsetCombo() const
+{
+	return d.insets_;
+}
+
+
 void GuiView::updateLayoutList()
 {
 	if (d.layout_)
@@ -1542,6 +1553,13 @@ void GuiView::updateLayoutList()
 }
 
 
+void GuiView::updateInsetCombo()
+{
+	if (d.insets_)
+		d.insets_->updateContents(false);
+}
+
+
 void GuiView::updateToolbars()
 {
 	ToolbarMap::iterator end = d.toolbars_.end();
@@ -4218,6 +4236,7 @@ void GuiView::resetDialogs()
 	constructToolbars();
 	guiApp->menus().fillMenuBar(menuBar(), this, false);
 	d.layout_->updateContents(true);
+	d.insets_->updateContents(true);
 	// Now update controls with current buffer.
 	guiApp->setCurrentView(this);
 	restoreLayout();
@@ -4355,6 +4374,7 @@ 

Re: Combo Box for Custom Insets

[Richard Heck]

On 06/25/2016 05:29 AM, Jean-Marc Lasgouttes wrote:
> That means that we probably shouldn't use a x but a kind of menu, maybe 
> attached to an icon

Try the latest version.

I'd be happy for someone else to make it into a menu, but I do not know
enough about Qt to do it myself. I mostly stole this from LayoutBox.

Richard


>
> JMarc 
>
> Le 25 juin 2016 08:58:57 GMT+02:00, Liviu Andronic <landr...@lyx.org> a écrit 
> :
>> On Sat, Jun 25, 2016 at 12:23 AM, Richard Heck <rgh...@lyx.org> wrote:
>> Looks good. Couple of comments:
>> - since unlike styles we don't always have a "default" chunk, probably
>> the first item in the list should be something like: > Inset>. This will also make the UI more intuitive.

Re: Combo Box for Custom Insets

[Richard Heck]

On 06/25/2016 02:58 AM, Liviu Andronic wrote:
> On Sat, Jun 25, 2016 at 12:23 AM, Richard Heck <rgh...@lyx.org> wrote:
>> Attached please find a patch that implements a combo box for custom
>> insets, much like the layout box. This is a very simple version. More
>> complicated ones might also have an InsetLayout tag that governed
>> whether an inset would appear here. It would also be very easy to adapt
>> this also to give us a combo for charstyles.
>>
> Looks good. Couple of comments:
> - since unlike styles we don't always have a "default" chunk, probably
> the first item in the list should be something like:  Inset>. This will also make the UI more intuitive.
> - using the knitr module, while I can insert Chunks without trouble,
> for S/R expression and Sweave Opts I get "undefined" inset

I've fixed both these issues with the attached.

Richard

>From 001716da6eb23aff6f38fdbb8cc07d2c5d900498 Mon Sep 17 00:00:00 2001
From: Richard Heck <rgh...@lyx.org>
Date: Fri, 24 Jun 2016 17:47:30 -0400
Subject: [PATCH] Initial work for inset toolbar combo.

---
 lib/ui/stdtoolbars.inc   |   2 +
 src/frontends/qt4/GuiToolbar.cpp |   9 ++
 src/frontends/qt4/GuiView.cpp|  24 -
 src/frontends/qt4/GuiView.h  |   3 +
 src/frontends/qt4/InsetCombo.cpp | 207 +++
 src/frontends/qt4/InsetCombo.h   |  56 +++
 src/frontends/qt4/Makefile.am|   2 +
 src/frontends/qt4/Toolbars.cpp   |   9 +-
 src/frontends/qt4/Toolbars.h |   4 +-
 9 files changed, 312 insertions(+), 4 deletions(-)
 create mode 100644 src/frontends/qt4/InsetCombo.cpp
 create mode 100644 src/frontends/qt4/InsetCombo.h

diff --git a/lib/ui/stdtoolbars.inc b/lib/ui/stdtoolbars.inc
index d375afa..c504e4a 100644
--- a/lib/ui/stdtoolbars.inc
+++ b/lib/ui/stdtoolbars.inc
@@ -95,6 +95,8 @@ ToolbarSet
 		Item "Toggle outline" "dialog-toggle toc"
 		Item "Toggle math toolbar" "toolbar-toggle math"
 		Item "Toggle table toolbar" "toolbar-toggle table"
+		Separator
+		Insets
 	End
 
 	Toolbar "view/update" "View/Update"
diff --git a/src/frontends/qt4/GuiToolbar.cpp b/src/frontends/qt4/GuiToolbar.cpp
index 77471c9..8958813 100644
--- a/src/frontends/qt4/GuiToolbar.cpp
+++ b/src/frontends/qt4/GuiToolbar.cpp
@@ -23,6 +23,7 @@
 #include "GuiView.h"
 #include "IconPalette.h"
 #include "InsertTableWidget.h"
+#include "InsetCombo.h"
 #include "LayoutBox.h"
 #include "qt_helpers.h"
 #include "Toolbars.h"
@@ -277,6 +278,14 @@ void GuiToolbar::add(ToolbarItem const & item)
 		action->setVisible(true);
 		break;
 	}
+	case ToolbarItem::INSETS: {
+		InsetCombo * insets = owner_.getInsetCombo();
+		QObject::connect(this, SIGNAL(iconSizeChanged(QSize)),
+			insets, SLOT(setIconSize(QSize)));
+		QAction * action = addWidget(insets);
+		action->setVisible(true);
+		break;
+	}
 	case ToolbarItem::MINIBUFFER:
 		command_buffer_ = new GuiCommandBuffer(_);
 		addWidget(command_buffer_);
diff --git a/src/frontends/qt4/GuiView.cpp b/src/frontends/qt4/GuiView.cpp
index 87ee553..34da998 100644
--- a/src/frontends/qt4/GuiView.cpp
+++ b/src/frontends/qt4/GuiView.cpp
@@ -27,6 +27,7 @@
 #include "GuiToolbar.h"
 #include "GuiWorkArea.h"
 #include "GuiProgress.h"
+#include "InsetCombo.h"
 #include "LayoutBox.h"
 #include "Menus.h"
 #include "TocModel.h"
@@ -277,7 +278,7 @@ class GuiView::GuiViewPrivate
 public:
 	GuiViewPrivate(GuiView * gv)
 		: gv_(gv), current_work_area_(0), current_main_work_area_(0),
-		layout_(0), autosave_timeout_(5000),
+		layout_(0), insets_(0), autosave_timeout_(5000),
 		in_show_(false)
 	{
 		// hardcode here the platform specific icon size
@@ -328,6 +329,7 @@ public:
 		delete splitter_;
 		delete bg_widget_;
 		delete stack_widget_;
+		delete insets_;
 	}
 
 	QMenu * toolBarPopup(GuiView * parent)
@@ -462,6 +464,7 @@ public:
 	 * to only one dialog.
 	 */
 	LayoutBox * layout_;
+	InsetCombo * insets_;
 
 	///
 	map<string, DialogPtr> dialogs_;
@@ -808,6 +811,7 @@ void GuiView::constructToolbars()
 	d.layout_ = new LayoutBox(*this);
 	d.stack_widget_->addWidget(d.layout_);
 	d.layout_->move(0,0);
+	d.insets_ = new InsetCombo(*this);
 
 	// extracts the toolbars from the backend
 	Toolbars::Infos::iterator cit = guiApp->toolbars().begin();
@@ -1344,7 +1348,8 @@ void GuiView::setBusy(bool busy)
 		return;
 	}
 	QApplication::restoreOverrideCursor();
-	updateLayoutList();	
+	updateLayoutList();
+	updateInsetCombo();
 }
 
 
@@ -1535,6 +1540,12 @@ LayoutBox * GuiView::getLayoutDialog() const
 }
 
 
+InsetCombo * GuiView::getInsetCombo() const
+{
+	return d.insets_;
+}
+
+
 void GuiView::updateLayoutList()
 {
 	if (d.layout_)
@@ -1542,6 +1553,13 @@ void GuiView::updateLayo

Re: new LyX 2.2.0 installer for Windows Vista is available

[Richard Heck]

On 06/25/2016 05:13 AM, Uwe Stöhr wrote:
> Dear LyXers,
>
> there is a new Windows installer available that provides support for
> Windows Vista:
> http://ftp.lyx.de/LyX%202.2.0/LyX-220-Installer-Vista-3.exe
>
> Dima kindly prepared the binary from the 2.2.0 tarball, I checked it
> against viruses and malware using commercial antivirus software, I
> created the installer with it and Dima tested that everything works
> fine on Vista.
>
> Richard, could you please put it on ftp.lyx.org? Could you please also
> write a news message that we now have a Vista installer but that this
> installer should not be used for other Windows versions than Vista.
>
> ---
>
> There is a discussion about this topic in the bug tracker that I
> cannot understand. Scott and Richard are concerned that Dima'S build
> contains malware. This is not fair. Dima invested some spare time to
> fiddle around with Qt to prepare a Vista build and to test it. To
> presume that a new contributor is not trustworthy is not the way we
> should welcome new people!

This is a complete misunderstanding of what Scott and I were saying. We
think that our officially releasing a LyX binary on the LyX website,
especially one signed with the LyX key, means that we are making certain
sorts of guarantees to people. We cannot make those guarantees if the
binary has been built by someone we do not at all know.

People don't even get commit rights until they've submitted a number of
patches and proved themselves capable.

> I checked Dima's build wit the anti-virus software at work (the
> installer only contains the lyx.exe and tex2lyx.exe from Dima, all
> other LyX files are identic with the other installers I released for
> 2.2.0.
> However, in general, if we don't trust new people investing their
> spare time, we will be lost. To dramatize: Some of you have never seen
> me, nobody knows my build system and could cross-check if I don't add
> spyware to the Win installers. So you have to trust me too.

You have been around here rather a long time.

> Thus please keep use welcome new people and encouraging to join the
> LyX developer team. LyX need manpower and I am happy about every new
> developer. We also need people developing on Windows.

Obviously. No one is saying we should not encourage Dima to submit
patches and ultimately gain commit rights. This is an entirely different
issue.

Richard

Combo Box for Custom Insets

[Richard Heck]

Attached please find a patch that implements a combo box for custom
insets, much like the layout box. This is a very simple version. More
complicated ones might also have an InsetLayout tag that governed
whether an inset would appear here. It would also be very easy to adapt
this also to give us a combo for charstyles.

Comments welcome.

Richard

>From 1151bc1c0392a010cafa040f7216553e6d54ed1a Mon Sep 17 00:00:00 2001
From: Richard Heck <rgh...@lyx.org>
Date: Fri, 24 Jun 2016 17:47:30 -0400
Subject: [PATCH] Initial work for inset toolbar combo.

---
 lib/ui/stdtoolbars.inc   |   2 +
 src/frontends/qt4/GuiToolbar.cpp |   9 ++
 src/frontends/qt4/GuiView.cpp|  24 -
 src/frontends/qt4/GuiView.h  |   3 +
 src/frontends/qt4/InsetCombo.cpp | 194 +++
 src/frontends/qt4/InsetCombo.h   |  56 +++
 src/frontends/qt4/Makefile.am|   2 +
 src/frontends/qt4/Toolbars.cpp   |   9 +-
 src/frontends/qt4/Toolbars.h |   4 +-
 9 files changed, 299 insertions(+), 4 deletions(-)
 create mode 100644 src/frontends/qt4/InsetCombo.cpp
 create mode 100644 src/frontends/qt4/InsetCombo.h

diff --git a/lib/ui/stdtoolbars.inc b/lib/ui/stdtoolbars.inc
index d375afa..c504e4a 100644
--- a/lib/ui/stdtoolbars.inc
+++ b/lib/ui/stdtoolbars.inc
@@ -95,6 +95,8 @@ ToolbarSet
 		Item "Toggle outline" "dialog-toggle toc"
 		Item "Toggle math toolbar" "toolbar-toggle math"
 		Item "Toggle table toolbar" "toolbar-toggle table"
+		Separator
+		Insets
 	End
 
 	Toolbar "view/update" "View/Update"
diff --git a/src/frontends/qt4/GuiToolbar.cpp b/src/frontends/qt4/GuiToolbar.cpp
index 77471c9..8958813 100644
--- a/src/frontends/qt4/GuiToolbar.cpp
+++ b/src/frontends/qt4/GuiToolbar.cpp
@@ -23,6 +23,7 @@
 #include "GuiView.h"
 #include "IconPalette.h"
 #include "InsertTableWidget.h"
+#include "InsetCombo.h"
 #include "LayoutBox.h"
 #include "qt_helpers.h"
 #include "Toolbars.h"
@@ -277,6 +278,14 @@ void GuiToolbar::add(ToolbarItem const & item)
 		action->setVisible(true);
 		break;
 	}
+	case ToolbarItem::INSETS: {
+		InsetCombo * insets = owner_.getInsetCombo();
+		QObject::connect(this, SIGNAL(iconSizeChanged(QSize)),
+			insets, SLOT(setIconSize(QSize)));
+		QAction * action = addWidget(insets);
+		action->setVisible(true);
+		break;
+	}
 	case ToolbarItem::MINIBUFFER:
 		command_buffer_ = new GuiCommandBuffer(_);
 		addWidget(command_buffer_);
diff --git a/src/frontends/qt4/GuiView.cpp b/src/frontends/qt4/GuiView.cpp
index 87ee553..34da998 100644
--- a/src/frontends/qt4/GuiView.cpp
+++ b/src/frontends/qt4/GuiView.cpp
@@ -27,6 +27,7 @@
 #include "GuiToolbar.h"
 #include "GuiWorkArea.h"
 #include "GuiProgress.h"
+#include "InsetCombo.h"
 #include "LayoutBox.h"
 #include "Menus.h"
 #include "TocModel.h"
@@ -277,7 +278,7 @@ class GuiView::GuiViewPrivate
 public:
 	GuiViewPrivate(GuiView * gv)
 		: gv_(gv), current_work_area_(0), current_main_work_area_(0),
-		layout_(0), autosave_timeout_(5000),
+		layout_(0), insets_(0), autosave_timeout_(5000),
 		in_show_(false)
 	{
 		// hardcode here the platform specific icon size
@@ -328,6 +329,7 @@ public:
 		delete splitter_;
 		delete bg_widget_;
 		delete stack_widget_;
+		delete insets_;
 	}
 
 	QMenu * toolBarPopup(GuiView * parent)
@@ -462,6 +464,7 @@ public:
 	 * to only one dialog.
 	 */
 	LayoutBox * layout_;
+	InsetCombo * insets_;
 
 	///
 	map<string, DialogPtr> dialogs_;
@@ -808,6 +811,7 @@ void GuiView::constructToolbars()
 	d.layout_ = new LayoutBox(*this);
 	d.stack_widget_->addWidget(d.layout_);
 	d.layout_->move(0,0);
+	d.insets_ = new InsetCombo(*this);
 
 	// extracts the toolbars from the backend
 	Toolbars::Infos::iterator cit = guiApp->toolbars().begin();
@@ -1344,7 +1348,8 @@ void GuiView::setBusy(bool busy)
 		return;
 	}
 	QApplication::restoreOverrideCursor();
-	updateLayoutList();	
+	updateLayoutList();
+	updateInsetCombo();
 }
 
 
@@ -1535,6 +1540,12 @@ LayoutBox * GuiView::getLayoutDialog() const
 }
 
 
+InsetCombo * GuiView::getInsetCombo() const
+{
+	return d.insets_;
+}
+
+
 void GuiView::updateLayoutList()
 {
 	if (d.layout_)
@@ -1542,6 +1553,13 @@ void GuiView::updateLayoutList()
 }
 
 
+void GuiView::updateInsetCombo()
+{
+	if (d.insets_)
+		d.insets_->updateContents(false);
+}
+
+
 void GuiView::updateToolbars()
 {
 	ToolbarMap::iterator end = d.toolbars_.end();
@@ -4213,6 +4231,7 @@ void GuiView::resetDialogs()
 	constructToolbars();
 	guiApp->menus().fillMenuBar(menuBar(), this, false);
 	d.layout_->updateContents(true);
+	d.insets_->updateContents(true);
 	// Now update controls with current buffer.
 	guiApp->setCurrentView(this);
 	restoreLayout();
@@ -4350,6 +4369,7 @@ void GuiView::updateDialogs()
 	}
 	updateToolbars();
 	updateLayoutLi

Re: InPreamble Tag: Bug #10215

[Richard Heck]

I'm now wondering whether what we really want to do here is just output
ALL the things that are included via addPreambleSnippet after the
"Textclass specific LaTeX commands": This is all the stuff loaded via
Preamble and AddToPreamble in the main document layout file and by
specific styles and inset layouts.

There are a handful of things that get included that way at the moment:
The InPreamble material; required packages for certain sorts of
characters (see BufferEncodings.cpp); preamble material required by
external insets; some macros provided by InsetRef::validate, to deal
with undeclared refstyle prefixes and the like; similar macros for
\regex and \endregex, added by InsetMathHull::validate.

That would basically look like this:

--- src/BufferParams.cpp
+++ src/BufferParams.cpp
@@ -1980,6 +1980,12 @@ bool BufferParams::writeLaTeX(otexstream & os,
LaTeXFeatures & features,
 "Textclass specific LaTeX commands.\n"
 + tmppreamble + '\n';
 
+tmppreamble = features.getPreambleSnippets();
+if (!tmppreamble.empty())
+atlyxpreamble += "\n%% "
+"Additional LaTeX commands.\n"
++ tmppreamble + '\n';
+   
 // suppress date if selected
 // use \@ifundefined because we cannot be sure that every document
class
 // has a \date command
--- src/LaTeXFeatures.cpp
+++ src/LaTeXFeatures.cpp
@@ -1167,11 +1167,6 @@ docstring const LaTeXFeatures::getMacros() const
 {
 odocstringstream macros;
 
-if (!preamble_snippets_.empty()) {
-macros << '\n';
-macros << from_utf8(getPreambleSnippets());
-}
-
 if (mustProvide("papersize")) {
 if (runparams_.flavor == OutputParams::LATEX)
 macros << papersizedvi_def << '\n';



Richard



On 06/19/2016 12:15 PM, Guenter Milde wrote:
> On 2016-06-18, Guillaume Munch wrote:
>> Le 18/06/2016 17:42, Richard Heck a écrit :
>>> On 06/17/2016 05:16 AM, Jean-Marc Lasgouttes wrote:
>>>> Le 14/06/2016 à 18:53, Richard Heck a écrit :
>>>>> This seems to me to count as a bug. To fix it, though, we'd obviously
>>>>> have to output the code from the style AFTER the Preamble, which would
>>>>> change the TeX export of lots of files. An alternative would be to
>>>>> introduce a new tag that would basically mean: Output this before or
>>>>> after the Preamble code. But I can't imagine why you'd want to do it
>>>>> before the Preamble code.
>>>> To me also, it is a bug.  I would say that all the preamble snippets
>>>> should be output before the InPreamble layouts are output.
>>>> The problem is that there are always a handful of creative people who
>>>> take advantage of this kind of things. So it might be that we have to
>>>> create a new tag to command this. But the possibilities are large in
>>>> what before/after means.
>>> In this case, it is a bit hard to see how one could take advantage of
>>> it. But it is perhaps safest to make the new tag. I'd obviously have to
>>> explain in some detail in the Customization manual what BEFORE and AFTER
>>> mean.
>>> This does seem unfortunate, though, since I find it hard to see how one
>>> could take advantage of this kind of bug. In our own styles, InPreamble
>>> is only ever used to put e.g. titles into the preamble.
>> As a user who creatively exploits LyX's quirks (though not this one), I
>> agree. I do not think it is worth making the layout tags more
>> complicated because of this. I think the creative user would be able to
>> find the cause of their new problem and fix it, e.g. with 
>> \AtBeginDocument. I would say go ahead and fix the bug.
> I also vote for a simple fix without a new tag.
>
> Instead of \AtBeginDocument (which does not work for code that must be in
> the preamble), the hypothetical creative power user can use
>
>  \usepackage{etools}
>  \AtEndPreamble{ ... }
>
> Günter
>
>
>

Re: LyX 2.1.5 Tarballs

[Richard Heck]

On 06/24/2016 05:04 AM, John McCabe-Dansted wrote:
> https://www.lyx.org/Download lists the LyX 2.2 Windows Installer as
> XP/Vista/...
>
> Perhaps this needs to be updated too?

Thanks, I've made some updates to that. Unfortunately, I cannot make
updates here:
http://wiki.lyx.org/Windows/Windows
Neither of the usual passwords seems to work.

Richard


>
> On Tue, Jun 21, 2016 at 11:04 PM, Richard Heck <rgh...@lyx.org
> <mailto:rgh...@lyx.org>> wrote:
>
> On 06/19/2016 08:16 PM, Uwe Stöhr wrote:
>     > Am 13.06.2016 um 17:33 schrieb Richard Heck:
> >
> >>
> >> The tarballs for the release of LyX 2.1.5 can be found here:
> >> ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.1/2.1.5/
> >> Please prepare binaries.
> >
> > Here is the Windows build:
> > http://ftp.lyx.de/LyX%202.1.5/
> >
> > Please add to the announcement that this will be the last LyX
> version
> > with support for Windows Vista.
>
> Done.
>
> rh
>
>
>
>
> -- 
> John C. McCabe-Dansted

Re: Joining LyX development team

[Richard Heck]

On 06/24/2016 02:43 AM, Dima Ruinskiy wrote:
> Hi. My name is Dima Ruinskiy, and I would like to join the LyX development 
> team.
>
> I hereby permit to use my contributions to LyX under the license of the GPL 
> version 2 or later.

Thanks for this email. We'll add you to the credits once there are
patches that need crediting.

Is there something specific you'd like to work on?

Richard

Re: Save transient properties

[Richard Heck]

On 06/23/2016 11:02 AM, Guillaume Munch wrote:
> Dear list,
>
> I am thinking of adding the "Save transient properties" checkbox
> (disabling the save of \origin, \tracking_changes, \output_changes) to
> the "document class" panel, for lack of a better place. This panel
> already contains other settings unrelated to the document class.
>
> Can you think of a better place? Of a better label? Thank you for any
> advice.

No, that looks like the best choice.

rh

Re: improved section 6.11 of User Guide (2.0.x), please CC me because I'm not subscribed

[Richard Heck]

On 06/23/2016 12:14 AM, Colin Keenan wrote:
> I have submitted a patch against the correct branch, 2.2.x. I don't
> know how to use change tracking. Please provide steps for doing that.
> I am currently following the guide at http://www.lyx.org/HowToUseGIT.

Document> Change Tracking> Track Changes.

Richard

Re: improved section 6.11 of User Guide (2.0.x), please CC me because I'm not subscribed

[Richard Heck]

On 06/21/2016 03:20 PM, Colin Keenan wrote:
> 0001-improved-section-6.11-of-User-Guide.patch
> is attached,
>  
> providing
> improvements to section 6.11 of the User Guide for branch 2.0.x.
> Please CC me because I am not subscribed to the LyX developer mailing
> list.
> I am just following these instructions
> http://www.lyx.org/HowToUseGIT.

Hi, Colin,

You seem to have generated a patch against a very old version of the
User Guide (from LyX 2.0.x). Can you just attach your modified version
and use change tracking to indicate where you have made changes? We use
change tracking for all modifications to the docs anyway, so the
translators can see what is new.

Richard

Re: lyx-cvs messages: show file names changed

[Richard Heck]

On 06/21/2016 07:48 PM, Scott Kostyshak wrote:
> On Sat, Apr 16, 2016 at 01:43:18PM -0400, Scott Kostyshak wrote:
>> On Sat, Apr 16, 2016 at 08:35:54AM -0400, Richard Heck wrote:
>>> On 04/15/2016 05:45 PM, Scott Kostyshak wrote:
>>>> On Tue, Mar 29, 2016 at 06:09:56PM -0400, Scott Kostyshak wrote:
>>>>> On Tue, Mar 29, 2016 at 10:49:55AM +0200, Jean-Marc Lasgouttes wrote:
>>>>>> Le 28/03/2016 00:04, Scott Kostyshak a écrit :
>>>>>>> It seems we currently use "git show ${hash}" in our script. Instead of
>>>>>>> doing two commands like I naively suggested above, what about the
>>>>>>> following?
>>>>>> What about "git show --stat"?
>>>>> Yes that is better than what I proposed. We should do
>>>>>
>>>>>git show --patch-with-stat
>>>>>
>>>>> so that both the patch and the stat are shown.
>>>> Richard are you able to change this? I think it would mean changing the
>>>> following in git_show:
>>>>
>>>>   p = subprocess.Popen(['git', 'show', hash], stdout=subprocess.PIPE)
>>>>
>>>> to
>>>>
>>>>   p = subprocess.Popen(['git', 'show', '--patch-with-stat', hash], 
>>>> stdout=subprocess.PIPE)
>>>>
>>>> git show is also used in get_commit_info():, but if I understand
>>>> correctly we don't need to change it there (I'm not confident about this
>>>> though).
>>> I will be able to do so, but I'll need to read this thread through and
>>> understand exactly what we are trying to do.
>> OK it is not urgent.
> Just pinging Richard in case he happens to find time to take a look.
> It's still not urgent of course.

Should work now.

rh

Re: Fwd: Re: [LyX/2.2.x] Document change to behavior of charstyles.

[Richard Heck]

On 06/21/2016 05:12 PM, Jean-Pierre Chrétien wrote:
> Le 21/06/2016 20:55, Richard Heck a écrit :
>> commit 76bf4bbc9ea32c3ac2e43efa9da835666bc280ce
>> Author: Richard Heck <rgh...@lyx.org>
>> Date:   Tue Jun 21 15:55:15 2016 -0400
>
>>
>> -You can download LyX 2.2.0 from https://www.lyx.org/Download/.
>> +You can download LyX 2.1.4 from http://www.lyx.org/Download/.
> ^
> 2.2.1 I guess

Yes, thanks.

rh

[ANNOUNCE] LyX 2.1.5 Released

[Richard Heck]

We are pleased to announce the release of LyX 2.1.5. This is the fifth
and final maintenance release in the 2.1.x series.

LyX 2.1.5 is the result of on-going efforts to make our stable version
even more reliable and stable. We have fixed a number of bugs and made a
number of improvements. Many of these were minor, but there were a few
crashes we fixed, too.These are detailed in the announcement
.

Please note that this is the final release in the 2.1.x series. It is
intended for users who for some reason do not wish to upgrade to 2.2.x
at this time. We strongly encourage all such users to upgrade to this
version. Most users should upgrade to 2.2.0.

Note also that LyX 2.1.5 is the last release that will support Windows
Vista. This is due to the fact that the Windows releases in the 2.2.x
series require Qt 5.6, which is not available for Vista.

One of the main features of 2.1.5 is its ability to read and write files
in the 2.2.x format. Since the conversion process back and forth usually
will not leave one with an identical file, however, we do not recommend
attempting to collaborate with users of 2.2.x. We strongly encourage all
LyX users to upgrade to this version.

You can download the sources in tar.gz format
 (also tar.xz
). There are
also some binaries  available.

Re: LyX 2.1.5 Tarballs

[Richard Heck]

On 06/19/2016 08:16 PM, Uwe Stöhr wrote:
> Am 13.06.2016 um 17:33 schrieb Richard Heck:
>
>>
>> The tarballs for the release of LyX 2.1.5 can be found here:
>> ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.1/2.1.5/
>> Please prepare binaries.
>
> Here is the Windows build:
> http://ftp.lyx.de/LyX%202.1.5/
>
> Please add to the announcement that this will be the last LyX version
> with support for Windows Vista.

Done.

rh

Re: Fixed in Master + Milestone 2.3.0

[Richard Heck]

On 06/21/2016 09:23 AM, Guenter Milde wrote:
> On 2016-06-20, Richard Heck wrote:
>> Note that this is different from having the *resolution* be fixed: These 
>> would still have no resolution and so would still turn up the right way in 
>> searches. 
> Having a keyword "fixed" and a resolution with the same name is confusing.

Yes, it is, but I'm not sure it is easy to change it.

We can leave the rest as is.

Richard

Re: Layout Changes Inside CharStyles?

[Richard Heck]

On 06/21/2016 10:45 AM, José Abílio Matos wrote:
> On Tuesday, June 21, 2016 4:07:25 PM WEST Helge Hafting wrote:
>> I might use a charstyle to set large amounts (several paragraphs or an 
>> entire chapter) in a different color. I may still want headings & 
>> enumerations inside of that!
>>
>> It can perhaps be argued that I ought to use a paragraph style for this, and 
>> nest the other stuff inside. Currently, that is more cumbersome – especially 
>> the creation of a custom paragraph style.
> Then the solution here is to ease the creation of custom paragraph styles and 
> not to mix two different concepts.

You can also do a custom inset, which is the same as a character style,
except that it appears in a different place on the menu.

Note also that this proposal does not *prohibit* anything. It just makes
"ForcePlain 1" the default for charstyles.

Richard

Re: provides "package" 1

[Richard Heck]

On 06/21/2016 06:58 AM, PhilipPirrip wrote:
> I was wondering if there's a special reason why
> provides fontenc 1
> provides inputenc 1
> provides amsmath 1
>
> prevent the corresponding packages from loading, but
>
> provides fontspec 1
> provides listings 1
> provides polyglossia 1
>
> -for example- don't?
>
> Should I report a bug?

Yes, that's a bug. This should work for all LyX-loaded packages.

I think

diff --git a/src/BufferParams.cpp b/src/BufferParams.cpp
index 373eee5..592833a 100644
--- a/src/BufferParams.cpp
+++ b/src/BufferParams.cpp
@@ -1589,7 +1589,8 @@ bool BufferParams::writeLaTeX(otexstream & os,
LaTeXFeatures & features,
os << from_ascii(ams);
 
if (useNonTeXFonts) {
-   os << "\\usepackage{fontspec}\n";
+   if (!features.isProvided("fontspec"))
+   os << "\\usepackage{fontspec}\n";
if (features.mustProvide("unicode-math")
&& features.isAvailable("unicode-math"))
os << "\\usepackage{unicode-math}\n";
@@ -2115,7 +2115,7 @@ bool BufferParams::writeLaTeX(otexstream & os,
LaTeXFeatures & features,
}
if (features.isRequired("bicaption"))
lyxpreamble += "\\usepackage{bicaption}\n";
-   if (!listings_params.empty() || features.isRequired("listings"))
+   if (!listings_params.empty() || features.mustProvide("listings"))
lyxpreamble += "\\usepackage{listings}\n";
if (!listings_params.empty()) {
lyxpreamble += "\\lstset{";

fixes the case of listings and fontspec. But I'd like to hear from
others, as I'm not expert on this.

I'm not sure how to handle polyglossia.

Richard

Re: Layout Changes Inside CharStyles?

[Richard Heck]

On 06/20/2016 11:03 PM, Jean-Marc Lasgouttes wrote:

Le 20/06/2016 17:34, Richard Heck a écrit :


At the moment, it is possible to effect a layout change inside almost
all of our character styles. So far as I can see, this is almost always
a bug. One does not want, e.g., to be able to switch to an enumeration
inside the Code character style. So I propose the following simple 
patch:


I would agree with this change, which should be properly documented.


PS Do you think this is all right for stable, even though it is a change of
behavior? We won't do anything with layout2layout

Richard

Re: Layout Changes Inside CharStyles?

[Richard Heck]

On 06/20/2016 11:03 PM, Jean-Marc Lasgouttes wrote:

Le 20/06/2016 17:34, Richard Heck a écrit :


At the moment, it is possible to effect a layout change inside almost
all of our character styles. So far as I can see, this is almost always
a bug. One does not want, e.g., to be able to switch to an enumeration
inside the Code character style. So I propose the following simple 
patch:


I would agree with this change, which should be properly documented.

I also think that in this case the layout change should be done in the 
outer paragraph. After all, this is what happens in a math inset.


Yes, that could be done---and racoon suggested the same thing---but then 
I worry it will be misleading. You could change a layout and have it 
only affect a paragraph any number of embeddings up. It's also hard to 
see how this works with the combo box. Surley (?) we want that still to 
display "Plain Layout" in an inset with ForcePlain on. But then you 
could use it to change to some other layout, and yet it still shows 
"Plain Layout". Or do you propose it displays the layout of the 
containing paragraph that has a layout? This again seems potentially 
confusing.


Richafd

Re: Fixed in Master + Milestone 2.3.0

[Richard Heck]

On 06/20/2016 11:04 PM, Jean-Marc Lasgouttes wrote:

Le 20/06/2016 18:37, Richard Heck a écrit :


I propose that bugs meeting that description (such as #4398) simply be
marked as having status "Fixed". The "Fixed in Master" status seems
misleading: They are not going to get fixed in stable. If we mark them
Fixed, it can mean: We are done with them.


I am not sure what we gain by doing this. Doesn't the milestone tell 
us whether we want to backport the fix?


I think it's just easier to see what's still pending for stable and 
what's not.


Richard

Fixed in Master + Milestone 2.3.0

[Richard Heck]

I propose that bugs meeting that description (such as #4398) simply be
marked as having status "Fixed". The "Fixed in Master" status seems
misleading: They are not going to get fixed in stable. If we mark them
Fixed, it can mean: We are done with them.

Note that this is different from having the *resolution* be fixed: These
would still have no resolution and so would still turn up the right way
in searches. The only difference would be that "fixedinmaster" would
mean: Fixed in master and (possibly, probably) to be fixed in stable.

Richard

Re: Layout Changes Inside CharStyles?

[Richard Heck]

On 06/20/2016 11:34 AM, Richard Heck wrote:
> At the moment, it is possible to effect a layout change inside almost
> all of our character styles. So far as I can see, this is almost always
> a bug. One does not want, e.g., to be able to switch to an enumeration
> inside the Code character style. So I propose the following simple patch:
>
> diff --git a/src/insets/InsetLayout.cpp b/src/insets/InsetLayout.cpp
> index a1677de..b41b630 100644
> --- a/src/insets/InsetLayout.cpp
> +++ b/src/insets/InsetLayout.cpp
> @@ -226,8 +226,10 @@ bool InsetLayout::read(Lexer & lex, TextClass const
> & tclass)
> lyxtype_ = translateLyXType(lt);
> if (lyxtype_  == NOLYXTYPE)
> LYXERR0("Unknown LyXType `" << lt << "'.");
> -   if (lyxtype_ == CHARSTYLE)
> +   if (lyxtype_ == CHARSTYLE) {
> multipar_ = false;
> +   forceplain_ = true;
> +   }
> break;
> }
> case IL_LATEXTYPE:  {
>
> which makes charstyles, by default, force the plain layout. If one
> really did want to be able to switch layouts, then one could later put
> "ForcePlain 0". So this does not prevent someone from doing that.
>
> Maybe this should be master-only, just in case someone used this 'feature'.

See http://www.lyx.org/trac/ticket/10237 for a case where this actually
causes a problem. It's because we had a Description inside an Alert
charstyle.

Richard

Layout Changes Inside CharStyles?

[Richard Heck]

At the moment, it is possible to effect a layout change inside almost
all of our character styles. So far as I can see, this is almost always
a bug. One does not want, e.g., to be able to switch to an enumeration
inside the Code character style. So I propose the following simple patch:

diff --git a/src/insets/InsetLayout.cpp b/src/insets/InsetLayout.cpp
index a1677de..b41b630 100644
--- a/src/insets/InsetLayout.cpp
+++ b/src/insets/InsetLayout.cpp
@@ -226,8 +226,10 @@ bool InsetLayout::read(Lexer & lex, TextClass const
& tclass)
lyxtype_ = translateLyXType(lt);
if (lyxtype_  == NOLYXTYPE)
LYXERR0("Unknown LyXType `" << lt << "'.");
-   if (lyxtype_ == CHARSTYLE)
+   if (lyxtype_ == CHARSTYLE) {
multipar_ = false;
+   forceplain_ = true;
+   }
break;
}
case IL_LATEXTYPE:  {

which makes charstyles, by default, force the plain layout. If one
really did want to be able to switch layouts, then one could later put
"ForcePlain 0". So this does not prevent someone from doing that.

Maybe this should be master-only, just in case someone used this 'feature'.

Richard

Branch Labeling: Bug #10213

[Richard Heck]

Some time back, there was a discussion on the list about the labels of
collapsed branches. As it is now, we display a bit of text from the
branch. The general view was that this is not very useful, and it makes
documents with lots of branches look terrible. The proposal was to label
collapsed branches the same way we label uncollapsed ones: with the
branch name, and a marker showing whether it is "on". Info on what's in
the inset will still be available from the tooltip.

I've attached a patch to the bug report
http://www.lyx.org/trac/ticket/10213
and intend to commit unless there are objections.

Richard

Re: [LyX/master] Skip paragraph parameters for dash conversion

[Richard Heck]

On 06/19/2016 11:06 AM, Georg Baum wrote:
> commit 5ab19af7820fba58876ac86efd8cc4aa1e75b44f
> Author: Georg Baum 
> Date:   Sun Jun 19 17:05:13 2016 +0200
>
> Skip paragraph parameters for dash conversion
> 
> Some of them are directly passed to LaTeX, but for all of them a token
> \twohyphens or \threehyphens is not valid. This fixes bug #10243.

Looks necessary for 2.2.x as well.

Richard

Re: Really Weird Build Problem

[Richard Heck]

On 06/18/2016 07:39 PM, Pavel Sanda wrote:
> Richard Heck wrote:
>> How can that be? About>LyX shows the program as having been built from
>> the same git commit in both cases.
> Sound like running two different binaries (the same commit but different
> changes on top of that). Can you reproduce if you kill all running 
> instances and rerun it again?

I rebooted and it went away. So something like that.

Richard

Really Weird Build Problem

[Richard Heck]

I am working on adding some new features to the cross-reference dialog,
but I have run into a really strange problem when testing it. If I run
the built program as:
/cvs/lyx/build/src/lyx
then all is well: I see my new checkboxes in the dialog. But if I run it as:
/cvs/lyx/build/src/lyx -userdir /tmp/lyx
then I do NOT see the new checkboxes!!

How can that be? About>LyX shows the program as having been built from
the same git commit in both cases.

Richard

Re: InPreamble Tag: Bug #10215

[Richard Heck]

On 06/17/2016 05:16 AM, Jean-Marc Lasgouttes wrote:
> Le 14/06/2016 à 18:53, Richard Heck a écrit :
>> This seems to me to count as a bug. To fix it, though, we'd obviously
>> have to output the code from the style AFTER the Preamble, which would
>> change the TeX export of lots of files. An alternative would be to
>> introduce a new tag that would basically mean: Output this before or
>> after the Preamble code. But I can't imagine why you'd want to do it
>> before the Preamble code.
>
> To me also, it is a bug.  I would say that all the preamble snippets
> should be output before the InPreamble layouts are output.
>
> The problem is that there are always a handful of creative people who
> take advantage of this kind of things. So it might be that we have to
> create a new tag to command this. But the possibilities are large in
> what before/after means.

In this case, it is a bit hard to see how one could take advantage of
it. But it is perhaps safest to make the new tag. I'd obviously have to
explain in some detail in the Customization manual what BEFORE and AFTER
mean.

This does seem unfortunate, though, since I find it hard to see how one
could take advantage of this kind of bug. In our own styles, InPreamble
is only ever used to put e.g. titles into the preamble.

Richard

Re: InPreamble Tag: Bug #10215

[Richard Heck]

On 06/17/2016 06:34 AM, Jean-Pierre Chrétien wrote:
> Le 14/06/2016 17:53, Richard Heck a écrit :
>>
>> Suppose you have a style like this:
>>
>> Style Test
>>LaTeXType command
>>LaTeXName whatever
>>InPreamble 1
>>Preamble
>>  \newcommand\whatever[1]{#1}
>>EndPreamble
>> End
>>
>> Then LyX gives you:
>>
>> % LyX specific LaTeX commands.
>> \whatever{this is a test}
>>
>> % Textclass specific LaTeX commands.
>> \newcommand\whatever[1]{#1}
>>
>> Which will of course fail. Obviously, the problem is that we output the
>> "Preamble" code *after* we output the code from the paragraph itself.
>>
>> This seems to me to count as a bug. To fix it, though, we'd obviously
>> have to
>> output the code from the style AFTER the Preamble, which would change
>> the TeX
>> export of lots of files. An alternative would be to introduce a new
>> tag that
>> would basically mean: Output this before or after the Preamble code.
>> But I can't
>> imagine why you'd want to do it before the Preamble code.
>>
>> Thoughts?
>
> What about outputting
>
> \AtBeginDocument{\newcommand\whatever[1]{#1}}

This still comes too late: The command \whatever has already been issued.

One could try it the other way, but in the case at issue here the real
command \whatever has to be issued in the preamble.

Richard

Re: 2.2.2-staging Merged to 2.2.x

[Richard Heck]

On 06/16/2016 05:09 PM, Guillaume Munch wrote:

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


I have merged 2.2.2-staging into 2.2.x now, so all commits for stable
should now go to 2.2.x.

Richard




Kudos to Scott for having been meticulous, so that no emergency release
was necessary.


Indeed.

Richard

2.2.2-staging Merged to 2.2.x

[Richard Heck]

I have merged 2.2.2-staging into 2.2.x now, so all commits for stable 
should now go to 2.2.x.


Richard

Re: lyx and dark color schemes

[Richard Heck]

On 06/15/2016 11:48 AM, José Abílio Matos wrote:

On Tuesday, June 14, 2016 9:21:38 PM WEST Guillaume Munch wrote:

latexhighlighter.diff

Could this go to lyx-2.2 as well. I have the same problem with the font
colours but not the panel icons.


OK by me.

Richard

Re: Difference between endnotes and foottoend modules

[Richard Heck]

On 06/15/2016 01:50 PM, Jean-Pierre Chrétien wrote:

Hello,

I'm not sure to have translated the description of these modules all 
right.

* foottoend makes all footnotes endnotes
* endnotes offers an extra inset to add endnotes in addition to plain 
footnotes


If this is right, I must amend my translation of the description of 
endnotes, which is unclear. Too late for 2.1, I will do it for 2.2.x.


Yes, that is right.

rh

Re: Basic module reloaded (Was: scrunched radio buttons on message pane)

[Richard Heck]

On 06/15/2016 01:39 PM, Jean-Pierre Chrétien wrote:

Le 15/06/2016 09:13, Scott Kostyshak a écrit :

On Wed, Jun 15, 2016 at 09:48:03AM +0100, Jean-Pierre Chrétien wrote:


I've seen this once with 2.2.0, but I can't reproduce, maybe I left 
open an

instance of 2.1.5, I see now

../TextClass.cpp (317): Reading module file: [layouts/basic.module]
../TextClass.cpp (330): Finished reading module file: 
[layouts/basic.module]


when I select LyX initialisation tracking.


I'm not sure about the above. If you can find a way to reproduce it, it
would be good to know.


Can't reproduce now even with 2.1.5.
But I get these lines

BufferParams.cpp (2220): setBaseClass: article
../TextClass.cpp (317): Reading module file: [layouts/basic.module]
../TextClass.cpp (330): Finished reading module file: 
[layouts/basic.module]


evety time I open the Document->Settings menu, and apparently, every 
time there is an automatic backup, both with 2.1.5 ans 2.2.0.


What is specific to this module ?


This is the module for the "basic" citation styles. It's normal for it 
to be read when the Document> Settings dialog is created. A copy of the 
BufferParams is created at that time.


Richard

Re: #10216: Lyx V2.2.0 Modules no working

[Richard Heck]

On 06/15/2016 10:37 AM, Robert Betz wrote:
I created a new file with Lyx using the standard article style.  I 
then included the module Customisable Lists (enumitem) using the 
Document->Settings->Modules. I am assuming that the

\usepackage{enumitem}
directive should be in this file.


The enumitem module has changed some since 2.1.x. The enumitem package 
will only be added to the preamble if you actually use some of the 
resources the module provides. Try e.g. putting an enumeration in your 
document.


Richard

Re: Support for more references by "plain label"

[Richard Heck]

On 06/15/2016 10:32 AM, racoon wrote:

Hi,

There are, for example, a number of refstyle commands that are (not 
yet) supported by LyX. Here are some examples: 
http://www.lyx.org/trac/ticket/10201.


I tried to build some of these with modules that use the already 
implemented commands but failed. Basically I tried to catch the 
command, like \ref{}, and read out it's internal label 
reference to recycle it with other commands. LaTeX seems not really to 
be build to do such things. It is also rather cumbersome.


So here is a suggestion to enhance the capabilities of LyX to be more 
easily extendable:


Add an (all purpose) reference format to the cross reference dialog 
that just adds the plain  to the code.


This way one could use the dialog and database of references with many 
other commands which could also be more easily turned into modules. 
Maybe there have to be two of those plain options: one with and one 
without prefixes ("enu:", "eq:", "sec:", etc)?


I guess the citation dialog could profit from a similar option as 
well. But I have not thought about details. This will make it possible 
to use more BibLaTeX commands with the citation dialog and database 
even though the commands lack direct support (at the moment).


Also this will enable support for commands that LyX will probably 
never directly support, for example because LyX is using another 
package by default.


In a way my suggestion seems obvious (to me now) so maybe this has 
been suggested before and probably I am overlooking something. Or is 
this functionality even already implemented somehow? My wild guess is 
that it is rather easy to implement.


Yes, it would be very easy indeed, though it would be a file format 
change, so can't be issued before 2.3.0. And it's a good idea, too, both 
for references and for citations.


An even better idea, in a way, would be to allow the reference types and 
the associated code to be defined dynamically, i.e., in a module.


Richard

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

[Richard Heck]

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

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

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

Maybe we should add an assertion here?


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


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


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


Richard

InPreamble Tag: Bug #10215

[Richard Heck]

Suppose you have a style like this:

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

Then LyX gives you:

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

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

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


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


Thoughts?

Richard

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

[Richard Heck]

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

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

commit 1bd5ef9a754a5b521f9d067b68fdac26035ef342
Author: Richard Heck <rgh...@lyx.org>
Date:   Sat Jun 11 23:26:02 2016 -0400

Add some comments to fix coverity #23386.

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

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

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


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


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


Maybe we should add an assertion here?

Richard

LyX 2.1.5 Tarballs

[Richard Heck]

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

I will be at a conference all week. I'll have email access, of course,
but I won't be at the right IP address for uploading files to
ftp.lyx.org. So I will plan to do the actual release next weekend.

Richard

Re: [LyX/2.2.x] Fix compilation with Qt < 4.7

[Richard Heck]

On 06/12/2016 06:13 PM, Guillaume Munch wrote:
> commit e6d28aad0a6f267c5ce51c5205fdb60343a7fc90
> Author: Guillaume Munch 
> Date:   Sat Jun 11 05:41:48 2016 +0100
>
> Fix compilation with Qt < 4.7

Probably this should go to 2.2.x, as well.

Richard

Re: compilation for coverity fails

[Richard Heck]

On 06/12/2016 02:59 PM, Jean-Marc Lasgouttes wrote:
> Le 12/06/2016 20:53, Richard Heck a écrit :
>> I don't think we have a definite policy, but it would be a good sort of
>> comment to have.
>>
>> Coverity seems to want the comment right before the code it complains
>> about, though, so I'm not sure this can be done ahead of time.
>
> We can also provide models to coverity, which are skeleton versions of
> the functions we use in which some properties can be given.
>
> Hmm, How vague is that? As you can tell, I am not sure how we can use
> this feature.

I'm not sure how useful this is to us, but:
*https://scan.coverity.com/tune

Richard
*