rc1 blocker? (was: Complaints about LyX on Mac)

[Guenter Milde]

On 14.08.17, Stephan Witt wrote:
> Am 14.08.2017 um 14:46 schrieb Guenter Milde :
> > On 2017-08-14, Stephan Witt wrote:
> >> Am 14.08.2017 um 09:43 schrieb Jean-Pierre Chrétien 
> >> :
> > 

> >>> 1) opening splash.lyx, gets a message
> > 
> >>>  No information for converting svgz format files to pdf6.\n
> >>>  Define a converter in the preferences.

> >> One can easily see the images are converted by rsvg-convert on my Mac.

> > Mind, that all icons in the toolbar work without external converter.

Yes, OSx can convert SVG to preview-bitmaps.
You can do this from the command line with "qlmanage"
https://superuser.com/questions/134679/command-line-application-for-converting-svg-to-png-on-mac-os-x

Unfortunatly, this is not a good option for SVG graphics that should end up
as vector in the PDF output.
(And, if I remember right, converting to a bitmap is also supported by QT.)


> > The to-be-converted image is in spash.lyx. It may be a better to remove
> > it from the document (unless the required converter can be bundled with
> > LyX).

> Yes, I see. That’s a difference indeed.

> And no, there are much more icons in the user guide. I cannot imagine to
> remove all these icons. 

True. However, errors when opening the UserGuide are less severe than errors
with every start of LyX. If there is no way to ensure LyX comes with an SVG
converter on Mac, removing the SVG icon from Splash.lyx is a stop-gap measure
to prevent it opening as "unwelcome screen".

> A more smart conversion process should be implemented
> instead. Isn’t this a possible problem for LyX on Linux too?

In Linux, it is the work of the packagers (creating a Debian LyX package,
say) to ensure all requirements for proper working are met.
In Debian, this is 

requires: ... libqt5svg5 (>=5.6.0~beta), ...
suggests: ..., librsvg2-bin | inkscape, ...

The above link lists some options for converting SVG to other formats.
For SVG to PDF, we have

inkscape (good but large)

librsvg  (problem with many images on one side -- breaks the internal preview
  -- maybe we can solve this with some librsvg setting?)

svglib   pure Python, but requires ReportLab (not tested)
 https://pypi.python.org/pypi/svglib/
 
cairosvg based on the Cairo 2D graphics library; 
 known to work at least on Linux, OS X, and Windows;
 requires Python 3
 http://cairosvg.org/


I don't have a Mac, so I cannot test.

Günter

Re: Any rc1 blockers?

[Jean-Marc Lasgouttes]

Le 11/09/2017 à 23:34, Uwe Stöhr a écrit :

Concerning libiconv 1.15, there are not yet opinions.


Updating looks like a good idea IMO.

We could also consider updating boost to 1.65.1 (we have 1.62 right now).

JMarc

Re: Any rc1 blockers?

[Jean-Marc Lasgouttes]

Le 12/09/2017 à 10:59, Jürgen Spitzmüller a écrit :

Hunspell is also outdated.


I'll have a go at it.

JMarc

Re: [LyX features/properpaint] Fix caret painting

[Jean-Marc Lasgouttes]

Le 11/09/2017 à 17:19, Pavel Sanda a écrit :


JMarc, I see the following problem:
Put your caret in the middle of paragraph (line-wise) and at the very end
of line, just behind the last character of the word and hit spacebar.
The space character is (invisbly) inserted, but caret does not move
as it used to.


Hi Pavel,

Actually, this is a regression in 2.2.x, described in ticket
http://www.lyx.org/trac/ticket/10117

The discussion there has slowed down, waiting for Guillaume's patch. Or 
for some great idea.


JMarc

Re: Any rc1 blockers?

[Jürgen Spitzmüller]

2017-09-12 10:15 GMT+02:00 Jean-Marc Lasgouttes :

> Le 11/09/2017 à 23:34, Uwe Stöhr a écrit :
>
>> Concerning libiconv 1.15, there are not yet opinions.
>>
>
> Updating looks like a good idea IMO.
>
> We could also consider updating boost to 1.65.1 (we have 1.62 right now).
>

Hunspell is also outdated.

Jürgen


>
> JMarc
>

Re: [OSX] Missing cite-engine basic

[Stephan Witt]

Am 12.09.2017 um 18:44 schrieb Richard Heck :
> 
> On 09/11/2017 06:05 PM, Ian Wilder wrote:
>> 
>>> On Sep 11, 2017, at 2:02 PM, Richard Heck  wrote:
>>> 
>>> On 09/11/2017 01:35 PM, Ian Wilder wrote:
 I am also having this problem. Ever since I tried to build the 2.3 branch 
 from git using cmake, I have been unable to use the 2.3 binaries. I am not 
 sure if they are related, but I figured mentioning might help.
 
 To be clear, when I try and run 2.3.0-beta1 from the dmg I get the message
 
 "The cite engine basic has been requested by
 this document but has not been found in the list of
 available engines. If you recently installed it, you
 probably need to reconfigure LyX."
 
 Reconfigure does not help.
>>> 
>>> This is on what OS? Did you install the binary? or are you running from the 
>>> build tree?
>>> 
>>> The file LyX is not finding is basic.citeengine, which is found in the 
>>> source tree at lib/citeengines/ and should be installed in a similar 
>>> location.
>>> 
>>> Richard
>>> 
>> 
>> Sorry, the platform is:
>> 
>> Darwin ares 16.7.0 Darwin Kernel Version 16.7.0: Thu Jun 15 17:36:27 PDT 
>> 2017; root:xnu-3789.70.16~2/RELEASE_X86_64 x86_64
>> 
>> I installed the binary form LyX-2.3.0beta1+qt5-x86_64-cocoa.dmg (shasum 
>> 19521bdb012a52b2daabc819a26e78f57bf3c1de)
>> 
>> I had previously tried a build I ran from the build tree using cmake (as the 
>> autotools version did not create a macOS binary) and I first saw this issue 
>> trying to run that version. It has since been removed and it is not possible 
>> that the build version is being run.
> 
> Re-subjecting and cc'ing Stephan, the Mac packager.

I have to admit that I don’t understand what Ian refers to with „It“ and „build 
version“.

When LyX is running configure.py it puts the results in the user-dir - where 
this is depends.

1. Possible scenario with cmake build (if I’m using it for Xcode debugging)

- Excerpt from "$HOME/Library/Application Support/LyX/configure.log“

- The cite engine description is found in source directory:

INFO: +checking list of cite engines... 
INFO: /Users/stephan/git/lyx/lib/citeengines/basic.citeengine
INFO: /Users/stephan/git/lyx/lib/citeengines/biblatex-natbib.citeengine
INFO: /Users/stephan/git/lyx/lib/citeengines/biblatex.citeengine
INFO: /Users/stephan/git/lyx/lib/citeengines/jurabib.citeengine
INFO: /Users/stephan/git/lyx/lib/citeengines/natbib.citeengine
INFO:   done

2. Possible scenario with automake install (real application bundle)

- Excerpt from "$HOME/Library/Application Support/LyX-2.3/configure.log“

- The cite engine description is found in application bundle:

INFO: +checking list of cite engines... 
INFO: 
/Users/stephan/git/lyx-build/LyX-2.3.0dev.app/Contents/Resources/citeengines/basic.citeengine
INFO: 
/Users/stephan/git/lyx-build/LyX-2.3.0dev.app/Contents/Resources/citeengines/biblatex-natbib.citeengine
INFO: 
/Users/stephan/git/lyx-build/LyX-2.3.0dev.app/Contents/Resources/citeengines/biblatex.citeengine
INFO: 
/Users/stephan/git/lyx-build/LyX-2.3.0dev.app/Contents/Resources/citeengines/jurabib.citeengine
INFO: 
/Users/stephan/git/lyx-build/LyX-2.3.0dev.app/Contents/Resources/citeengines/natbib.citeengine
INFO:   done

So the package is fine and the run from build directory too.

Ian, please check your configure.log for this. Are you sure configure run 
succeeded?

What version of python is used by LyX?

Stephan

Re: How to setup image converters on Mac?

[Stephan Witt]

Am 11.09.2017 um 20:55 schrieb Pavel Sanda :
> 
> Stephan Witt wrote:
>>> If it's not easily possible we should at least make clear to newcomers that 
>>> lyx without tex & imagemagick will have lot of problems.
>> 
>> LyX without TeX is a problem. This can be solved by a newcomer by installing 
>> MacTeX. Easy.
>> LyX without ImageMagick shouldn???t be a problem for a user who is working 
>> with PNG, EPS and PDF images only, IMHO.
>> 
>> To install ImageMagick on a Mac you have to install Xcode and MacPorts (or 
>> HoweBrew) and use the terminal to get a running ImageMagick.
>> 
>> What is the fundamental problem I have without ImageMagick? What graphics 
>> capabilities of LyX do you refer to?
> 
> We use convert pretty much as default except when explicit converter is 
> defined so besides few formats and precisely selected output routes you'll 
> get in troubles.
> 
> I doubt even your PNG/EPS/PDF selection will be without problems. If I insert 
> png image and select postscript as output format will it work?
> Will html generation work? Will instant preview work? (didn't check, these 
> just randomly pop in my mind).

HTML generation works.
With LyXHTML I’m not sure - my systems tries to open it in iPhone simulator :) 
PDF with pdflatex works.
PDF with XeTeX works.
DVI doesn’t work - missing PNG to EPS converter. (Perhaps possible to solve 
with existing command line tool „sips“.)
OpenDocument (texht) works.
PDF (dvipdfm) doesn’t work (of course).
PDF (LuaTeX) works.
Postscript doesn’t work - missing PNG to EPS converter.
Instant preview works.

I think the most requested format is PDF - this works in various ways.
HTML and OpenDocument is working too.
Not bad, IMHO.

> Isn't it possible just to grab some statically linked convert and push it 
> into dmg package…?

Perhaps, I didn’t try it because I see it as a last resort. I don’t want to 
provide binaries grabbed from somewhere and I even don’t know if it works.

Even the route of providing self-made utilities isn’t attractive. We have to 
provide bug-fixes for them, IMO. This is not good.

Stephan

> Anyway my point was that current svgz info-inset problem is not likely big 
> deal or even showstopper because my guess is that bunch of other lyx 
> documents we distribute won't compile for various output formats without 
> convert.

Yes, that’s the problem exactly.

BTW, I didn’t say the installation of ImageMagick is useless. My point is: LyX 
shouldn’t present error messages on preview of the documentation as a 
PDF-document. That’s why I’m trying to establish a conversion path from 
LyX+SVG-icons to PDF-output via PNG. I don’t know how to do this. I suspect 
convertDefault.py should simply be avoided if there is no usable „convert“ or 
„magick“ program is available.

Stephan

> But its guess, I did not spent time to investigate.
> 
> Pavel

Re: Any rc1 blockers?

[Uwe Stöhr]

El 12.09.2017 a las 18:49, Scott Kostyshak escribió:


Thanks. Uwe, please go ahead.


Done.

regards Uwe

Re: rc1 blocker? (was: Complaints about LyX on Mac)

[Stephan Witt]

Am 12.09.2017 um 09:19 schrieb Guenter Milde :
> 
> On 14.08.17, Stephan Witt wrote:
>> Am 14.08.2017 um 14:46 schrieb Guenter Milde :
>>> On 2017-08-14, Stephan Witt wrote:
 Am 14.08.2017 um 09:43 schrieb Jean-Pierre Chrétien 
 :
>>> 
> 
> 1) opening splash.lyx, gets a message
>>> 
> No information for converting svgz format files to pdf6.\n
> Define a converter in the preferences.
> 
 One can easily see the images are converted by rsvg-convert on my Mac.
> 
>>> Mind, that all icons in the toolbar work without external converter.
> 
> Yes, OSx can convert SVG to preview-bitmaps.
> You can do this from the command line with "qlmanage"
> https://superuser.com/questions/134679/command-line-application-for-converting-svg-to-png-on-mac-os-x

The output is not useful.
It’s a png - but the original svg-image sits in the upper left corner of a big 
A4- or Letter-PNG.

> Unfortunatly, this is not a good option for SVG graphics that should end up
> as vector in the PDF output.
> (And, if I remember right, converting to a bitmap is also supported by QT.)

Yes, that’s the way I’m trying to go. A small utility based on Qt to convert 
SVG (or SVGZ) to PNG (or JPEG).

>>> The to-be-converted image is in spash.lyx. It may be a better to remove
>>> it from the document (unless the required converter can be bundled with
>>> LyX).
> 
>> Yes, I see. That’s a difference indeed.
> 
>> And no, there are much more icons in the user guide. I cannot imagine to
>> remove all these icons. 
> 
> True. However, errors when opening the UserGuide are less severe than errors
> with every start of LyX. If there is no way to ensure LyX comes with an SVG
> converter on Mac, removing the SVG icon from Splash.lyx is a stop-gap measure
> to prevent it opening as "unwelcome screen".
> 
>> A more smart conversion process should be implemented
>> instead. Isn’t this a possible problem for LyX on Linux too?
> 
> In Linux, it is the work of the packagers (creating a Debian LyX package,
> say) to ensure all requirements for proper working are met.
> In Debian, this is 
> 
> requires: ... libqt5svg5 (>=5.6.0~beta), ...
> suggests: ..., librsvg2-bin | inkscape, …

Suggest doesn't mean required…

> The above link lists some options for converting SVG to other formats.
> For SVG to PDF, we have
> 
> inkscape (good but large)
> 
> librsvg  (problem with many images on one side -- breaks the internal preview
> -- maybe we can solve this with some librsvg setting?)
> 
> svglib   pure Python, but requires ReportLab (not tested)
> https://pypi.python.org/pypi/svglib/
> 
> cairosvg based on the Cairo 2D graphics library; 
>known to work at least on Linux, OS X, and Windows;
>requires Python 3
>http://cairosvg.org/

Cairosvg is not usable on Mac - it uses the X11 raster device.

> I don't have a Mac, so I cannot test.

I see.

Stephan

Re: How to setup image converters on Mac?

[Scott Kostyshak]

On Wed, Sep 13, 2017 at 01:59:55AM +0200, Stephan Witt wrote:

> That’s why I’m trying to establish a conversion path from LyX+SVG-icons to 
> PDF-output via PNG.

If this is implemented and the .lyx files contains an included .svg as a
graphic, then it would also be converted to a bitmap for the PDF output,
right? Personally (meaning for my own use of LyX), I would prefer an
error instead of my vector graphic being converted silently to a bitmap.
But I realize (1) I'm not a typical LyX user and (2) including a .svg
file is not as common as a .eps or .pdf file (which I understand do not
need to be converted so are left as vectors?); and finally (3), I don't
have a better proposal.

It actually amazes me how few people care about including bitmaps
graphics in their final meant-for-publication drafts. I wonder if I am
the only one that is annoyed when I am reading a PDF and see a bitmap
that should be a vector graphic.

Thanks for your work on this tricky issue, Stephan.

Scott


signature.asc
Description: PGP signature

Re: [LyX features/properpaint] Fix caret painting

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> Le 8 septembre 2017 20:02:39 GMT+02:00, Pavel Sanda  a écrit :
> >Jean-Marc Lasgouttes wrote:
> >> Feedback welcome. Everything is supposed to work at this point. The
> >only 
> >> strange point is that my tests with remote executions give poor 
> >> performance. I hoped for the opposite, but this is not a scientific 
> >> comparison.
> >
> >By remote execution you mean running through forwarded ssh tunnel?
> >Pavel
> 
> Yes. But I did not compare with 2.2 in this situation.

I tried, but... :)
Are you still able to compile on the ubuntu 12.04 oldie?
Even if I try beta tarball to avoid our autotools version requirements
it chokes on signal.h and its C++11 constructs. Are we completely
done with 12.04 or is there still some relatively painless way how
to get binary for it?

Pavel

Re: Any rc1 blockers?

[Jürgen Spitzmüller]

2017-09-12 13:09 GMT+02:00 Jürgen Spitzmüller :

> 2017-09-12 12:20 GMT+02:00 Jean-Marc Lasgouttes :
>
>> Le 12/09/2017 à 11:41, Jean-Marc Lasgouttes a écrit :
>> Not so easy after all. What we have is a trimmed down version of 1.3.3,
>> but I am not sure of what we want to trim down.
>>
>
> Just the relevant READMEs, licenses and src/ (without hunspell2, which is
> the forthcoming version that won't work anyway with LyX yet).
>

and msvc/config.h > win_api/config.h

Jürgen


>
> Jürgen
>
>
>>
>> JMarc
>>
>
>

Re: Any rc1 blockers?

[Jean-Marc Lasgouttes]

Le 12/09/2017 à 11:41, Jean-Marc Lasgouttes a écrit :

Le 12/09/2017 à 10:59, Jürgen Spitzmüller a écrit :

Hunspell is also outdated.


I'll have a go at it.


Not so easy after all. What we have is a trimmed down version of 1.3.3, 
but I am not sure of what we want to trim down.


JMarc

Re: Any rc1 blockers?

[Jürgen Spitzmüller]

2017-09-12 12:20 GMT+02:00 Jean-Marc Lasgouttes :

> Le 12/09/2017 à 11:41, Jean-Marc Lasgouttes a écrit :
> Not so easy after all. What we have is a trimmed down version of 1.3.3,
> but I am not sure of what we want to trim down.
>

Just the relevant READMEs, licenses and src/ (without hunspell2, which is
the forthcoming version that won't work anyway with LyX yet).

Jürgen


>
> JMarc
>

Re: #10662: "LyX: Add BibTeX Database" dialog goes behind other dialog after browse step

[Stephan Witt]

Am 12.09.2017 um 11:19 schrieb LyX Ticket Tracker :
> 
> #10662: "LyX: Add BibTeX Database" dialog goes behind other dialog after 
> browse
> step
> --+
> Reporter:  jkulesza  |   Owner:  lasgouttes
> Type:  defect|  Status:  fixedinmaster
> Priority:  normal|   Milestone:  2.2.4
> Component:  general   | Version:  2.3.0dev
> Severity:  normal|  Resolution:
> Keywords:  os=macosx, patch  |
> --+
> Changes (by spitz):
> 
> * cc: rgheck (added)
> * milestone:  2.3.0 => 2.2.4
> 
> 
> Comment:
> 
> Candidate for stable. The bug has also been reported for 2.2 (see #10396),
> and the patch is straightforward.

Wait a minute, please. I have some questions…

1. Why is QDialog::setModal(true) used instead of setModal(true)?

2. What is with the other setModal uses? 
Shouldn’t these followed by a call to setWindowModality(Qt::WindowModal) too?

3. What is with the call of setModal(Qt::WindowModal) in GuiCompareHistory.cpp?
Is this really correct?

Stephan

Re: #10662: "LyX: Add BibTeX Database" dialog goes behind other dialog after browse step

[Jürgen Spitzmüller]

2017-09-12 15:21 GMT+02:00 Stephan Witt :

> Wait a minute, please. I have some questions…
>
> 1. Why is QDialog::setModal(true) used instead of setModal(true)?
>

This code is over 10 years old:
http://www.lyx.org/trac/changeset/c9ea6e6eef090b8/lyxgit

Maybe the namespace specifier is/was needed with some compiler? I don't
know.


2. What is with the other setModal uses?
> Shouldn’t these followed by a call to setWindowModality(Qt::WindowModal)
> too?
>

If this is needed on the Mac. It does not seem to make a difference at all
on Linux.


>
> 3. What is with the call of setModal(Qt::WindowModal) in
> GuiCompareHistory.cpp?
> Is this really correct?
>

Dunno. It has been there from day 1 of this class.

But this all does not strike me an argument for not backporting, since the
change in GuiBibtex clearly fixed a problem on the Mac.

Jürgen


>
> Stephan

Re: Improving the shell-escape warning when a global converter has -shell-escape

[Enrico Forestieri]

On Tue, Sep 12, 2017 at 02:03:34PM -0400, Scott Kostyshak wrote:
> On Wed, Aug 30, 2017 at 08:45:45PM -0400, Scott Kostyshak wrote:
> > I'm interested in the experience of users who already added
> > -shell-escape to their converters and will be using the same preferences
> > file after they upgrade to LyX 2.3.x. When such a user compiles any .lyx
> > file, they will get the following message:
> > 
> > The following LaTeX backend has been configured to allow execution
> > of external programs for any document:
> > 
> > pdflatex -shell-escape $$i
> > 
> > This is a dangerous configuration. Please, consider using the
> > support offered by LyX for allowing this privilege only to documents
> > that actually need it, instead.
> > 
> > I think the warning is good for users who just changed the converter
> > because hopefully it will make sense to them and they will know what
> > "-shell-escape" means, and how they changed the converter (since they
> > just did it). But I'm worried about users who made the change months
> > ago.
> > 
> > Ideally users would send us thank you cards with sparkles for adding
> > extra protection for them by giving this warning, but I have a feeling
> > that many will be confused and annoyed by this new warning that greets
> > them in LyX 2.3.x. First, I'm guessing there are some that added
> > shell-escape a long time ago following some guide and don't even know
> > what it is for. Second, I think we should explain further what solution
> > we're proposing. The following is verbose, but I think the extra words
> > are worth their weight:
> > 
> > The following LaTeX backend has been configured to allow execution
> > of external programs for any document:
> > 
> > pdflatex -shell-escape $$i
> > 
> > Using the -shell-escape option is a dangerous configuration so LyX
> > 2.3.x now gives this warning and offers the option of using
> > -shell-escape only for documents that actually need it. To use this
> > feature, first remove the -shell-escape option from the global
> > converter by going to Preferences > file handling > converters,
> > removing "-shell-escape" from the corresponding converter, and
> > clicking on "Modify" and then "Save". Second, allow for
> > -shell-escape from a .lyx document that needs it by going to
> > Document > Settings > Formats, click on "Allow running external
> > programs", and then "OK".
> > 
> > Any thoughts or alternative improvements?
> 
> Any thoughts? An alternative would be to put this information in the
> docs somewhere and just reference that section for more information.
> 
> I'm fine with keeping the message as it is. I'm not good at predicting
> how users will react so I'm not confident in the changes I proposed and
> they might even make things more confusing. I really don't know.

Maybe a more detailed explanation can be given in the release notes,
which can be referenced in the message. Otherwise, do as you think it
best fits.

-- 
Enrico

[OSX] Missing cite-engine basic

[Richard Heck]

On 09/11/2017 06:05 PM, Ian Wilder wrote:
>
>> On Sep 11, 2017, at 2:02 PM, Richard Heck > > wrote:
>>
>> On 09/11/2017 01:35 PM, Ian Wilder wrote:
>>> I am also having this problem. Ever since I tried to build the 2.3
>>> branch from git using cmake, I have been unable to use the 2.3
>>> binaries. I am not sure if they are related, but I figured
>>> mentioning might help.
>>>
>>> To be clear, when I try and run 2.3.0-beta1 from the dmg I get the
>>> message
>>>
>>> "The cite engine basic has been requested by
>>> this document but has not been found in the list of
>>> available engines. If you recently installed it, you
>>> probably need to reconfigure LyX."
>>>
>>> Reconfigure does not help.
>>
>> This is on what OS? Did you install the binary? or are you running
>> from the build tree?
>>
>> The file LyX is not finding is basic.citeengine, which is found in
>> the source tree at lib/citeengines/ and should be installed in a
>> similar location.
>>
>> Richard
>>
>
> Sorry, the platform is:
>
> Darwin ares 16.7.0 Darwin Kernel Version 16.7.0: Thu Jun 15 17:36:27
> PDT 2017; root:xnu-3789.70.16~2/RELEASE_X86_64 x86_64
>
> I installed the binary form LyX-2.3.0beta1+qt5-x86_64-cocoa.dmg
> (shasum 19521bdb012a52b2daabc819a26e78f57bf3c1de)
>
> I had previously tried a build I ran from the build tree using cmake
> (as the autotools version did not create a macOS binary) and I first
> saw this issue trying to run that version. It has since been removed
> and it is not possible that the build version is being run.

Re-subjecting and cc'ing Stephan, the Mac packager.

Richard

Re: [LyX/2.3.x] #10662 use drawers for bibliography dialogs

[Scott Kostyshak]

On Tue, Sep 12, 2017 at 11:05:44AM +0200, Stephan Witt wrote:
> commit 97dc58513884bb89b6a015c2c7dc61c8bb3f7dfe
> Author: Stephan Witt 
> Date:   Tue Sep 12 11:05:42 2017 +0200
> 
> #10662 use drawers for bibliography dialogs
> 
> This change solves dialog stacking problems on newer Mac OS X in 
> combination with the OS provided file open dialog.

From what I understand, the reason this problem happens only with
GuiBibtex (and thus why this change is only needed in GuiBibtex), is
because that's our only dialog that has stacking. Indeed, I cannot think
of another such dialog, but I feel there might be one that is not
commonly used (so perhaps the bug wasn't reported). Is there a
Qt-stacking-related string that we can grep for that would tell us that
GuiBibtex is indeed the only one that currently uses stacking?

Scott


signature.asc
Description: PGP signature

Re: Any rc1 blockers?

[Scott Kostyshak]

On Tue, Sep 12, 2017 at 10:15:25AM +0200, Jean-Marc Lasgouttes wrote:
> Le 11/09/2017 à 23:34, Uwe Stöhr a écrit :
> > Concerning libiconv 1.15, there are not yet opinions.
> 
> Updating looks like a good idea IMO.

Thanks. Uwe, please go ahead.

Scott


signature.asc
Description: PGP signature

Re: Any rc1 blockers?

[Scott Kostyshak]

On Tue, Sep 12, 2017 at 10:59:00AM +0200, Jürgen Spitzmüller wrote:
> 2017-09-12 10:15 GMT+02:00 Jean-Marc Lasgouttes :
> 
> > Le 11/09/2017 à 23:34, Uwe Stöhr a écrit :
> >
> >> Concerning libiconv 1.15, there are not yet opinions.
> >>
> >
> > Updating looks like a good idea IMO.
> >
> > We could also consider updating boost to 1.65.1 (we have 1.62 right now).
> >
> 
> Hunspell is also outdated.

As for boost and hunspell, I trust your judgments. I'll leave it up to
you to decide whether the changes are worth the risk.

Scott


signature.asc
Description: PGP signature

Re: #10662: "LyX: Add BibTeX Database" dialog goes behind other dialog after browse step

[Richard Heck]

On 09/12/2017 10:01 AM, Jürgen Spitzmüller wrote:
> 2017-09-12 15:51 GMT+02:00 Stephan Witt  >:
>
> In theory it should make a difference on Linux too. Did you test
> with multiple windows open?
>
>
> Yes. I didn't see a difference (which does not mean that there is not
> a difference, of course)
>  
>
>
> > 3. What is with the call of setModal(Qt::WindowModal) in
> GuiCompareHistory.cpp?
> > Is this really correct?
> >
> > Dunno. It has been there from day 1 of this class.
> >
> > But this all does not strike me an argument for not backporting,
> since the change in GuiBibtex clearly fixed a problem on the Mac.
>
> You’re right. It’s not a prerequisite but I’d like to understand
> the issue before backporting.
>
>
> We can play safe and guard it in #ifdef Q_OS_MAC, in order to prevent
> unwanted effects at least on other OSes.
>
> In any case, for stable, it's Richard's call. I just thought that some
> Mac users struggled heavily with the issue (up to the point that they
> though LyX froze and couldn't use the BibTeX dialog anymore).

Maybe it is worth the #ifdef as you say, at least in 2.2.4, so go ahead.
No opinion on 2.3.x.

Richard

Re: Improving the shell-escape warning when a global converter has -shell-escape

[Scott Kostyshak]

On Tue, Sep 12, 2017 at 09:10:40PM +0200, Enrico Forestieri wrote:

> Maybe a more detailed explanation can be given in the release notes,
> which can be referenced in the message. Otherwise, do as you think it
> best fits.

Makes sense. I will propose a patch. In the message I will put something
like <>.

The patch will be specific to the 2.3.x branch. I don't think we should
change anything for master branch.

Scott


signature.asc
Description: PGP signature

Re: Improving the shell-escape warning when a global converter has -shell-escape

[Scott Kostyshak]

On Wed, Aug 30, 2017 at 08:45:45PM -0400, Scott Kostyshak wrote:
> I'm interested in the experience of users who already added
> -shell-escape to their converters and will be using the same preferences
> file after they upgrade to LyX 2.3.x. When such a user compiles any .lyx
> file, they will get the following message:
> 
> The following LaTeX backend has been configured to allow execution
> of external programs for any document:
> 
> pdflatex -shell-escape $$i
> 
> This is a dangerous configuration. Please, consider using the
> support offered by LyX for allowing this privilege only to documents
> that actually need it, instead.
> 
> I think the warning is good for users who just changed the converter
> because hopefully it will make sense to them and they will know what
> "-shell-escape" means, and how they changed the converter (since they
> just did it). But I'm worried about users who made the change months
> ago.
> 
> Ideally users would send us thank you cards with sparkles for adding
> extra protection for them by giving this warning, but I have a feeling
> that many will be confused and annoyed by this new warning that greets
> them in LyX 2.3.x. First, I'm guessing there are some that added
> shell-escape a long time ago following some guide and don't even know
> what it is for. Second, I think we should explain further what solution
> we're proposing. The following is verbose, but I think the extra words
> are worth their weight:
> 
> The following LaTeX backend has been configured to allow execution
> of external programs for any document:
> 
> pdflatex -shell-escape $$i
> 
> Using the -shell-escape option is a dangerous configuration so LyX
> 2.3.x now gives this warning and offers the option of using
> -shell-escape only for documents that actually need it. To use this
> feature, first remove the -shell-escape option from the global
> converter by going to Preferences > file handling > converters,
> removing "-shell-escape" from the corresponding converter, and
> clicking on "Modify" and then "Save". Second, allow for
> -shell-escape from a .lyx document that needs it by going to
> Document > Settings > Formats, click on "Allow running external
> programs", and then "OK".
> 
> Any thoughts or alternative improvements?

Any thoughts? An alternative would be to put this information in the
docs somewhere and just reference that section for more information.

I'm fine with keeping the message as it is. I'm not good at predicting
how users will react so I'm not confident in the changes I proposed and
they might even make things more confusing. I really don't know.

Scott


signature.asc
Description: PGP signature

Re: #10662: "LyX: Add BibTeX Database" dialog goes behind other dialog after browse step

[Stephan Witt]

Am 12.09.2017 um 15:42 schrieb Jürgen Spitzmüller :
> 
> 2017-09-12 15:21 GMT+02:00 Stephan Witt :
> Wait a minute, please. I have some questions…
> 
> 1. Why is QDialog::setModal(true) used instead of setModal(true)?
> 
> This code is over 10 years old:
> http://www.lyx.org/trac/changeset/c9ea6e6eef090b8/lyxgit
> 
> Maybe the namespace specifier is/was needed with some compiler? I don't know. 

Yes, maybe.

> 2. What is with the other setModal uses?
> Shouldn’t these followed by a call to setWindowModality(Qt::WindowModal) too?
> 
> If this is needed on the Mac. It does not seem to make a difference at all on 
> Linux.

In theory it should make a difference on Linux too. Did you test with multiple 
windows open?

> 3. What is with the call of setModal(Qt::WindowModal) in 
> GuiCompareHistory.cpp?
> Is this really correct?
> 
> Dunno. It has been there from day 1 of this class.
> 
> But this all does not strike me an argument for not backporting, since the 
> change in GuiBibtex clearly fixed a problem on the Mac.

You’re right. It’s not a prerequisite but I’d like to understand the issue 
before backporting.

Stephan

Re: #10662: "LyX: Add BibTeX Database" dialog goes behind other dialog after browse step

[Jürgen Spitzmüller]

2017-09-12 15:51 GMT+02:00 Stephan Witt :

> In theory it should make a difference on Linux too. Did you test with
> multiple windows open?
>

Yes. I didn't see a difference (which does not mean that there is not a
difference, of course)


>
> > 3. What is with the call of setModal(Qt::WindowModal) in
> GuiCompareHistory.cpp?
> > Is this really correct?
> >
> > Dunno. It has been there from day 1 of this class.
> >
> > But this all does not strike me an argument for not backporting, since
> the change in GuiBibtex clearly fixed a problem on the Mac.
>
> You’re right. It’s not a prerequisite but I’d like to understand the issue
> before backporting.
>

We can play safe and guard it in #ifdef Q_OS_MAC, in order to prevent
unwanted effects at least on other OSes.

In any case, for stable, it's Richard's call. I just thought that some Mac
users struggled heavily with the issue (up to the point that they though
LyX froze and couldn't use the BibTeX dialog anymore).

Jürgen


>
> Stephan

Which 3rd party deps do we include?

[Scott Kostyshak]

Dear all,

I would like to make a list of 3rd party dependencies that we include.
Do we already have such a list? In future major releases, I would
propose that the release manager consider updating these dependencies
before any alpha release, and perhaps before any beta. Actually, if
others prefer, I'm fine with updating them even before an rc; but even
in this case we can reduce the risk of an incompatibility by also
remembering to update them before an earlier pre-release so I think
collecting this list is still useful.

Ideally, we would include the following information in such a list:

  dependency name:
  URL to check for new version:
  loose guidelines for updating: [e.g. only point releases; only before
  alpha; only if we need a newer feature]

But I will be happy if we just make a list of names.

The following is useful:

  ls 3rdparty/

But I think there may be others?

So far on the list I see:

boost
evince_sync
hunspell
iconv
mythes
xvkbd
zlib

For example, since xvkbd is only used for our tests, I think we could
update it at any time. Although in theory the keytests would be robust
enough that we would encourage packagers to run these tests so maybe we
should be more careful. But since in my opinion the tests are too
fragile we should not push packagers.

What else should we add to the list?

Scott


signature.asc
Description: PGP signature