Re: Missing icons

2022-08-09 Thread Jean-Pierre Chrétien

Le 06/08/2022 à 18:55, Jean-Pierre Chrétien a écrit :

Dear Developers,

With the latest 2.4.0dev version, I do not see anymore the icons for "Find and 
Replace", "Find and Replace (advanced)" and "Toggle outline", but the plain text.


Problem solved.
Thanks, Jürgen.

--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Missing icons

2022-08-06 Thread Jean-Pierre Chrétien

Dear Developers,

With the latest 2.4.0dev version, I do not see anymore the icons for "Find and 
Replace", "Find and Replace (advanced)" and "Toggle outline", but the plain text.


See attached screenshot.

--
Jean-Pierre-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Wrong commit ?

2022-08-01 Thread Jean-Pierre Chrétien

Le 31/07/2022 à 19:16, Kornel Benko a écrit :

Am Sun, 31 Jul 2022 18:48:01 +0200
schrieb Jean-Pierre Chrétien :


Dear Developers,

While committing a very minor change in the French UserGuide, I had a warning
about the fact that I was in "Detached HEAD mode".

I committed nevertheless, but I see in the log that there is something fishy:


$ git log
commit 4c72d8aeac01c53e27732999108f249356e67c5c (HEAD -> master, origin/master,
origin/HEAD)
Author: jpc 
Date:   Sun Jul 31 18:28:23 2022 +0200

  Info in French UserGuide

commit c04192526187c1b3bfe7d7dcabd9cd6c50084642
Author: Pavel Sanda 
Date:   Sun Jul 31 11:13:53 2022 +0200

  pyupgrade related fixes to python scripts #2.

  Patch from Jose.
  https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg21.html


Is my commit in the right place?

What should I do to return to normal behavior?
Should I run

$git switch -


Maybe
$ git checkout master
?


from what I understand from the inline explanations?



Looks OK here.

commit 4c72d8ae
Author: jpc 
AuthorDate: Sun Jul 31 18:28:23 2022 +0200
Commit: jpc 
CommitDate: Sun Jul 31 18:29:23 2022 +0200

 Info in French UserGuide




What bugs me is the  (HEAD -> master, origin/master, origin/HEAD) part, which is 
not present usually.


--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Wrong commit ?

2022-07-31 Thread Jean-Pierre Chrétien

Dear Developers,

While committing a very minor change in the French UserGuide, I had a warning 
about the fact that I was in "Detached HEAD mode".


I committed nevertheless, but I see in the log that there is something fishy:


$ git log
commit 4c72d8aeac01c53e27732999108f249356e67c5c (HEAD -> master, origin/master, 
origin/HEAD)

Author: jpc 
Date:   Sun Jul 31 18:28:23 2022 +0200

Info in French UserGuide

commit c04192526187c1b3bfe7d7dcabd9cd6c50084642
Author: Pavel Sanda 
Date:   Sun Jul 31 11:13:53 2022 +0200

pyupgrade related fixes to python scripts #2.

Patch from Jose.
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg21.html


Is my commit in the right place?

What should I do to return to normal behavior?
Should I run

$git switch -

from what I understand from the inline explanations?

--
Jean-Pierre




--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [LyX/master] Update fr.po and a couple of shortcuts defined with non-existing letters

2022-06-14 Thread Jean-Pierre Chrétien

Le 13/06/2022 à 12:48, Kornel Benko a écrit :

Am Mon, 13 Jun 2022 09:07:12 +0200 (CEST)
schrieb jpc :


Normal Space|w"


You missed
#: lib/ui/stdmenus.inc:454
msgid "Normal Space|w"


Thanks, I did not check stdmenus.inc



Also there is wrong translation in fr.po to
"Espace large négative insécable (−5/18 em)a"
(missing '|'?)
but probably in conflict with
"Dimension réglable|a"


Right, corrected and shortcut conflicts solved.

I have a question : with Debian stable, when I open the InsetSpace context menu, 
the selection is controlled by check-boxes. In that case, shortcuts are not 
useful. Is it different on other platforms where the shortcuts would be welcome ?


--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [LyX/master] Make space names more standard

2022-06-13 Thread Jean-Pierre Chrétien

Le 12/06/2022 à 13:07, Juergen Spitzmueller a écrit :

commit b2a7b715a2c6f0d9f26a180c15e1570308dc6d6c
Author: Daniel Ramoeller 
Date:   Wed Jun 8 08:20:37 2022 +0200

 Make space names more standard
 
 Fix for bug #12547.
 
 - "Interword" becomes "Normal"

 - "Protected" becomes "Non-Breaking"
 
 Plus a minor fixes to the "Horizontal Space Settings" dialog:

 - Indicate that when "Non-Breaking" is disabled, the space will be 
non-breaking


While translating in French, I saw that a couple of original English shortcuts 
letters were not found in the string:


Item "Normal Space|w"
Item "Half Quad Space (1/2 em)|k"
Item "Non-Breaking Half Quad Space (1/2 em)|E"

I updated these to

Item "Normal Space|e"
Item "Half Quad Space (1/2 em)|S"
Item "Non-Breaking Half Quad Space (1/2 em)|k"

with hopefully no shortcuts conflicts.

--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [LyX/master] Revert "Add UI for selecting backing store drawing strategy"

2022-01-13 Thread Jean-Pierre Chrétien

Le 13/01/2022 à 17:29, Jean-Pierre Chrétien a écrit :

Le 13/01/2022 à 16:46, Jean-Marc Lasgouttes a écrit :

commit 854fbc52621f3ecdced7cada98d72da8e8e35428
Author: Jean-Marc Lasgouttes 
Date:   Thu Jan 13 17:09:42 2022 +0100

 Revert "Add UI for selecting backing store drawing strategy"


Effectivement...
J'avais soumis la traduction.
Je suppose que le message traduit en français va disparaître avec le message 
original ?



Sorry for the noise, this was intended for Jean-Marc only.  :-(

--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [LyX/master] Revert "Add UI for selecting backing store drawing strategy"

2022-01-13 Thread Jean-Pierre Chrétien

Le 13/01/2022 à 16:46, Jean-Marc Lasgouttes a écrit :

commit 854fbc52621f3ecdced7cada98d72da8e8e35428
Author: Jean-Marc Lasgouttes 
Date:   Thu Jan 13 17:09:42 2022 +0100

 Revert "Add UI for selecting backing store drawing strategy"
 


Effectivement...
J'avais soumis la traduction.
Je suppose que le message traduit en français va disparaître avec le message 
original ?


--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Performance regression in export to LaTeX?

2021-12-20 Thread Jean-Pierre Chrétien

Le 20/12/2021 à 12:16, Jürgen Spitzmüller a écrit :

Am Montag, dem 20.12.2021 um 10:21 +0100 schrieb Jürgen Spitzmüller:

Tried again and (once more) ended up at

commit 26ea1e14966c092a7b87c75c19b83a369e79aeb8
Author: Juergen Spitzmueller 
Date:   Sun Apr 22 19:06:46 2018 +0200

     Align fontenc with document fonts

I'll check if we can do something.


c2f2ba57f1275c should address this one.


Now :

real0m11,354s
user0m9,962s
sys 0m1,044s
--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Performance regression in export to LaTeX?

2021-12-20 Thread Jean-Pierre Chrétien

Le 19/12/2021 à 15:45, Jürgen Spitzmüller a écrit :

Am Sonntag, dem 19.12.2021 um 15:03 +0100 schrieb Jürgen Spitzmüller:

So it's the cprotection checks that seem to cost time. Need to check
whether this can be optimized.


After 61b8afd893ec we're back at

real0m19,685s
user0m15,633s
sys 0m3,025s



Recompiling after 61b8afd893ec leads here to

real0m13,374s
user0m11,999s
sys 0m1,012s

instead of

real0m31,623s
user0m22,924s
sys0m1,532s

(which includes 9s of lyx reconfiguration, that means thet real must be rather 
22s).

To be compared to the 2.3.x result

real0m9,749s
user0m8,459s
sys0m1,320s

So the ratio is now 10/13 instead of a little
over 2.

--
Jean-Pierre


--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Performance regression in export to LaTeX?

2021-12-18 Thread Jean-Pierre Chrétien

Le 18/12/2021 à 03:23, Scott Kostyshak a écrit :

If I do

   time lyx -e pdflatex UserGuide.lyx

I get big differences in timings if I do the above with master versus
with 2.3.0. I'm not sure these differences necessarily mean a
regression. I've definitely compiled master with different compile
flags.

Does anyone else see differences when comparing 2.3.0 (or 2.3.x) to
master with the above command?


Hello Scott,

Here I must run

time  -e pdf2 UserGuide.lyx

With 2.3.7dev:

real0m9,749s
user0m8,459s
sys 0m1,320s


With 2.4.0dev (up to date):

real0m31,623s
user0m22,924s
sys 0m1,532s

Ration ~ 3

--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Export to 2.3.x of French linguistics manual fails to compile on 2.3.x

2021-12-09 Thread Jean-Pierre Chrétien

Le 08/12/2021 à 10:22, Jürgen Spitzmüller a écrit :

Am Mittwoch, dem 08.12.2021 um 09:51 +0100 schrieb Jürgen Spitzmüller:

The other is the reversion with language switches. Might be more
difficult, I'll check.


I forgot that language switches in glosses do not work. In the long
run, we should probably allow language switches in LyX (for spell
checking) but output no language markup to LaTeX. Something like an
OmitLangSwitch layout tag.


Thanks for checking and fixing things, Jürgen.

--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Upgrade from buster to bullseye

2021-11-11 Thread Jean-Pierre Chrétien

Le 11/11/2021 à 13:23, Jean-Marc Lasgouttes a


Editing policy.html was the trick.
Thanks to all of you who helped.


Do you have rsvg-convert installed? Is it used in this situation?


I installed librsvg2-bin, reconfigured lyx-2.3.7dev, removed files from the 
cache and again, compilation of the UserGuide went flawlessly with calls to rsvg.


The rsvg path is actually easier on Debian that editing the ImageMagick policy 
file.

I never use Debian install of LyX because it requires to install Texlive as well 
(and I install it separately from tug.org), but is librsvg2-bin in the Lyx 
dependencies ?


--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Upgrade from buster to bullseye

2021-11-11 Thread Jean-Pierre Chrétien

Le 11/11/2021 à 11:52, Jean-Pierre Chrétien a écrit :

Le 10/11/2021 à 14:32, Jean-Marc Lasgouttes a écrit :

Le 10/11/2021 à 14:07, Jean-Pierre Chrétien a écrit :

You need to enable "files" debug level.


This not very informative, in fact I would like to see the conversion command 
to be able to test it from the console.


I should (from Converter::convert, l. 661):
 LYXERR(Debug::FILES, "Calling " << command);

What do you have as output?


No Converter.cpp reference, so the message is not triggered. All references are 
to ConverterCache.cpp, so I guess that I should clean the cache, but I do not 
remember how...




I found a cache directory in my personal LyX dir, so I removed the contents ans 
bingo! compilation of the UserGuide works flawlessly.



ConverterCache.cpp (401): not in cache.
Looking for python v2.x or 3.x ...
Examining /opt/texlive/2021/bin/x86_64-linux/pythontex
Examining /usr/bin/python2
Found Python 2.7.18

Converter.cpp (430): No converter defined! I use convertDefault.py:
	/usr/bin/python2 -tt "/usr/local/share/lyx-2.3.7dev/scripts/convertDefault.py" 
svgz 
"/tmp/lyx_tmpdir.XrMxvxhYnibI/lyx_tmpbuf0/0_usr_local_share_lyx-2_3_7dev_images_buffer-new.svgz" 
pdf 
"/tmp/lyx_tmpdir.XrMxvxhYnibI/lyx_tmpbuf0/0_usr_local_share_lyx-2_3_7dev_images_buffer-new.pdf"
ConverterCache.cpp (270):  /usr/local/share/lyx-2.3.7dev/images/buffer-new.svgz 
pdf6 
/tmp/lyx_tmpdir.XrMxvxhYnibI/lyx_tmpbuf0/0_usr_local_share_lyx-2_3_7dev_images_buffer-new.pdf



Editing policy.html was the trick.
Thanks to all of you who helped.

--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Upgrade from buster to bullseye

2021-11-11 Thread Jean-Pierre Chrétien

Le 10/11/2021 à 14:32, Jean-Marc Lasgouttes a écrit :

Le 10/11/2021 à 14:07, Jean-Pierre Chrétien a écrit :

You need to enable "files" debug level.


This not very informative, in fact I would like to see the conversion command 
to be able to test it from the console.


I should (from Converter::convert, l. 661):
 LYXERR(Debug::FILES, "Calling " << command);

What do you have as output?


No Converter.cpp reference, so the message is not triggered. All references are 
to ConverterCache.cpp, so I guess that I should clean the cache, but I do not 
remember how...


--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Upgrade from buster to bullseye

2021-11-10 Thread Jean-Pierre Chrétien

Le 09/11/2021 à 12:22, Pavel Sanda a écrit :

On Tue, Nov 09, 2021 at 11:28:30AM +0100, Jean-Pierre Chrétien wrote:

I edited /etc/ImageMagick-6/policy.xml without success, here is the log of
the first file to convert, extracted from lyx-2.3.7dev -dbg graphics


Can show the current content of that config?


File attached. This is the original bullseye file in which I changed lines 93, 
96, 97.





How can I display the conversion process from svgz to pdf6 itself?


You need to enable "files" debug level.


This not very informative, in fact I would like to see the conversion command to 
be able to test it from the console.


--
Jean-Pierre



  
  
  
]>


  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Upgrade from buster to bullseye

2021-11-09 Thread Jean-Pierre Chrétien

Le 08/11/2021 à 21:57, Pavel Sanda a écrit :



Yes, this is default imagemagick policy on debian now.
First introduced in buster to overcome ghostscritp security issues, then 
reverted
in testing (forthcoming bullseye) and  then reintroduced again. I tried to 
explain
the situation in couple debian bugs but no one seem to care.


I did not get these messages with buster, maybe I upgraded from etch after the 
reversion to testing.




The situation is very unfortunate, because this default policy ban on
postscript conversions can not be overriden by user setting and if you
don't have root access on the machine you work, you can't use
postscript anymore.


I edited /etc/ImageMagick-6/policy.xml without success, here is the log of the 
first file to convert, extracted from lyx-2.3.7dev -dbg graphics



insets/InsetGraphics.cpp (119): findTargetFormat: PDF mode
insets/InsetGraphics.cpp (742):  we have: from svgz to pdf6
insets/InsetGraphics.cpp (748): 	the orig file is: 
/usr/local/share/lyx-2.3.7dev/images/buffer-new.svgz
insets/InsetGraphics.cpp (794): 	The original file is 
/usr/local/share/lyx-2.3.7dev/images/buffer-new.svgz

A copy has been made and convert is to be called with:
	file to convert = 
/tmp/lyx_tmpdir.ukkrIUtySeWW/lyx_tmpbuf0/0_usr_local_share_lyx-2_3_7dev_images_buffer-new.svgz

 from svgz to pdf6
insets/InsetGraphics.cpp (924): InsetGraphics::latex outputting:
\includegraphics[width=1em]{0_usr_local_share_lyx-2_3_7dev_images_buffer-new.pdf}


With 2.4.0dev (wich works all right), I get this :


insets/InsetGraphics.cpp (117): findTargetFormat: PDF mode
insets/InsetGraphics.cpp (735):  we have: from svgz to pdf6
insets/InsetGraphics.cpp (741): 	the orig file is: 
/usr/local/share/lyx-2.4.0dev/images/buffer-new.svgz
insets/InsetGraphics.cpp (787): 	The original file is 
/usr/local/share/lyx-2.4.0dev/images/buffer-new.svgz

A copy has been made and convert is to be called with:
	file to convert = 
/tmp/lyx_tmpdir.HrwLplbmyPtA/lyx_tmpbuf0/export_buffer-new_svgz_c835ff7b1cb15ad019ad9820ad3e422677e2fb0ffb807224b41310571151427e.svgz

 from svgz to pdf6
insets/InsetGraphics.cpp (916): InsetGraphics::latex outputting:
\includegraphics[width=1em]{export_buffer-new_svgz_c835ff7b1cb15ad019ad9820ad3e422677e2fb0ffb807224b41310571151427e.pdf}


How can I display the conversion process from svgz to pdf6 itself?

--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Upgrade from buster to bullseye

2021-11-09 Thread Jean-Pierre Chrétien

Le 08/11/2021 à 21:57, Pavel Sanda a écrit :

On Mon, Nov 08, 2021 at 11:03:25AM +0100, Jean-Pierre Chrétien wrote:

On 2.3.x, I first checked the fr.po file status and when I ran the make
lyx-2.3.7dev.pot-update in the po dir of the build directory, I got in the
following error:

/bin/sh: 1: /usr/bin/python: not found
make: *** [Makefile:774 : qt4_l10n.pot] Erreur 127

So I created a link:

sudo ln -s /usr/bin/python3 /usr/bin/python

and the problem was solved.


This is actually not correct way how to solve this under bullseye.
"python" is gone for good and scripts should use either python2
or python3 binary.


I was quite aware that my workaround was not the correct solution.

However, as

make lyx-2.3.7dev.pot-update

fails because of missing python

while

make lyx-2.4.0dev.pot-update

succeeds, is it possible to cherry-pick the python management from master ?


If you insist on using "python" you should install specific package (IIRC 
"python") via:
apt install python


It is not me who insists, it is lyx-2.3.7dev :-)

--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Upgrade from buster to bullseye

2021-11-08 Thread Jean-Pierre Chrétien

Le 08/11/2021 à 14:12, Kornel Benko a écrit :





For ubuntu/debian it was sufficient to modify the imagemagic policy.
Like:
$ cp /etc/ImageMagick-6/policy.xml ~/.config/ImageMagick/.
and add/modify policies for PS, PDF and EPS in ~/.config/ImageMagick/policy.xml 
to




I removen rsvh-conbert, reconfigured, created and edited 
~/.config/ImageMagick/policy.xml and now, same behavior as with rsvg-convert, 
latex does not find the files.  I'm lost. What is broken now ? I will recompile 
lyx-2.3.7dev from scratch.


--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Upgrade from buster to bullseye

2021-11-08 Thread Jean-Pierre Chrétien

Le 08/11/2021 à 11:20, Jean-Marc Lasgouttes a écrit :

Le 08/11/2021 à 11:03, Jean-Pierre Chrétien a écrit :

Dear developers

I upgraded my Debian yesterday and I tested compilation and execution of 
master and 2.3.7dev.


Compilation and display of the UserGuide run flawlessly on master.

On 2.3.x, I first checked the fr.po file status and when I ran the make 
lyx-2.3.7dev.pot-update in the po dir of the build directory, I got in the 
following error:


/bin/sh: 1: /usr/bin/python: not found
make: *** [Makefile:774 : qt4_l10n.pot] Erreur 127


This is for José, right?


I guess so.





So I created a link:

sudo ln -s /usr/bin/python3 /usr/bin/python

and the problem was solved.

The I compiled lyx-2.3.7dev all right with QT5 (QT4 fails).

However, when compiling the pdf of the UserGuide, none of the svgz icons could 
be converted, so the padf dispaly failed with a pdf image not found. Here is 
first of the error messages:


convert-im6.q16: attempt to perform an operation not allowed by the security 
policy `PDF' @ error/constitute.c/IsCoderAuthorized/421.

/usr/local/share/lyx-2.3.7dev/scripts/convertDefault.py ERROR
Execution of "convert" failed.


Do you have rsvg-convert intalled (in librsvg2-bin package here).


No I hadn't. So I installed librsvg2-bin, reconfigured LyX and it seems that the 
situation is worse : the conversion does not even seem to take place.




This "convert" situation is really horrible, I do not understand that there is 
no workaround yet.


As the problem seems to be gone with master, I guess that such a workaround 
won't be needed in the (near?) future.

But why is the behavior different between 2.3.7 and 2.4.0?

--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Upgrade from buster to bullseye

2021-11-08 Thread Jean-Pierre Chrétien

Dear developers

I upgraded my Debian yesterday and I tested compilation and execution of master 
and 2.3.7dev.


Compilation and display of the UserGuide run flawlessly on master.

On 2.3.x, I first checked the fr.po file status and when I ran the make 
lyx-2.3.7dev.pot-update in the po dir of the build directory, I got in the 
following error:


/bin/sh: 1: /usr/bin/python: not found
make: *** [Makefile:774 : qt4_l10n.pot] Erreur 127

So I created a link:

sudo ln -s /usr/bin/python3 /usr/bin/python

and the problem was solved.

The I compiled lyx-2.3.7dev all right with QT5 (QT4 fails).

However, when compiling the pdf of the UserGuide, none of the svgz icons could 
be converted, so the padf dispaly failed with a pdf image not found. Here is 
first of the error messages:


convert-im6.q16: attempt to perform an operation not allowed by the security 
policy `PDF' @ error/constitute.c/IsCoderAuthorized/421.

/usr/local/share/lyx-2.3.7dev/scripts/convertDefault.py ERROR
Execution of "convert" failed.
support/Systemcall.cpp (276): Systemcall: 'python -tt 
"/usr/local/share/lyx-2.3.7dev/scripts/convertDefault.py" svgz 
"/tmp/lyx_tmpdir.ISfQxXhtSZQG/lyx_tmpbuf0/0_usr_local_share_lyx-2_3_7dev_images_buffer-view.svgz" 
pdf 
"/tmp/lyx_tmpdir.ISfQxXhtSZQG/lyx_tmpbuf0/0_usr_local_share_lyx-2_3_7dev_images_buffer-view.pdf"' 
finished with exit code 1


--
Jean-Pierre


--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Makefile in po

2021-10-18 Thread Jean-Pierre Chrétien

Le 18/10/2021 à 13:55, Jean-Marc Lasgouttes a écrit :

Le 18/10/2021 à 12:12, Jean-Pierre Chrétien a écrit :

Le 18/10/2021 à 11:46, Jean-Marc Lasgouttes a écrit :

Le 18/10/2021 à 10:53, Jean-Pierre Chrétien a écrit :

Hello

The files Makefile disappeared from the po directory, both in master and 2.3.x.
I need them to remerge strings.
I ran ./autogen.sh with no success.
what's wrong here ?



Hi Jean-Pierre,

Did you run ./configure too?


Sure, lyx compiles fine in both cases. Bot po contains only

Makefile.in.in Makevars   Makevars.template




Towards the end of the configure run, I see:

config.status: executing po-directories commands
config.status: creating po/POTFILES
config.status: creating po/Makefile

Don't you see that?


Sure.

Stupid of me, I was looking for Makefile in master/po, not in /po.

Sorry for the noise.

--
Jean-Pierre


--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: DeprecationWarning when installing master

2021-10-18 Thread Jean-Pierre Chrétien

Le 18/10/2021 à 13:22, Jean-Pierre Chrétien a écrit :

Dear developers

I get this :

$ sudo make install-strip >>make.log
-c:2: DeprecationWarning: the imp module is deprecated in favour of importlib; 
see the module's documentation for alternative uses




With some context :

 /usr/bin/install -c -m 644 ../../../master/lib/lyx2lyx/lyx2lyx 
lyx2lyx_version.py ../../../master/lib/lyx2lyx/lyx2lyx_lang.py 
../../../master/lib/lyx2lyx/generate_encoding_info.py 
../../../master/lib/lyx2lyx/parser_tools.py 
../../../master/lib/lyx2lyx/lyx2lyx_tools.py 
../../../master/lib/lyx2lyx/unicode_symbols.py 
../../../master/lib/lyx2lyx/LyX.py ../../../master/lib/lyx2lyx/lyx_0_06.py 
../../../master/lib/lyx2lyx/lyx_0_08.py ../../../master/lib/lyx2lyx/lyx_0_10.py 
../../../master/lib/lyx2lyx/lyx_0_12.py ../../../master/lib/lyx2lyx/lyx_1_0.py 
../../../master/lib/lyx2lyx/lyx_1_1.py ../../../master/lib/lyx2lyx/lyx_1_1_5.py 
../../../master/lib/lyx2lyx/lyx_1_1_6_0.py 
../../../master/lib/lyx2lyx/lyx_1_1_6_3.py 
../../../master/lib/lyx2lyx/lyx_1_2.py ../../../master/lib/lyx2lyx/lyx_1_3.py 
../../../master/lib/lyx2lyx/lyx_1_4.py ../../../master/lib/lyx2lyx/lyx_1_5.py 
../../../master/lib/lyx2lyx/lyx_1_6.py ../../../master/lib/lyx2lyx/lyx_2_0.py 
../../../master/lib/lyx2lyx/lyx_2_1.py ../../../master/lib/lyx2lyx/lyx_2_2.py 
../../../master/lib/lyx2lyx/lyx_2_3.py ../../../master/lib/lyx2lyx/lyx_2_4.py 
../../../master/lib/lyx2lyx/profiling.py 
../../../master/lib/lyx2lyx/test_parser_tools.py 
'/usr/local/share/lyx-2.4.0dev/lyx2lyx'
-c:2: DeprecationWarning: the imp module is deprecated in favour of importlib; 
see the module's documentation for alternative uses

Byte-compiling python modules...
lyx2lyx_version.pylyx2lyx_lang.pygenerate_encoding_info.pyparser_tools.pylyx2lyx_tools.pyunicode_symbols.pyLyX.pylyx_0_06.pylyx_0_08.pylyx_0_10.pylyx_0_12.pylyx_1_0.pylyx_1_1.pylyx_1_1_5.pylyx_1_1_6_0.pylyx_1_1_6_3.pylyx_1_2.pylyx_1_3.pylyx_1_4.pylyx_1_5.pylyx_1_6.pylyx_2_0.pylyx_2_1.pylyx_2_2.pylyx_2_3.pylyx_2_4.pyprofiling.pytest_parser_tools.py

--
Jean-Pierre



--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


DeprecationWarning when installing master

2021-10-18 Thread Jean-Pierre Chrétien

Dear developers

I get this :

$ sudo make install-strip >>make.log
-c:2: DeprecationWarning: the imp module is deprecated in favour of importlib; 
see the module's documentation for alternative uses


--
Regards
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Makefile in po

2021-10-18 Thread Jean-Pierre Chrétien

Le 18/10/2021 à 11:46, Jean-Marc Lasgouttes a écrit :

Le 18/10/2021 à 10:53, Jean-Pierre Chrétien a écrit :

Hello

The files Makefile disappeared from the po directory, both in master and 2.3.x.
I need them to remerge strings.
I ran ./autogen.sh with no success.
what's wrong here ?



Hi Jean-Pierre,

Did you run ./configure too?


Sure, lyx compiles fine in both cases. Bot po contains only

Makefile.in.in Makevars   Makevars.template

--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Makefile in po

2021-10-18 Thread Jean-Pierre Chrétien

Hello

The files Makefile disappeared from the po directory, both in master and 2.3.x.
I need them to remerge strings.
I ran ./autogen.sh with no success.
what's wrong here ?

--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Master regression example with emph and comment

2021-09-26 Thread Jean-Pierre Chrétien

Le 25/09/2021 à 20:04, Scott Kostyshak a écrit :

The attached example compiles fine with 2.3.x. On master, the \emph is not closed after 
"regardless" as what happens on 2.3.x.


Right, the comment is encapsulated in the \emph command.

With 2.3.7, the command is closed all right before the comment, but there is 
still a harmless {} after the comment.


--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Fwd: [LyX/master] Add hint about the need of Acrobat DC

2021-07-07 Thread Jean-Pierre Chrétien

Hello Riki

This one is candidate for stable.

Jean-Pierre


 Message transféré 
Sujet : [LyX/master] Add hint about the need of Acrobat DC
Date : Tue,  6 Jul 2021 18:38:01 +0200 (CEST)
De : jpc 
Répondre à : lyx-devel@lists.lyx.org
Pour : lyx-...@lists.lyx.org

commit 27092c2af02d1f54d108a4d7159e6edcbb245ae0
Author: jpc 
Date:   Tue Jul 6 18:51:30 2021 +0200

   Add hint about the need of Acrobat DC
---
 lib/examples/Modules/PDF_Form.lyx |   29
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: PDF Form

2021-07-02 Thread Jean-Pierre Chrétien

Le 02/07/2021 à 12:40, Dr Eberhard Lisse a écrit :

Jean-Pierre

I just use the 'PDF Form' Module (which requires/loads hyperref) and the

 Insert->Custom Insets

offers a number of choices such as

 TextField.

Then you can put stuff like

 width=9cm, charsize=9pt, bordercolor={0.94 0.97 1.0},
 backgroundcolor={0.94 0.97 1.0}, name=company


That seems to work in any PDF Viewer, Preview and Skim on the Mac.


Hello Eberhard,

OK, but my concern was with the JS dynamic forms described in section 5 of the
PDF-Form.lyx manual of the examples directory.

Could you confirm that the forms display correctly in this section and 
specifically that
 - if you select "unlimited" in the radio button combo box, the "From" and 
"Until" fields disappear;
 - if you type in a A in the bottom field, you get a warning (the field id 
dedicated to numbers).


You must have insdljs.sty installed (that is package acrotex).

--
Thanks for your reply
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


PDF Form

2021-07-01 Thread Jean-Pierre Chrétien

Dear Developers

A French user draw my attention on the fact that the dynamic forms documented in 
section 5 of the PDF_Form.lyx manual (in examples/Modules) did not work as 
described.


After installing insdljs.sty, I could display the examples in the output. It 
took me a while to understand that they would only work with acroread, which is 
not available in Linux since 2013 (I tried Okular first). I was able to install 
this last version on my Linux box: the checkNumber function works and the radio 
button displays correctly, but the forms do not disappear when I check "unlimited".


I'm going to document the need for Acrobat DC in the lyx file, but I would like 
to know if the forms disappear in that case. Is it the case for any of you ? If 
not, I will ask on the users' list.


--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [LyX/master] Revert "Fix bug #10263"

2021-06-14 Thread Jean-Pierre Chrétien

Le 13/06/2021 à 18:33, Kornel Benko a écrit :

Am Sun, 13 Jun 2021 11:42:59 -0400
schrieb Scott Kostyshak :


On Sat, May 29, 2021 at 01:47:41PM -0400, Scott Kostyshak wrote:

On Fri, May 28, 2021 at 10:48:51AM -0400, Scott Kostyshak wrote:

On Tue, Apr 13, 2021 at 10:13:16AM +0200, Jean-Marc Lasgouttes wrote:

commit 441c6a93590698c3c57982c8b80179d6809fb106
Author: Jean-Marc Lasgouttes 
Date:   Mon Apr 12 20:44:58 2021 +0200

 Revert "Fix bug #10263"
 
 A series of commits, culminating at 812ff7de, pushed a few days later,

 fixes the bug at its root. This one is not needed anymore to fix
 
 This reverts commit 001f5a47861f04c985323677dfd17ef15b8c33a7

---
  src/insets/InsetFoot.h |4 
  1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/src/insets/InsetFoot.h b/src/insets/InsetFoot.h
index 1e4b0d2..0c3f65a 100644
--- a/src/insets/InsetFoot.h
+++ b/src/insets/InsetFoot.h
@@ -45,10 +45,6 @@ private:
///
Inset * clone() const override { return new InsetFoot(*this); }
///
-   bool inheritFont() const override { return true; }
-   ///
-   bool allowMultiPar() const override { return true; }
-   ///
docstring custom_label_;
///
bool intitle_;
--


The following ctest started failing with this commit:

   export/doc/ja/Tutorial_pdf5_systemF

The diff between the "bad" (current master) and "good" (current master
with this commit reverted) is as follows:

$ diff good.tex bad.tex
61c61
< \author{\LyX
プロジェクトチーム\thanks{なにかコメントや間違いの修正がある場合には,\protect\LyX
文書化メーリングリスト(\protect\href{mailto:lyx-d...@lists.lyx.org}{lyx-d...@lists.lyx.org})までお知らせ下さい.この文書の翻訳は,当初人見光太郎氏が行った貢献に基づいています.}}
---

\author{\LyX プロジェクトチーム\thanks{{\normalsize
なにかコメントや間違いの修正がある場合には,\protect\LyX
文書化メーリングリスト(\protect\href{mailto:lyx-d...@lists.lyx.org}{lyx-d...@lists.lyx.org})までお知らせ下さい.この文書の翻訳は,当初人見光太郎氏が行った貢献に基づいています.}}}

$

I have no idea why the {\normalsize ...} would cause the failure. Does
anyone know the problem?

Note that we are already aware of several other Japanese documents that
do not compile with non-TeX fonts:

   export/doc/ja/(Additional|LaTeXConfig|Math|UserGuide).*_systemF

so it would not be surprising if we need to add Tutorial.lyx to the list.

By the way, if this report does not lead to a fix in LyX or a bug
report, we should log this wasted time in
development/autotests/ctests-costs-benefits.txt.


I think the French Powerdot example might also have a footnote where
this commit changes behavior. If I remove the footnote, compilation
succeeds. I did not do a bisect on that document but it feels like a
similar issue.


Does anyone know what the core issue is? Here is the LaTeX code causing
the problem after this commit:

\thanks{{\normalsize Traduction française Jean-Pierre
Chrétien, }{\normalsize\texttt{}}}{\normalsize}, 
novembre
2009.}}}

Do we need to adapt lyx2lyx perhaps? Or is this a LyX LaTeX export
issue?

Scott


This compiles also if changing the font inside the footnote (Teletype->default)


Hello

The French Powerdot file was a mess because the Footnote which gives info about 
the translator exported to LaTeX as \thanks, splitting the content in two pieces 
and leaving spurious parentheses at the end.


I dissolved the Footnote inset and made the content a LyX note, compiles fine 
now.

Committed at 5b0b3f053e

--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: ctests for French User Guide are failing

2021-05-30 Thread Jean-Pierre Chrétien

Le 28/05/2021 à 14:24, Scott Kostyshak a écrit :

On Fri, May 28, 2021 at 08:51:08AM +0200, Jean-Pierre Chrétien wrote:

Le 28/05/2021 à 02:14, Scott Kostyshak a écrit :

The following ctests for the French User Guide on current master are failing 
for me:

export/doc/fr/UserGuide_lyx22 (Failed)
export/doc/fr/UserGuide_lyx23 (Failed)
export/doc/fr/UserGuide_dvi (Failed)
export/doc/fr/UserGuide_dvi3_texF (Failed)
export/doc/fr/UserGuide_pdf (Failed)
DEFAULTOUTPUT_export/doc/fr/UserGuide_pdf2 (Failed)
export/doc/fr/UserGuide_pdf3 (Failed)
export/doc/fr/UserGuide_pdf5_texF (Failed)


Should be fixed now.


Works well. Thanks for the quick fix, Jean-Pierre!


The error that made the tests fail is quite peculiar. I copied the new escape 
sequences at the end of section 6.8.1 from the English UserGuide without marking 
it as French, and I got this error:


! Paragraph ended before \bbl@foreign@x was complete.

When I look at the code, I do not see any missing parenthesis.

eux\foreignlanguage{english}{.\nomenclature{%@, %|, %!, %"}{The quote sign in 
TeX code is output by writing ' %"{}%"{} '.}}


The error disappears when I mark the index entry as French, and the new code is:

.\nomenclature{%@, %|, %!, %"}{The quote sign in TeX code is output by writing ' 
%"{}%"{} '.}


Could this be a hidden bug affecting language embedding of index entries?
I'll try to build a MWE.

--
Jean-Pierre




--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: ctests for French User Guide are failing

2021-05-28 Thread Jean-Pierre Chrétien

Le 28/05/2021 à 02:14, Scott Kostyshak a écrit :

The following ctests for the French User Guide on current master are failing 
for me:

   export/doc/fr/UserGuide_lyx22 (Failed)
   export/doc/fr/UserGuide_lyx23 (Failed)
   export/doc/fr/UserGuide_dvi (Failed)
   export/doc/fr/UserGuide_dvi3_texF (Failed)
   export/doc/fr/UserGuide_pdf (Failed)
   DEFAULTOUTPUT_export/doc/fr/UserGuide_pdf2 (Failed)
   export/doc/fr/UserGuide_pdf3 (Failed)
   export/doc/fr/UserGuide_pdf5_texF (Failed)


Should be fixed now.

--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Dynamic insets

2021-05-18 Thread Jean-Pierre Chrétien

Le 18/05/2021 à 07:52, Jürgen Spitzmüller a écrit :

Am Montag, dem 17.05.2021 um 16:07 +0200 schrieb Jean-Pierre Chrétien:





Finally, it seems that not all menu entries appear in dynamic insets.
What are exactly those which are liable to do so (the list in the
inset parameters is not very explicit)? And is it done everywhere
where it can be in the English docs?
If not, is this a target to achieve?


Probably all should use info insets.


Is it correct to state that all the recognised strings are given in the LFUNS 
mùanual, under 'dialog-show' ?





As a conclusion, where is the dynamic inset feature documented? I do
not remember to have translated it.


User Guide A.4.4


Thanks, indeed, it needs to be translated in French.

--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Dynamic insets

2021-05-17 Thread Jean-Pierre Chrétien

Dear Developers

Following a discussion on lyx-docs about the Text Style menu, I g=have a couple 
of questions about the dynamic insets feature.


First of all, the advantages of such a feature, as far as menus are concerned, 
is twofold:
 A/ the menu names appears translated in the UI language when the reader opens 
a manual;

 B/ any change in the po file is corrected automagically in the docs.

Initially I thought that the translation in the language of the UI should not 
appear in the pdf export, but I understood that it was easy to create a PDF in 
English by changing the locale before calling LyX.


Then I wondered if the UI should be dynamic in the translated manuals, as a 
reader of the e.g. French manual will have the UI in French. But feature B 
remains an incentive to keep it dynamic there also. I'm not sure to have it a 
all places, I will check that.


Finally, it seems that not all menu entries appear in dynamic insets. What are 
exactly those which are liable to do so (the list in the inset parameters is not 
very explicit)? And is it done everywhere where it can be in the English docs? 
If not, is this a target to achieve?


As a conclusion, where is the dynamic inset feature documented? I do not 
remember to have translated it.


--
Regards
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Clipboard

2021-05-05 Thread Jean-Pierre Chrétien

Le 04/05/2021 à 18:36, Scott Kostyshak a écrit :

On Tue, May 04, 2021 at 06:31:43PM +0200, Jean-Pierre Chrétien wrote:

Le 04/05/2021 à 15:17, Kornel Benko a écrit :

Am Tue, 4 May 2021 14:14:47 +0200
schrieb Jean-Pierre Chrétien :


Le 14/04/2021 à 18:49, Scott Kostyshak a écrit :



In that case, it could be that the fix referenced above actually made
things worse for you. You could try to revert the commit 7a158055 on the
2.3.x branch and see if that makes the terminal message go away for you.
If you do that, please let me know if it helps things because that means
we should fix something.


[...]


However, it turns out that I reverted globally instead of locally, sorry.


No problem, we've all done that before.


I guess I should have simply patched the local files, right? Or is there a git 
command to revert locally only?


The clipboard message is still there, but I got this message when starting LyX:

$ invoking IsSupported() failed for remote volume monitor with dbus name 
org.gtk.vfs.UDisks2VolumeMonitor:: Le délai d’attente est dépassé 
(g-io-error-quark, 24)


So I will come back to lyx-2.4.0 with your patches...

--
Jean-Pierre



--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Clipboard

2021-05-04 Thread Jean-Pierre Chrétien

Le 04/05/2021 à 15:17, Kornel Benko a écrit :

Am Tue, 4 May 2021 14:14:47 +0200
schrieb Jean-Pierre Chrétien :


Le 14/04/2021 à 18:49, Scott Kostyshak a écrit :



In that case, it could be that the fix referenced above actually made
things worse for you. You could try to revert the commit 7a158055 on the
2.3.x branch and see if that makes the terminal message go away for you.
If you do that, please let me know if it helps things because that means
we should fix something.


Hello SCott

In fact, I get the message also with master while working on the French docs:
.
frontends/qt/GuiClipboard.cpp (92): No timely response from clipboard, perhaps
process holding clipboard is frozen?

What is the commit to revert on master ?



commit 7a158055fe6c05763f88ddb61a9c02b42614091d
Author: Scott Kostyshak 
Date:   Fri Mar 27 21:23:08 2020 -0400
...
 (cherry picked from commit af4ee1a487c4d899b71df02ba57c2f024fea6786)
 (cherry picked from commit 23abb5aaa36af07aadfa5e565869104778ba0d6d)

Got this by 'git show 7a158055'.


Thanks for the info and the hint, Kornel.

However, it turns out that I reverted globaélly instead of locally, sorry.

What shoulsd I do to restore the commits in the master repo?

--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Clipboard

2021-05-04 Thread Jean-Pierre Chrétien

Le 14/04/2021 à 18:49, Scott Kostyshak a écrit :



In that case, it could be that the fix referenced above actually made
things worse for you. You could try to revert the commit 7a158055 on the
2.3.x branch and see if that makes the terminal message go away for you.
If you do that, please let me know if it helps things because that means
we should fix something.


Hello SCott

In fact, I get the message also with master while working on the French docs:
.
frontends/qt/GuiClipboard.cpp (92): No timely response from clipboard, perhaps 
process holding clipboard is frozen?


What is the commit to revert on master ?

--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Clipboard

2021-04-14 Thread Jean-Pierre Chrétien

Le 13/04/2021 à 19:58, Scott Kostyshak a écrit :

On Tue, Apr 13, 2021 at 06:35:22PM +0200, Jean-Pierre Chrétien wrote:

Dear Developers

While working with lyx-2.3.7dev compiled with QT5.11.3, I see this in the 
terminal :

$ frontends/qt4/GuiClipboard.cpp (92): No timely response from clipboard,
perhaps process holding clipboard is frozen?

I see it when I come back to the terminal window, so I do not know when it 
happens.

Any clue?


Do you use a clipboard manager? If so, which one? I use CopyQ and I
often see that message in the terminal. I think it's also related that
sometimes I select something in LyX and the selection is broken. Does
this ever happen to you? It is much better in my experience after the
fix for #11715 (which is in the version of LyX you're using) but I still
see it sometimes.


Hello SCott,

No I don't use a clipboard manager.
What puzzles me is that the message mentions Qt4...



If you don't use a clipboard manager, then I'm not sure. LyX does some
tricks regarding the clipboard because it does not want to constantly
export code whenever the selection changes (that would be expensive), so
it tries to wait until an application requests the selection.


Sure, but it is the first time I see this message. Of course, I do not use any 
more LyX to produce documents as I used to do before I retired.

I'll keep an aye on my terminal.

--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Clipboard

2021-04-13 Thread Jean-Pierre Chrétien

Dear Developers

While working with lyx-2.3.7dev compiled with QT5.11.3, I see this in the 
terminal :

$ frontends/qt4/GuiClipboard.cpp (92): No timely response from clipboard, 
perhaps process holding clipboard is frozen?


I see it when I come back to the terminal window, so I do not know when it 
happens.

Any clue?

--
Jean-Pierre


--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Wayland

2021-03-31 Thread Jean-Pierre Chrétien

Le 31/03/2021 à 17:12, Jean-Marc Lasgouttes a écrit :

Le 29/03/2021 à 15:38, Jean-Pierre Chrétien a écrit :

Le 29/03/2021 à 11:00, Jean-Marc Lasgouttes a écrit :

What happens if you do what they say? I see the same with Ubuntu.


$ export QT_QPA_PLATFORM=wayland
$ lyx-2.3.7dev
Using Wayland-EGL
Using the 'xdg-shell-v6' shell integration

And the window fonts are very small, the header is blue and the shortcut 
symbols for the control of the window are unreadable (and in fact only closing 
is functional).


Could you try some other Qt applications in wayland mode to see whether the 
problem is wayland configuration in debian or LyX itself?


I do not see any difference with VLC of FileZilla, seems to be LyX-related.
i see there are other wayland plugins, should I test them ?



I guess now you know why LyX runs in X mode by default under wayland :)


Sure.

--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Wayland

2021-03-29 Thread Jean-Pierre Chrétien

Le 29/03/2021 à 10:22, Jean-Pierre Chrétien a écrit :

Dear developers

With master git print 779f0a74, I get this when I start Lyx :

Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland 
to run on Wayland anyway.


Debian Buster Gnome Wayland, indeed.



Same message with branch.

--
Jean-Pierre
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Wayland

2021-03-29 Thread Jean-Pierre Chrétien

Dear developers

With master git print 779f0a74, I get this when I start Lyx :

Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland 
to run on Wayland anyway.


Debina Buster Gnome Wayland, indeed.

--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: LyX compilation fails after reinstalling OS

2021-03-13 Thread Jean-Pierre Chrétien

Le 12/03/2021 à 18:17, Pavel Sanda a écrit :

On Fri, Mar 12, 2021 at 06:12:18PM +0100, Jean-Pierre Chrétien wrote:

Dear developers

I had to reinstall my Debian buster after a big mistake while using rsync.

Now here is what I get when I run the config command in the build dir:

../master/configure --with-version-suffix --with-included-hunspell


checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for QT_CORE... yes
checking for QT_FRONTEND... checking for X... libraries , headers
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... no
checking for Qt library name... failed, retrying with Qt4
checking for QT_CORE... yes
Package QtCore was not found in the pkg-config search path.
Perhaps you should add the directory containing `QtCore.pc'
to the PKG_CONFIG_PATH environment variable
No package 'QtCore' found
Package QtCore was not found in the pkg-config search path.
Perhaps you should add the directory containing `QtCore.pc'
to the PKG_CONFIG_PATH environment variable
No package 'QtCore' found
checking for QT_FRONTEND... checking for X... libraries , headers
checking for gethostbyname... (cached) yes
checking for connect... (cached) yes
checking for remove... (cached) yes
checking for shmat... (cached) yes
checking for IceConnectionNumber in -lICE... (cached) no
checking for Qt library name... (cached) failed
configure: error: cannot compile a simple Qt executable. Check you have the
right $QTDIR.


Looking in the log for what causes the
"checking for Qt library name... failed", I see :

configure:10708: checking for Qt library name
configure:10747: g++ -o conftest  -I/usr/lib/x86_64-linux-gnu/qt5/include -I/usr
/lib/x86_64-linux-gnu/qt5/include/Qt -I/usr/lib/x86_64-linux-gnu/qt5/include/QtC
ore -I/usr/lib/x86_64-linux-gnu/qt5/include/QtGui -I/usr/lib/x86_64-linux-gnu/qt
5/include/QtWidgets -I/usr/lib/x86_64-linux-gnu/qt5/include/QtSvg -I/usr/lib/x86
_64-linux-gnu/qt5/include/QtConcurrent -I/usr/lib/x86_64-linux-gnu/qt5/include/Q
tMacExtras -L/usr/lib/x86_64-linux-gnu/qt5/lib conftest.cpp-lX11  -lQt5C
ore >&5
conftest.cpp:36:11: fatal error: qglobal.h: No such file or directory
   #include 


When I look at the contents of the qt5 dir, I see this :

$ ls /usr/lib/x86_64-linux-gnu/qt5/
bin  libexec  mkspecs  plugins  qml  qt.conf

No include there, I must have missed some qt5 package when I reinstalled. So
in which qt5 package are the includes located ?

Sorry for the lengthy mail, and thanks for your help.


Did you run debian's
apt-get build-dep lyx
before compiling?


Here is what apt-get installs:

$ sudo apt-get build-dep lyx
[snip]
Les NOUVEAUX paquets suivants seront installés :
  dh-python libboost-dev libboost-filesystem-dev libboost-filesystem1.67-dev
  libboost-iostreams-dev libboost-iostreams1.67-dev libboost-regex-dev
  libboost-regex1.67-dev libboost-signals-dev libboost-signals1.67-dev
  libboost-signals1.67.0 libboost-system1.67-dev libboost-test-dev
  libboost-test1.67-dev libboost-test1.67.0 libboost-timer1.67.0
  libboost1.67-dev libenchant-dev libmagic-dev libmythes-dev libqt5svg5-dev

So the boost libs were missing. I can compile all right now, thanks a lot.


Let's continue discussion on lyx-devel this really does not belong to this
list.


Sure, sorry.

--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Insert menu

2021-01-26 Thread Jean-Pierre Chrétien

Le 26/01/2021 à 09:37, José Abílio Matos a écrit :

One striking example for me is the case of Portuguese books where the TOC was 
placed at the end. The idea is that in this case you can interpret the TOC as 
some kind of index. Actually it even received the name of index while the index 
was called "remissive index".



Personally I do not like because when I go to a book I like to see the structure 
of the book and the TOC conveys that.



Nowadays most book in Portuguese have the TOC at front but I can see a different 
interpretation to have it at the end.


In French, the TOC is usually in the endmatter.

--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Page Break vs New Page

2021-01-25 Thread Jean-Pierre Chrétien

Le 25/01/2021 à 10:59, Jean-Marc Lasgouttes a écrit :

Le 25/01/2021 à 10:43, Jean-Pierre Chrétien a écrit :

Le 25/01/2021 à 10:29, Jean-Marc Lasgouttes a écrit :
« fer à gauche » means that the characters are stacked from the left limit, 
i.e left alignment

« fer en haut » means that the characters are stacked from the upper limit

https://fr.wikipedia.org/wiki/Justification_(typographie)

Obviously, the page does not exist in English.


Why not? Don't they do typography too?


Sure, under a different name:

 https://en.wikipedia.org/wiki/Typographic_alignment

But this one does not say a word about vertical justification either.





What about
« aligné à gauche » instead of « fer à gauche »
« calé en haut de page » instead of « fer en haut »


I do not see the reference to "en haut" in te*he wikipedia page. This is the 
part I do not really get.


I'm sure I found it when I looked for a translation of the terms  newpage, 
pagebreak, etc.
I guess thet English-speaking people have understood that translators in other 
languages had to find something explicit to translate these words.

Shouldn't we continue this discussion on lyx-fr ?

--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Page Break vs New Page

2021-01-25 Thread Jean-Pierre Chrétien

Le 25/01/2021 à 10:29, Jean-Marc Lasgouttes a écrit :



But the problem with "adequate French typographical expressions" is that I can 
never figure out what "fer en haut" might mean.


A bit confusing I admit and difficult to explain in English. « fer » is the 
limit of the frame inside which typographers used to stack characters. So


« fer à gauche » means that the characters are stacked from the left limit, i.e 
left alignment

« fer en haut » means that the characters are stacked from the upper limit

https://fr.wikipedia.org/wiki/Justification_(typographie)

Obviously, the page does not exist in English.

What about
« aligné à gauche » instead of « fer à gauche »
« calé en haut de page » instead of « fer en haut »

--
Jean-Pierre



--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Page Break vs New Page

2021-01-25 Thread Jean-Pierre Chrétien

Le 25/01/2021 à 09:58, Jean-Pierre Chrétien a écrit :
.


Right, I have had for a long time translations which use adequate French 
typographical expressions


Page Break    as Saut de page (fer en haut)
New Page  as Saut de page (justifié)
Clear Page    as Saut de page (vide le tampon)
Clear Double Page as Saut de page impaire



That was for 2.3, I see that I will need to add

No Page Break   as Saut de page interdit

in 2.4.0

--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Page Break vs New Page

2021-01-25 Thread Jean-Pierre Chrétien

Le 24/01/2021 à 18:36, Richard Kimberly Heck a écrit :

Over on lyx-users, we got a question that uncovered the fact that these
names are not very descriptive. (The user had used Page Break and gotten
surprising results: a very stretched Table of Contents.) The line breaks
have more descriptive names. Is there something else we could use for
Page Break that would indicate what it does? Something like "Page Break
(Stretch Page)" would work, but is kind of long


Right, I have had for a long time translations which use adequate French 
typographical expressions


Page Breakas Saut de page (fer en haut)
New Page  as Saut de page (justifié)
Clear Pageas Saut de page (vide le tampon)
Clear Double Page as Saut de page impaire

--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Update docs on the wiki

2021-01-16 Thread Jean-Pierre Chrétien

Le 16/01/2021 à 02:26, Richard Kimberly Heck a écrit :

On Fri, Jan 15, 2021 at 06:34:08PM +0100, Jean-Pierre Chrétien wrote:

There is nothing about Japanese, and I'm unable to compile the Japanese
documentation. Anybody knows why Uwe did not include these manuals?


Maybe send an email to Koji? yoko...@gmail.com


Done

--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Update docs on the wiki

2021-01-15 Thread Jean-Pierre Chrétien

Le 14/01/2021 à 14:00, Jean-Pierre Chrétien a écrit :

Hello,

I'm about to update the docs on the wiki. Could someone give me privately the 
identity and password to connect to ftp://wiki.lyx.org ?




The files were at ftp.lyx.de, I uploaded my files on the wiki, in directory 
LyX/Manuals/2.3


The wiki Manuals directory reads like this now:

https://wiki.lyx.org/LyX/Manuals

I'll create a section about Additional manuals later.

There is nothing about Japanese, and I'm unable to compile the Japanese 
documentation. Anybody knows why Uwe did not include these manuals?


The section about 'Maintaining' is also out of date, what should be there?

--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Update docs on the wiki

2021-01-14 Thread Jean-Pierre Chrétien

Hello,

I'm about to update the docs on the wiki. Could someone give me privately the 
identity and password to connect to ftp://wiki.lyx.org ?


--
Thanks and regards
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: What Localized Manuals Are Maintained?

2021-01-13 Thread Jean-Pierre Chrétien

Le 13/01/2021 à 10:11, Yuriy Skalko a écrit :
> Before I send a note asking for help with the copy-paste stuff, what 
localized manuals are currently maintained? I.e., for which languages do we 
need to copy over the new and changed material?


As I said yesterday, manuals other than Intro and Tutorial are localized in 
French, German, Japanese ans Spanish.



There are also newly introduced manuals in Russian. But they are already 
prepared for LyX 2.4, so no need to copy over any material.


Yes, I should have mentioned that my concern was about 2.3, following the 
discussion during the meeting on Monday.


--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: What Localized Manuals Are Maintained?

2021-01-12 Thread Jean-Pierre Chrétien

Le 11/01/2021 à 18:52, Richard Kimberly Heck a écrit :
Before I send a note asking for help with the copy-paste stuff, what localized 
manuals are currently maintained? I.e., for which languages do we need to copy 
over the new and changed material?




As I said yesterday, manuals other than Intro and Tutorial are localized in 
French, German, Japanese ans Spanish.


There are translations of specific manuals in these languages as well.

I posted a record of the 2.3 translation status in French on lyx-docs :

https://www.mail-archive.com/lyx-docs@lists.lyx.org/msg09668.html

I committed the final version of Customization since. I really would like to 
translate Jürgen's sections about biblatex in the UserGuide before 2.3.7, can 
you give me an idea of the deadline ?

A couple of months maybe ?

As for the other languages, I'm pretty confident that German manuals are up to 
date as Jürgen writes down the German version of the changes first. I can 
contact Ignacio Garcia for Spanish and Koji Yokota for Japanese to ask about the 
status of their translations.


--
Jean-Pierre


--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Markdown to Lyx

2020-12-14 Thread Jean-Pierre Chrétien

Le 14/12/2020 à 18:04, Richard Kimberly Heck a écrit :

On 12/14/20 12:27 AM, Murat Yildizoglu wrote:

Hello,

I have now created the WiKi
page: https://wiki.lyx.org/Tips/ConvertMarkdown



Nice work, but IMHO the section titles have been inverted, the first one is 
about 'From Markdown to LyX', while the second one is 'From LyX to Markdown'.


--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Warning while compiling 2.3.6

2020-12-09 Thread Jean-Pierre Chrétien

Dear developers

I just compiled 2.3.6 today.

I see this, whic is harmless I guess.


1.2.5/mythes.cxx: In member function ‘int MyThes::Lookup(const char*, int, 
mentry**)’:
1.2.5/mythes.cxx:247:25: warning: ‘char* strncpy(char*, const char*, size_t)’ 
specified bound depends on the length of the source argument [-Wstringop-overflow=]

  strncpy(dfn,pos,k);
  ~~~^~~
1.2.5/mythes.cxx:244:27: note: length computed here
 int k = strlen(pos);
 ~~^
>/cite>

Debian Buster
Configuration
  Host type:   x86_64-pc-linux-gnu
  Special build flags:  build=release std-regex use-hunspell
  Bundled libraries:boost hunspell mythes
  C++ Compiler:g++ (8.3.0)
  C++ Compiler flags:   -fPIC -O2 -std=c++14
  C++ Compiler user flags:
  Linker flags:
  Linker user flags:
  Qt Frontend:
  Qt version:  5.11.3
  Packaging:   posix
  LyX binary dir:  /usr/local/bin
  LyX files dir:   /usr/local/share/lyx-2.3.6

--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Warnings while compiling branch

2020-11-02 Thread Jean-Pierre Chrétien

Dear developers

While compiling the latest branch with this config

Configuration
  Host type:   x86_64-pc-linux-gnu
  Special build flags:  build=development std-regex warnings assertions 
stdlib-debug use-hunspell

  Bundled libraries:boost hunspell mythes
  C++ Compiler:g++ (8.3.0)
  C++ Compiler flags:   -Wall -Wextra -fPIC -g -O -std=c++14
  C++ Compiler user flags:
  Linker flags:
  Linker user flags:
  Qt Frontend:
  Qt version:  5.11.3
  Packaging:   posix
  LyX binary dir:  /usr/local/bin
  LyX files dir:   /usr/local/share/lyx-2.3.6dev


I see this :

../../../2.3.x/3rdparty/hunspell/1.6.2/src/hunspell/hunspell.cxx: In member 
function ‘bool HunspellImpl::spell(const string&, int*, std::__cxx11::string*)’:
../../../2.3.x/3rdparty/hunspell/1.6.2/src/hunspell/hunspell.cxx:562:7: warning: 
this statement may fall through [-Wimplicit-fallthrough=]

   }
   ^
../../../2.3.x/3rdparty/hunspell/1.6.2/src/hunspell/hunspell.cxx:564:5: note: 
here
 case INITCAP: {
 ^~~~
../../../2.3.x/3rdparty/hunspell/1.6.2/src/hunspell/hunspell.cxx: In member 
function ‘std::__debug::vector > 
HunspellImpl::suggest(const string&)’:
../../../2.3.x/3rdparty/hunspell/1.6.2/src/hunspell/hunspell.cxx:900:16: 
warning: this statement may fall through [-Wimplicit-fallthrough=]

   capwords = 1;
   ~^~~
../../../2.3.x/3rdparty/hunspell/1.6.
/src/hunspell/hunspell.cxx:901:5: note: here
 case HUHCAP: {
 ^~~~
../../../2.3.x/3rdparty/hunspell/1.6.2/src/hunspell/hunspell.cxx:1012:18: 
warning: this statement may fall through [-Wimplicit-fallthrough=]

 capwords = 1;
 ~^~~
../../../2.3.x/3rdparty/hunspell/1.6.2/src/hunspell/hunspell.cxx:1013:7: note: 
here
   case HUHCAP: {
   ^~~~
../../../2.3.x/3rdparty/hunspell/1.6.2/src/parsers/manparser.cxx: In member 
function ‘virtual bool ManParser::next_token(std::__cxx11::string&)’:
../../../2.3.x/3rdparty/hunspell/1.6.2/src/parsers/manparser.cxx:72:17: warning: 
this statement may fall through [-Wimplicit-fallthrough=]

   state = 2;
   ~~^~~
../../../2.3.x/3rdparty/hunspell/1.6.2/src/parsers/manparser.cxx:75:7: note: 
here
   case 2:  // non word chars

I guess this is harmless.

--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: LyX Development Release Tarballs, Round 3

2020-10-29 Thread Jean-Pierre Chrétien

Le 29/10/2020 à 01:26, Richard Kimberly Heck a écrit :

On 10/28/20 8:15 PM, Jean-Pierre wrote:

Le 26 octobre 2020 21:57:09 Richard Kimberly Heck  a
écrit :


OK, so, another set of tarballs is at
http://ftp.lyx.org/ftp/pub/lyx/devel/lyx-2.4/. Please let me know if
that these are good to go (hopefully).


Hello Riki

Signature OK this time.
Up to now, I just ran configure, and I see that the version name is
lyx-2.4.0dev, that is the same as the one I retrieve with git to check
master.
Would not it read lyx-2.4.0alpha ?


I wasn't officially releasing it as an alpha and won't announce it that
way. We had not, so far as I am aware, made any official determination
about that (although Pavel suggested it). So, for now, it'll be
announced as a 'testing release'. If all goes well with it, maybe we can
do a real alpha in November.


OK.
BTW, compilation worked all right with this conf :

Configuration
  Host type:   x86_64-pc-linux-gnu
  Special build flags:  build=development std-regex warnings assertions 
stdlib-debug callback-printing use-hunspell

  Bundled libraries:boost hunspell mythes
  C++ Compiler:g++ (8.3.0)
  C++ Compiler flags:   -Wall -Wextra -fPIC -g -O -std=c++14 
-Wno-deprecated-copy

  C++ Compiler user flags:
  Linker flags: -rdynamic
  Linker user flags:
  Qt Frontend:
  Qt version:  5.11.3
  Packaging:   posix
  LyX binary dir:  /usr/local/bin
  LyX files dir:   /usr/local/share/lyx-2.4.0dev

on Debian buster.

UserGuide compiles fine.

--
Jean-Pierre


--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: LyX Development Release Tarballs, Round 2

2020-10-25 Thread Jean-Pierre Chrétien

Le 25/10/2020 à 16:54, Richard Kimberly Heck a écrit :

So, new tarballs at http://ftp.lyx.org/ftp/pub/lyx/devel/lyx-2.4/.
Probably people should hold off on building binaries until we get
confirmation that these are OK.

Layouts updated and some missing files included


Hello Riki

Signature fails :
 gpg --verify lyx-2.4.0dev-bd142885.tar.xz.sig
gpg: les données signées sont supposées être dans « 
lyx-2.4.0dev-bd142885.tar.xz »
gpg: Signature faite le dim. 25 oct. 2020 16:49:23 CET
gpg:avec la clef RSA FE66471B43559707AFDAD955DE7A44FAC7FB382D
gpg: MAUVAISE signature de « LyX Release Manager (Signing LyX tarballs and 
binaries)  » [inconnu]


--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: r41260 - www-user/trunk/farm/cookbook/LyX

2020-09-18 Thread Jean-Pierre Chrétien

Le 18/09/2020 à 17:34, Pavel Sanda a écrit :

On Fri, Sep 18, 2020 at 11:27:24AM -0400, Richard Kimberly Heck wrote:

I've reverted it for now. I'm not sure what's wrong.


Remerged with python2 for now. P



Works fine now.

--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: r41260 - www-user/trunk/farm/cookbook/LyX

2020-09-18 Thread Jean-Pierre Chrétien

Le 18/09/2020 à 16:39, rgh...@lyx.org a écrit :

Author: rgheck
Date: Fri Sep 18 16:39:19 2020
New Revision: 41260
URL: http://www.lyx.org/trac/changeset/41260

Log:
* i18n.inc: update stats

Modified:
www-user/trunk/farm/cookbook/LyX/i18n.inc


Hello Riki

There is something wrong :

Warning: usort() expects parameter 1 to be array, null given in 
/home/lyx/www/www-user/farm/cookbook/LyX/i18n.php on line 58 Warning: Variable 
passed to each() is not an array or object in 
/home/lyx/www/www-user/farm/cookbook/LyX/i18n.php on line 104


--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Change trackibg with master

2020-08-21 Thread Jean-Pierre Chrétien

Le 20/08/2020 à 17:03, Richard Kimberly Heck a écrit :

On 8/20/20 11:00 AM, Jean-Pierre Chrétien wrote:

Dear developers,

While browsing a comparison of files using master, I find that the
'Next change' function stays stuck on a word in sans-serif font. I
have to put the cursor after the word to be able to go on.

Can you reproduce ?


Can you see if you can get a minimal example?


Sorry, I tried a simple example, but CT works fine there. It happened in a 
rather complicated differences document between versions of a manual, that I am 
currently unable to reproduce.


I will have to make other differences in the future, I will keep my eyes open.

--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Change trackibg with master

2020-08-20 Thread Jean-Pierre Chrétien

Le 20/08/2020 à 17:03, Richard Kimberly Heck a écrit :

On 8/20/20 11:00 AM, Jean-Pierre Chrétien wrote:

Dear developers,

While browsing a comparison of files using master, I find that the
'Next change' function stays stuck on a word in sans-serif font. I
have to put the cursor after the word to be able to go on.

Can you reproduce ?


Can you see if you can get a minimal example?


Sure, I just recompile lyx-2.4.0dev to check with the very last version.

--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Change trackibg with master

2020-08-20 Thread Jean-Pierre Chrétien

Dear developers,

While browsing a comparison of files using master, I find that the 'Next change' 
function stays stuck on a word in sans-serif font. I have to put the cursor 
after the word to be able to go on.


Can you reproduce ?

--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Windows installation over an exiating version

2020-07-07 Thread Jean-Pierre Chrétien

Dear developers,

A recent exchange on the lyx-fr list pointed out the fact that
 * installing 2.3.5 without removing 2.3.4 creates all right a 2.3.5 registry 
entry;

 * however the 2.3.4 registry entry is still there, but does not point on 
anything;
 * desinstalling 2.3.4 removes 2.3.5.
The only way out is to kill directly the 2.3.4 registry entry.

Can this be reproduced (I'm on Linux)?

--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [LyX/2.3.x] Translation update of French manuals, first round

2020-06-21 Thread Jean-Pierre Chrétien

Le 21/06/2020 à 09:43, Jürgen Spitzmüller a écrit :

Am Samstag, den 20.06.2020, 18:51 +0200 schrieb jpc:

commit de6bec415176415abf3158981de22f710a7e121f

Author: jpc 

Date:   Sat Jun 20 19:13:06 2020 +0200



Translation update of French manuals, first round



You are aware that this deleted the French UG from the repo?


Sure, I've seen it, I will restore it.

--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [ANNOUNCE] LyX 2.3.5 Released

2020-06-14 Thread Jean-Pierre Chrétien

Le 13/06/2020 à 18:56, Richard Kimberly Heck a écrit :

On 6/12/20 10:44 AM, Jean-Pierre Chrétien wrote:

Le 09/06/2020 à 05:26, Daniel a écrit :

On 2020-06-07 17:49, Richard Kimberly Heck wrote:

Public release of LyX version 2.3.5
===


Hello Riki,

I do not see a record of the Franch UI update in the DOCUMENTATION AND
LOCALIZATION section.
Must I add an entry in the status file when I provide an update ?


Yes, all commits to 2.3.x (with very few exceptions) should include a
note in status.23x. And I should have caught that it was missing.


No, you've got other things to worry about, it's up to me to update status.23x 
almost once during a cycle of updates. I will do it in the future.


--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [ANNOUNCE] LyX 2.3.5 Released

2020-06-12 Thread Jean-Pierre Chrétien

Le 12/06/2020 à 16:44, Jean-Pierre Chrétien a écrit :

I do not see a record of the Franch UI update in the DOCUMENTATION AND 

   French, sorry

--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Beamer enumerations

2020-06-12 Thread Jean-Pierre Chrétien

Dear developers

I had a question on the French list about the following problem : with Beamer, 
enumerated subitems are numbered alike main items:


1 item
2 item
  1 subitem
  2 subitem
3 item

The solution is to add a command in the preamble to redefine subitem numbering 
style. I added it to the wiki :


https://wiki.lyx.org/Tips/Beamer#toc1

--
Jean-Pierre



--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: [ANNOUNCE] LyX 2.3.5 Released

2020-06-12 Thread Jean-Pierre Chrétien

Le 09/06/2020 à 05:26, Daniel a écrit :

On 2020-06-07 17:49, Richard Kimberly Heck wrote:

Public release of LyX version 2.3.5
===


Hello Riki,

I do not see a record of the Franch UI update in the DOCUMENTATION AND 
LOCALIZATION section.

Must I add an entry in the status file when I provide an update ?

--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: LyX 2.3.5 Tarballs, Again

2020-06-02 Thread Jean-Pierre Chrétien

Le 02/06/2020 à 05:51, Richard Kimberly Heck a écrit :

Revised tabarlls (minor packaging issues) are now at:

http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/



Compiles fine on Debian Buster (but a mythes warning already discussed) with

Configuration
  Host type:   x86_64-pc-linux-gnu
  Special build flags:  build=release std-regex use-hunspell
  Bundled libraries:boost mythes
  C++ Compiler:g++ (8.3.0)
  C++ Compiler flags:   -fPIC -O2 -std=c++14
  C++ Compiler user flags:
  Linker flags:hunspall
  Linker user flags:
  Qt Frontend:
  Qt version:  5.11.3
  Packaging:   posix
  LyX binary dir:  /usr/local/bin
  LyX files dir:   /usr/local/share/lyx-2.3.5

French UserGuide compiles fine with TL2020.

--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: LyX 2.3.5 Tarballs

2020-06-01 Thread Jean-Pierre Chrétien

Le 01/06/2020 à 20:20, Richard Kimberly Heck a écrit :

The tarballs for 2.3.5 are now here

http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/

for testing. Please prepare binaries. (Eugene, you can build new
installers for testing as well, especially the 64 bit one.)


Hello Riki

Sorry, I only see Windows stuff there:


Index of /pub/lyx/devel/lyx-2.3
[ICO]   NameLast modified   SizeDescription
[PARENTDIR] Parent Directory-   
[ ] LyX-2344-Installer-5-x32-beta1.exe  2020-03-16 04:3752M 
[ ] LyX-2344-Installer-5-x32-beta1.exe.sig  2020-03-16 04:38310 
[ ] LyX-2344-Installer-5-x64-beta1.exe  2020-03-16 04:3855M 
[ ] LyX-2344-Installer-5-x64-beta1.exe.sig  2020-03-16 04:38310 
[ ] README  2020-03-16 04:46450 
Apache/2.4.35 (Unix) OpenSSL/1.0.2k Server at ftp.lyx.org Port 80

--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Shall we drop resources ?

2020-05-15 Thread Jean-Pierre Chrétien

Le 15/05/2020 à 16:20, Jean-Pierre Chrétien a écrit :



I will try now with the second one (I assume that I must revert the first one). 
Should I reboot again ?




Without reboot:

if 1
#pmprof# getIcon: 1.38 ms, count=263, total=363.84 ms

#if 0
#pmprof# getIcon: 1.05 ms, count=254, total=267.29 ms

--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Shall we drop resources ?

2020-05-15 Thread Jean-Pierre Chrétien

Le 15/05/2020 à 11:10, Jean-Marc Lasgouttes a écrit :

Le 14/05/2020 à 23:40, Jean-Marc Lasgouttes a écrit :

Le 14/05/2020 à 22:29, Jean-Pierre Chrétien a écrit :
My computer uses mechanical drives all right, and runs an AMD biprocessor 
since 2009. Does it seem enough disabled for a test ? If so, what should I do 
exactly ?


Very good platform. Apply this patch (which is work in progress but should 
work) and recompile lyx in release mode.


Then reboot your computer (to avoid caching of files), run LyX, create new 
file, insert math equation (to have more icons) and exit.


Note what is output on screen.

Then in GuiApplication/iconName() and repalce the "#if 1" by "#if 0" (see in 
the patch). Recompile, repeat the same measurement.


Is this clear enough ?

Note that there are other uses of the resources in the code, I am just testing 
this particular path.


Here you are:

#if 1
$ src/lyx
#pmprof# iconName: 534.10 us, count=281, total=150.08 ms

#if 0
$ src/lyx
#pmprof# iconName: 34.87 us, count=263, total=9.17 ms




Try this one instead (do not worry, recompilation will be limited).

The difference is that is report time for getIcon (find and read icon) instead 
of iconName (find icon only).


I will try now with the second one (I assume that I must revert the first one). 
Should I reboot again ?


--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: Shall we drop resources ?

2020-05-14 Thread Jean-Pierre Chrétien

Le 14/05/2020 à 20:42, Jean-Marc Lasgouttes a écrit :

Le 14/05/2020 à 18:16, Jean-Marc Lasgouttes a écrit :
I only noticed now that Resources have been made useless just 3 days after 
there were introduced  at 33e397dff8792c.


This is the result of this thread:
https://marc.info/?l=lyx-devel=119283257516050=2

What I do not understand is why André did not complain more a the time. As it 
is now, resources are never used, since the filesystem is looked at first.


On a SSD drive (after a reboot), launching lyx creating an empty formula and 
quitting leads to the following timing for the iconName() function alone.


tanuki: src/lyx
#pmprof# iconName: 180.96 us, count=235, total=42.52 ms

If I remove the search in the file system (and thus force use of resource), I 
get:

tanuki: src/lyx
#pmprof# iconName: 13.96 us, count=234, total=3.27 ms

So, using resources is 15x faster, but the total time of 40ms is barely 
noticeable.

What would be interesting though is to try that on an older computer with 
mechanical hard drive. Is there someone with such a disabled machine ?


My computer uses mechanical drives all right, and runs an AMD biprocessor since 
2009. Does it seem enough disabled for a test ? If so, what should I do exactly ?


--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: How to Specify PDF Attachments?

2020-02-26 Thread Jean-Pierre Chrétien

Le 26/02/2020 à 18:19, Joel Kulesza a écrit :
On Wed, Feb 26, 2020 at 9:53 AM Kornel Benko > wrote:


Am Wed, 26 Feb 2020 07:45:20 -0700
schrieb Joel Kulesza mailto:jkule...@gmail.com>>:

...
 > Sorry if I'm being dense, but what do you mean by "external template"?
         Insert->File->External Material...->Template: PDF Pages


This is for inserting PDF files into PDF files, right?  I want to insert a 
text/image/etc. file into a PDF file as an electronic attachment.


In this way, a person reading the encapsulating PDF can retrieve the 
text/image/etc. in its raw form and work with it that way.


Would it be beneficial to post another example of my desired end result beyond 
what is provided in the OSTI link?


Sure, I don't understand what's wrong with a plain hyperlink.

--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: How to Specify PDF Attachments?

2020-02-26 Thread Jean-Pierre Chrétien

Le 26/02/2020 à 07:47, Joel Kulesza a écrit :

LyX Developers,

Recently, I've been making increased, and good, use of PDF attachments (e.g., 
Appendix A of this technical report: https://www.osti.gov/biblio/1574726).


I've achieved this with the `navigator` and `embedfile` packages using ERT. 
  `embedfile` is my preferred approach because it interacts better with 
`tcolorbox`, has a slightly more simple interface, and has not otherwise caused 
problems or shown a deficiency.


*Is there a way to achieve this natively in LyX?*  I have not found a way via 
menus or Help.  Sorry if I overlooked this.


*If this is not currently possible, I want to solicit your thoughts on how to 
incorporate such functionality.*  My immediate thought is by using the Insert -> 
File -> Child Document dialog with an additional checkbox to "Attach file to 
output".  This assumes that the file will be included in the document in some 
other fashion.  It is reasonable for someone to merely attach the file without 
incorporating it otherwise.  In that case, this would not be quite right.  
Further, I opt for a checkbox rather than another dropdown entry to minimize the 
number of times the file must be browsed/specified (in case it should be listed 
and attached).


I'm curious to hear your thoughts on how to proceed to achieve this 
functionality natively in LyX conveniently, intuitively, and while avoiding 
duplication of data (i.e., file paths). *Once an approach is identified, I'll 
file a ticket in the tracker and will begin coding to that end.*


In the meantime, please contact me with any comments, questions, or concerns.


My personal practice to include pdf docs is to use pdfpages, as it allows to 
keep the running headers and document page numbering and a lot of tricks.


But there is a lot of options to the package, so I guess Pavel's suggestion to 
use external material machinery is the right approach. Just adding a checkbox to 
the include/input menu will not do it.


--
Jean-Pierre

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: LyX 2.3.4 is Released

2020-02-06 Thread Jean-Pierre Chrétien

Le 06/02/2020 à 18:16, Pavel Sanda a écrit :

On Thu, Feb 06, 2020 at 06:01:26PM +0100, Enrico Forestieri wrote:

On Thu, Feb 06, 2020 at 05:46:57PM +0100, Pavel Sanda wrote:

On Thu, Feb 06, 2020 at 04:02:34PM +0100, Enrico Forestieri wrote:

On Thu, Feb 06, 2020 at 12:59:53PM +0100, Pavel Sanda wrote:

I looked at the code and the buffer length seems properly handled in the 
reported
line (247) by the previous if clause.
What is not clear to me are two following lines, which add m+1 chars while the
check seem to properly handle only m chars and leaving no place for the final' 
\0'.
Anyone else can confirm?


I think the code is correct. It copies m+1 chars in order to be sure that
the final '\0' is also copied. The fact that there is space for it is
assured by the initial check that k+m+1 < MAX_WD_LEN.


I checked the code again and you are right.
Misread < (by <=) in the initial condition.


On second thought, I instead think you are right. The code also adds
a blank after the first strncpy(dfn,pos,k), and that makes a total
of k+m+2 chars when accounting also for the final '\0'.


This is what I initially thought, but no k+m+2 is still ok because we
check against < MAX_WD_LEN-1 not <= MAX_WD_LEN-1.


I patched and recompiled, same warning  as expected from the last posts.

--
Jean-Pierre
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: LyX 2.3.4 is Released

2020-02-05 Thread Jean-Pierre Chrétien

Le 31/01/2020 à 20:46, Richard Kimberly Heck a écrit :

Public release of LyX version 2.3.4
===

We are proud to announce the release of LyX 2.3.4. This is the fourth
maintenance release in the 2.3.x series.


I got a working LyX installation where the 4 UserGuides compile fine, but I had 
a warning during compilation:



1.2.5/mythes.cxx: In member function ‘int MyThes::Lookup(const char*, int, 
mentry**)’:
1.2.5/mythes.cxx:247:25: warning: ‘char* strncpy(char*, const char*, size_t)’ 
specified bound depends on the length of the source argument [-Wstringop-overflow=]

  strncpy(dfn,pos,k);
  ~~~^~~
1.2.5/mythes.cxx:244:27: note: length computed here
 int k = strlen(pos);


Debian Buster, TL 2019,
Configuration
  Host type:   x86_64-pc-linux-gnu
  Special build flags:  build=release std-regex use-hunspell
  Bundled libraries:boost mythes
  C++ Compiler:g++ (8.3.0)
  C++ Compiler flags:   -fPIC -O2 -std=c++14
  C++ Compiler user flags:
  Linker flags:
  Linker user flags:
  Qt Frontend:
  Qt version:  5.11.3
  Packaging:   posix
  LyX binary dir:  /usr/local/bin
  LyX files dir:   /usr/local/share/lyx-2.3.4

--
Jean-Pierre





--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel


Re: LyX 2.3.3 Tarballs

2019-06-12 Thread Jean-Pierre Chrétien

Le 11/06/2019 à 18:38, Jean-Pierre Chrétien a écrit :



All common manuals compile fine with TL 2019.



and 'make check' is successful (9 tests are OK).

--
Jean-Pierre


Re: LyX 2.3.3 Tarballs

2019-06-11 Thread Jean-Pierre Chrétien

Le 10/06/2019 à 21:45, Richard Kimberly Heck a écrit :

Here:

     http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/

Please test and prepare binaries.


Compiles fine on Debian Stretch with the following configuration :

 Host type:   x86_64-pc-linux-gnu
  Special build flags:  build=release std-regex use-hunspell
  Bundled libraries:boost mythes
  C++ Compiler:g++ (6.3.0)
  C++ Compiler flags:   -fPIC -O2 -std=c++14
  C++ Compiler user flags:
  Linker flags:
  Linker user flags:
  Qt Frontend:
  Qt version:  5.7.1
  Packaging:   posix
  LyX binary dir:  /usr/local/bin
  LyX files dir:   /usr/local/share/lyx-2.3.3

All common manuals compile fine with TL 2019.

--
Jean-Pierre



Missing shortcut

2019-06-07 Thread Jean-Pierre Chrétien

Dear Developers

While updating fr.po for master, I see this :

Rows & Columns|

This string is in stdcontext.inc.

The shortcut is missing, there is another occurrence where the shortcut is 'C'.

--
Jean-Pierre


Re: Shortcut Conflict

2019-05-31 Thread Jean-Pierre Chrétien

Le 31/05/2019 à 16:55, Jürgen Spitzmüller a écrit :

Am Freitag, den 31.05.2019, 16:50 +0200 schrieb Jean-Pierre Chrétien:

Why not Lists/Contents/References ?
There are several lists...


Because you can only insert one list at once via the Insert menu
("Contents" and "References" are pluralia tantum here).


This is correct if the entry name means "Choose a list, the table of Contents or 
the bib refrerences style". It might also mean "Choose among lists, table of 
Contents or bib refrerences style".


--
Jean-Pierre


Re: Shortcut Conflict

2019-05-31 Thread Jean-Pierre Chrétien

Le 31/05/2019 à 15:47, Jürgen Spitzmüller a écrit :

Am Freitag, den 31.05.2019, 12:47 +0200 schrieb Jean-Marc Lasgouttes:

Le 31/05/2019 à 11:29, Jürgen Spitzmüller a écrit :

Am Donnerstag, den 30.05.2019, 12:27 +0200 schrieb Jürgen
Spitzmüller:

My suggestion would be "List/Contents/References" or simply
"List/References" if it needs to be shorter (since TOC seems more
clearly a list to me than references). In any case avoid the TOC
acronym in the UI.


Objections?


Fine with me.


OK, pushed. If I get objections, I'll revert.


Why not Lists/Contents/References ?
There are several lists...

--
Jean-Pierre



Re: r41227 - www-user/trunk/farm/cookbook/LyX

2019-04-26 Thread Jean-Pierre Chrétien

Le 26/04/2019 à 10:26, sp...@lyx.org a écrit :

Author: spitz
Date: Fri Apr 26 10:26:32 2019
New Revision: 41227
URL: http://www.lyx.org/trac/changeset/41227

Log:
Name current bg translator

(fixed in the po itself as well)


I was about to post about that. Is it worth to check other translators?
Riki, are your mail adresses used to warn about translation deadlines up to 
date?

--
Jean-Pierre



Re: Use of msgmerge

2019-03-27 Thread Jean-Pierre Chrétien

Le 27/03/2019 à 07:03, Jürgen Spitzmüller a écrit :



I have no experience with that. As for single po files, e.g. lokalize
(the KDE po editor) allows to set up another po file as "Primary Sync",
which lets you import translations from stable po with a single key
stroke (per string).


Thanks for the hint, it works fine.

I have tested also the other way, it works without manual action, so I guess 
that Jean-Marc must be right when he states that this is the preferred method to 
upgrade po files before the release of master.


I gain 22 translations, this is not much, but it insures that these translations 
will be the same in branch and master.


--
Jean-Pierre



Re: about the Win installer

2019-03-26 Thread Jean-Pierre Chrétien

Le 26/03/2019 à 03:22, Uwe Stöhr a écrit :



But that is my main problem with LyX - the development focus on
developers needs, not on the needs of average users. Average users don't
need a dozen more expert features every release but a better workflow
allowing them to write more in shorter time, to collaborate with
colleagues, good and up-to date documentation etc.


That's true that "average" users as you name them do not necessarily care about
some specific packages which appear with new releases of LyX. But they can be 
fairly productive with a several years old release of LyX and TeXLive.
In fact, we got much more problem with the development model of MiKTeX, which is 
permanently upgrading (and killed LyX on Windows for some time incidently).
A development model à la Debian, where I can stick to the stable release if I 
want to, seems much better to me than the MiKTeX stuff. And I'm not alone to 
think like that, so why distributors would boast about LTS releases ?




I got the feeling that most core LyX developers are working at
universities and institutes while the majority of users have business
jobs where time matters. 


Obviously, you do not know what you are speaking about. Do you really think that 
people working in institutions have no deadlines ?
I worked in a research institute before I retired and I had deadlines all the 
time for reports, presentations, papers and so on. That is exactly the reason 
for using LaTeX instead of Word: I did not want to be blocked because the TOC 
would mess up or the document being too big (happened once, I could not recover 
control on the document). Compared to LaTeX, LyX offered me much better 
productivity by easing e.g. a lot the reference and bibliography management 
among many other user-friendly features.


The time spent to learn about both LaTeX and LyX, and thus learning how to 
install them, was very rewarding in fact. I can't imagine anyone trying to 
install LyX on Windows to write a document due shortly. There is a learning 
curve, and your arguments about users having nothing to learn to be productive 
with LyX seem pointless to me.


--
Jean-Pierre


Use of msgmerge

2019-03-25 Thread Jean-Pierre Chrétien

Dear LyX developers,

As you can see here:

/ext/lyx/master$  msgfmt --statistics po/fr.po
7153 translated messages, 307 fuzzy translations, 137 untranslated messages.

I have some work to perform to get French translations for master up-to-date.

Among the strings to be translated in master, some have been translated in 2.3.x 
branch (which is currently up-to-date).


Does it make sense to run

/ext/lyx/master$ msgmerge -o po/frnew.po /ext/lyx/2.3.x/po/fr.po 
/ext/lyx/master/po/fr.po


(i.e. consider po file in branach as new and po file in master as old) to merge 
2.3.x translations in master translations ?


--
Jean-Pierre





Re: Reconfigure does not work for a specific user directory

2019-03-11 Thread Jean-Pierre Chrétien

Le 11/03/2019 à 01:47, Scott Kostyshak a écrit :

Attached is a user directory. I believe I happened to create it from a
weird situation. Maybe TeX Live was half-way installed or something like
that. In any case, LyX won't compile to PDF with pdflatex when this user
directory is used. That's probably not too strange. But when I
reconfigure and restart, LyX still doesn't want to compile to PDF with
pdflatex. Note that LyX will compile to PDF with lualatex. The
configure.log contains the following:

   INFO: checking for the pdflatex program...
   INFO: +checking for "pdflatex"...  yes

so I'm not sure why the button is greyed out.

To reproduce:

1. tar -xzf userdir123.tar.gz && lyx -userdir ./userdir123
2. Note that you cannot compile a simple "hello" document to PDF with pdflatex.


pdf viewer icon greyed out


3. Reconfigure and restart.
4. You still cannot compile a simple "hello" document to PDF with pdflatex.


Similar behaviour, but I can compile Hello after reconfiguration and  same LyX 
instance (2.3.2).


If I restart lyx with the userdir, the icon is greyed out again.

So reconfigure solves the problem if I keep on with LyX.

--
Jean-Pierre


Obsolete hollywood/broadway

2019-01-22 Thread Jean-Pierre Chrétien

dear developers,

Happy new year to you all first, it's still time for wishes.

A recent question on the French LyX list about the existence of a layout for 
scripts for comics lead me to review what was available in LyX for stage or 
screen play writing.


I found out that there are only two classes in CTAN prone to replace the 
obsoleted hollywood and broadway classes: screenplay.cls (2012) and stage.cls 
(2017).


Would it be appropriate to provide layouts for these ? Should I file an 
enhancement ticket ?


--
Jean-Pierre





Re: German Download Page [and Russian]

2018-12-24 Thread Jean-Pierre Chrétien

Le 24/12/2018 à 01:00, Richard Kimberly Heck a écrit :

On 12/23/18 6:59 PM, Richard Kimberly Heck wrote:

Can someone update the German download page here:

     https://www.lyx.org/WebDe.Download

to reflect the fact that the bundle installer no longer exists? And add
this language:

NOTE: Before you install LyX on Windows, you need to install a TeX
distribution. For more information on how to do this, please see this
page on the LyX wiki.


This also needs to be done on the Russian page.


Here is the translation status reminder :

https://www.lyx.org/SiteTranslation

--
Jean-Pierre


Re: 2.3.2 Tarballs Available

2018-12-10 Thread Jean-Pierre Chrétien

Le 10/12/2018 à 11:51, Pavel Sanda a écrit :

On Sun, Dec 09, 2018 at 03:17:15PM -0500, Richard Kimberly Heck wrote:

Here:

     http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/

Please prepare binaries.


seems to work without problem on debian. p



+1

--
Jean-Pierre


Re: [LyX/2.3.x] Update fr.po

2018-10-14 Thread Jean-Pierre Chrétien

Le 14/10/2018 à 11:59, José Abílio Matos a écrit :

On Sunday, 14 October 2018 10.49.11 WEST Jean-Pierre Chrétien wrote:

Is it normal that there is no record (diff) of the changes in the message ?


Yes.

That happens every time the diff is larger than a given threshold.

In practice that happens a lot for .po merges.


Thanks, Jürgen and José, I should have suspected this.

--
Jean-Pierre


Re: [LyX/2.3.x] Update fr.po

2018-10-14 Thread Jean-Pierre Chrétien

Le 14/10/2018 à 11:50, jpc a écrit :

commit 481633eab4aa1f87e604be6786c7d328cf7a3547
Author: jpc 
Date:   Sun Oct 14 11:40:28 2018 +0200

 Update fr.po

  po/fr.gmo |  Bin 543901 -> 546879 bytes
  po/fr.po  | 2394 ++---
  2 files changed, 1337 insertions(+), 1057 deletions(-)




Is it normal that there is no record (diff) of the changes in the message ?

--
Jean-Pierre


Re: Versioned User Directories on Windows

2018-10-01 Thread Jean-Pierre Chrétien

Le 01/10/2018 à 17:28, Richard Kimberly Heck a écrit :

On 10/1/18 4:02 AM, Jean-Pierre Chrétien wrote:

Le 01/10/2018 à 03:05, Richard Kimberly Heck a écrit :
[...]


I take it that the reason to have versioned user directories is so
people can have parallel installations of 2.2 and 2.3, say. But you can
still do that, of course, by manually setting the user directory. How
many people do that anyway on Windows?


With TL on Linux, there are two local directories : one with admin
privileges (texmf-local) independent of the version and one personal
(~/.texlive where  is the version number). Note the the first
one requires admin action when TL is updated, for e.g. font management.



I meant LyX's user directory, which on Linux defaults to ~/.lyx/. On
Windows, it would be something like
c:\Users\andrew\AppData\Roaming\LyX2.3\, at the moment. Note the use of
the version number.


You're right, I was mixing things up as I always install a versioned version of 
lyx here on Linux (using --with-version-suffix) for translation needs, and links 
/usr/bin/lyx and friends to the version I currently use for production (mostly 
letters nowadays).


--
Jean-Pierre



Re: Versioned User Directories on Windows

2018-10-01 Thread Jean-Pierre Chrétien

Le 01/10/2018 à 03:05, Richard Kimberly Heck a écrit :
[...]


I take it that the reason to have versioned user directories is so
people can have parallel installations of 2.2 and 2.3, say. But you can
still do that, of course, by manually setting the user directory. How
many people do that anyway on Windows?


With TL on Linux, there are two local directories : one with admin privileges 
(texmf-local) independent of the version and one personal (~/.texlive where 
 is the version number). Note the the first one requires admin action when 
TL is updated, for e.g. font management.


I wonder if it is alike on Windows, but could this be an inspiration to manage 
the problem ? Personally, I seldomly change the installed LyX user dir, but for 
testing purpose. OTOH, I do not really use LyX for production.


--
Jean-Pierre


SIGHUP signal

2018-08-28 Thread Jean-Pierre Chrétien

Hello

I happened to close a command window from which I called lyx-2.3.1 and I got a 
popup about the SIGHUP crashing LyX. Excellent!


Is it a new feature or has it been there for a long time ?

--
Jean-Pierre




Re: 2.3.1 Binaries

2018-08-28 Thread Jean-Pierre Chrétien

Le 27/08/2018 à 20:41, Richard Kimberly Heck a écrit :

Are available for testing at http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/.
I suppose we should wait to prepare binaries until we have some feedback.



On Debian Stretch, with:

Configuration
  Host type:   x86_64-pc-linux-gnu
  Special build flags:  build=release std-regex use-hunspell
  Bundled libraries:boost mythes
  C++ Compiler:g++ (6.3.0)
  C++ Compiler flags:   -fPIC -O2 -std=c++14
  C++ Compiler user flags:
  Linker flags:
  Linker user flags:
  Qt Frontend:
  Qt version:  5.7.1
  Packaging:   posix
  LyX binary dir:  /usr/local/bin
  LyX files dir:   /usr/local/share/lyx-2.3.1

compilation runs flawlessly,

With TL18, Advanced, Customization and EmbeddeOnjects pdfcompile all right.
UserGuide compilation is successful, with two warnings from the indexer:


WARNING: Found no :close-range matching an already opened one!
 Location-reference is 20 in keyword (Environnements de paragraphe).
 Maybe I lost some of the regular location-references.

WARNING: Found a :close-range in the index that wasn't opened before!
 Location-reference is 37 in keyword (Environnements de Paragraphe)
 I'll continue and ignore this.


The index processor is texindy.

--
Jean-Pierre


Re: 'make install' compiles a lot of stuff after 'make uninstall'

2018-08-27 Thread Jean-Pierre Chrétien

Le 27/08/2018 à 16:32, Scott Kostyshak a écrit :

On Mon, Aug 27, 2018 at 09:50:52AM +0200, Jean-Pierre Chrétien wrote:



Sorry for the noise, I must have run 'make clean' after installation of the
2.2.4 executable, as the job was done and lyx-2.2.4 not prone to
reinstallation.


I forget, what is your distro?


Debian Stretch



I will give the following advice before Kornel does (which he helped me
realize the benefit of). When you compile LyX, it might be helpful for
you to create a .deb and then install that with dpkg. Then your package
manager handles things. If you are interested, we can give very simple
instructions.


I have the instructions for cmake, I guess. But it's not necessary for me to go 
to the .deb package. I compile the sub-releases to be up to date for lyx work, 
and I keep the last version of the preceding release (the 2.2.4 was here for 
that sake).
And for the devel 2.3.x and master branches, I have a procedure to compile in a 
separate directory which I am accustomed to.


Thanks for your help.

--
Jean-Pierre




Re: 'make install' compiles a lot of stuff after 'make uninstall'

2018-08-27 Thread Jean-Pierre Chrétien

Le 27/08/2018 à 09:46, Jean-Pierre Chrétien a écrit :

Dear developers

I wrongly ran 'sudo make uninstall' in my lyx-2.2.4 distro build dir, so I ran
'sudo make install-strip' to reinstall. I was surprised to see files being 
recompiled as if this did not heppen earlier.


Does the earlier 'sudo make install-strip' (done when I installed 2.2.4 after 
2.3.0 was released) remove all the .o and the .a files ?




Sorry for the noise, I must have run 'make clean' after installation of the 
2.2.4 executable, as the job was done and lyx-2.2.4 not prone to reinstallation.


--
Jean-Pierre



  1   2   3   4   5   6   7   8   9   10   >