Re: about the Win installer
On 2/10/19 7:53 PM, Uwe Stöhr wrote: > Now the controversial part: > In the installer I see that you removed support for MiKTeX. You require > now that the users have enough knowledge to set up MiKTeX in advance > before installing MiKTeX. This is not the case, especially not for > newbies. Moreover you removed code that setup MiKTeX for LyX. That is > something I cannot accept because then LyX is not fully functional. > Users need a lot of knowledge to get then all features to work. Yes, we decided no longer to offer a bundled installer. That was a decision we made as a group. I'm sorry if you can't accept it, but it's the decision we made. If you need to re-add code that will configure MiKTeX for use with LyX, you are welcome to do that. In my testing, it has not been needed, however, and we have not heard any complaints from users. I see you re-introduced the mirror code, as well. The plan was to download those files from our own server---we have these somewhere on lyx.org---but I had not found time yet to do that. I'll be doing it before the 2.2.3 release, so you might just revert that for now. > However, I still follow the track that users deserve a LyX installation > that does not require background knowledge before they start using LyX. > For the first installation everything must work out of the box. And this > does not work for the installer I can download from lyx.org. > I don't want to fight again. It hurt me the last time a lot that devs > who don't use LyX under Windows for production/daily told me what should > be right for average Windows users and that the actions the installer > did successfully for about 10 years should not be done anymore to suit > the needs of expert users. > Since we could not find consensus I went away. I think we were all sorry that happened, but, as I said, we have made a number of decisions in the meantime, and I'm not sure anyone is in the mood to re-litigate those issues. You are of course free to offer your own installer, but the official LyX one will no longer tie LyX so tightly to MiKTeX. Doing so has caused too many problems. Riki
Re: about the Win installer
On Mon, Feb 11, 2019 at 01:53:18AM +0100, Uwe Stöhr wrote: > A minor issue is that the EmbeddedObjects manual can currently not be > compiled because of a bug in a LaTeX package. I reported this already. Thanks for reporting it! Where did you report it, so that I can follow? I saw this problem also, when updating TeX Live 2018. I think this is the same issue that Kornel also reproduced: https://www.mail-archive.com/search?l=mid&q=3657501.G12lpvAOYi%40amd64 Scott signature.asc Description: PGP signature
Re: define LYX_USE_LONG_LONG
On Mon, Jan 07, 2019 at 04:21:12PM +0100, Jean-Marc Lasgouttes wrote: > Le 07/01/2019 à 16:02, Jean-Marc Lasgouttes a écrit : > > Le 07/01/2019 à 15:39, Elias M. Mariani a écrit : > > > Jean-Marc Lasgouttes wrote: > > > > I would be interested to know what compiler errors you get. I'd rather > > > > get rid of the long long things, than tweak the again. > > > > > > Great, I attach a log with the compilation error. > > > > Is it the only compilation error that you get? I am surprised. > > > > Would it suffice to only rely on HAVE_LONG_LONG_INT and skip the part > > that checks size? > > Now there is something I do not understand. Linux/amd64 does have long long, > which is a 64bits type, like long. So what happens with OpenBSD that is so > special? That size_t is a long long? Just bumping these questions. Elias, do you know the answers to JMarc's questions above? Scott signature.asc Description: PGP signature
Re: LyX inserts figures into wrong positions
On Tue, Dec 18, 2018 at 03:36:29PM +0100, Pavel Sanda wrote: > Hi, > > this issue is bugging me for years, but it passed some triggering frustration > point today... > > Not sure whether you experienced it but sometimes you try to insert new figure > at the cursor position and the figure gets pasted elsewhere in the document, > it > does not happen always so one tends to get confused and think he had the > cursor > wrong or whatever. > > To reliably reproduce the issue you need to: > 1. click on some other graphics inset and cancel the dialog > 2. put the cursor elsewhere in document and insert new graphics via > menu->insert > 3. the graphics is inserted at the position of figure at step 1, not on the > cursor position > > The underlying problem is that we fill up edited insets into cache when > editing > inset is triggered, but this cache is never cleared up for dialogs > unassociated > with some inset - thus when graphics dialog is open for completely new image > the old cache is used. > > To solve this we need to trigger cache update for each dialog show. Patch > attached, it can be made more concise without BufferView.cpp part, but it will > be less visible that we rely on stuffing cache with null inset pointers for > each dialog type (the rest of code is fine with both solutions as far as I > could see). > > Unless there are objections I want to have this in both master and branch. > It however touches sensitive part of the code, so please review the patch. > > Pavel For archival purposes, note that this patch was committed at 99bfe201. Scott signature.asc Description: PGP signature
Re: Can't cancel suggestion context menu
On Sat, Dec 29, 2018 at 12:49:39AM +0100, Pavel Sanda wrote: > On Thu, Nov 29, 2018 at 01:33:17PM +0100, Pavel Sanda wrote: > > On Wed, Nov 28, 2018 at 04:01:24PM +0100, Kornel Benko wrote: > > > Am Montag, 26. November 2018 17:45:41 CET schrieb Pavel Sanda > > > : > > > > Hi, > > > > > > > > have english dictionary on, write "traces", leave cursor at the end of > > > > the work, > > > > hit tab. Context menu with suggestions appears. When I pres Esc, the > > > > context menu > > > > won't disappear. Is this expected? > > > > > > > > Pavel > > > > > > > > > > Sorry, cannot reproduce on master. Neither with master nor with stable. > > > I probably have not understood the procedure ... > > > > Because the recipy was not full, other suggestions needs to be in the > > buffer first, type: > > > > tracesi tracesu traces > > > > and hit tab after last "s". You should see contex menu with first two words > > as suggestions > > appearing and it won't disappear after Esc. > > Patch fixing the issue is attached; we simply did not have handler for Esc. > Will commit soon unless anyone objects. For archival purposes, note that the patch was committed at 33284ee5. Scott signature.asc Description: PGP signature
Re: Spacing Error With Macros
On Sat, Jun 23, 2018 at 07:08:52AM +0200, Kornel Benko wrote: > Am Samstag, 23. Juni 2018 00:36:16 CEST schrieb Richard Kimberly Heck > : > > The attached file gives me spacing errors. > > > > Riki > > > > Confirmed. > The first entered character inside the \tmp-parameter looks wrong. I can't reproduce (did the errors show in the terminal upon opening the file?). I guess this was fixed. If not, we should make a bug report. Scott signature.asc Description: PGP signature
InstantPreview fails with Python 3
InstantPreview fails with Python 3.7.2 and I cannot figure out why. In the console I see: - graphics\PreviewLoader.cpp (781): PreviewLoader::finishedInProgress(1): processing failed for python -tt $$s/scripts/lyxpreview2bitmap.py --png "C:/Users/User/AppData/Local/Temp/lyx_tmpdir.PlMVrEJL4248/lyx_tmpbuf0/lyxpreviewZb4248.tex" --dpi 115 --fg 00 --bg faf0e6 --bibtex="bibtex" I tried to run the lyxpreview2bitmap.py manually in a console and then get the error that it cannot find gswin32c or gswin64c. But the path to it is correctly set in the LyX preferences. I also could not find out how to tell the script a path to gswin32c. Therefore I could not investigate further. José, could you maybe have a look and tell me at least how to specify the path to gswin32c when executing the script in a console? thanks and regards Uwe
about the Win installer
Dear LyXers, I have been away for some months because of health problems, new job etc. but also because I don't use LyX anymore since a while because all documents I have to work with need collaborative access. And others don't like to collaborate with me with LyX but with Office365 and the like. (Personally I switched to LibreOffice because I can then convert to .docx if even .odt is not allowed in a project.) Meanwhile I got frequent requests to provide a new installer because there are problems. Today I found time and indeed there are different issues that I will try to fix. As first step I updated all libraries and commit some uncontroversial things. The good news is that with the current MiKTeX there is no longer a need to update the MiKTeX update mechanism, since all users will already have it. Unfortunately MiKTeX is crashing during the run of LyX's configure script under some circumstances. Then the users will get a non-functional LyX. I reported this already. A problem is that convertDefault.py fails under Python 3, see my last post. Another problem is that InstantPreview fails with Python 3 and I cannot figure out why, see my next post. A minor issue is that the EmbeddedObjects manual can currently not be compiled because of a bug in a LaTeX package. I reported this already. Another minor thing s that the UserGuide that comes with 2.3.2 has change tracking on. This should not happen. I'll merge these changes to the other UserGuide files as I have done for years. After that I won't have time to work on the LyX docs. Now the controversial part: In the installer I see that you removed support for MiKTeX. You require now that the users have enough knowledge to set up MiKTeX in advance before installing MiKTeX. This is not the case, especially not for newbies. Moreover you removed code that setup MiKTeX for LyX. That is something I cannot accept because then LyX is not fully functional. Users need a lot of knowledge to get then all features to work. I also see that there is not much maintenance for the installer. The libraries, dictionaries, download mirror etc. need care. I started some update action today. However, I still follow the track that users deserve a LyX installation that does not require background knowledge before they start using LyX. For the first installation everything must work out of the box. And this does not work for the installer I can download from lyx.org. I don't want to fight again. It hurt me the last time a lot that devs who don't use LyX under Windows for production/daily told me what should be right for average Windows users and that the actions the installer did successfully for about 10 years should not be done anymore to suit the needs of expert users. Since we could not find consensus I went away. regards Uwe
convertDefault.py is broken under python 3
Today I tried LyX 2.3.2 with Python 3.7.2 and found that all image
conversions failed. I investigated and I found out that this commit
introduced the problem:
5b160e82
Line 38 fails since there is no .decode() for strings.
Also line 35 fails but strangely not line 29.
Attached is the diff to get it at least to work.
José, could you please have a look?
Besides this I don't understand why we limit the depth for image
conversions to 8 bit:
sopts = "-depth 8"
I cannot see a reason for this limitation. So if there is no longer one,
sopts should be kept empty in line 22.
thanks and regards
Uwe
diff --git
"a/C:\\Users\\USti\\AppData\\Local\\Temp\\TortoiseGit\\convertDefault-4162ed1.000.py"
"b/D:\\LyXGit\\Master\\lib\\scripts\\convertDefault.py"
index 8678965013..3a2cd645aa 100644
---
"a/C:\\Users\\USti\\AppData\\Local\\Temp\\TortoiseGit\\convertDefault-4162ed1.000.py"
+++ "b/D:\\LyXGit\\Master\\lib\\scripts\\convertDefault.py"
@@ -32,10 +32,10 @@ if fout.close() != None:
# caution: windows has a convert.exe for converting file systems
command = 'convert'
fout = os.popen('convert -version 2>&1')
-output = fout.readline()
+#output = fout.readline()
fout.close()
if not PY2:
-output = output.decode()
+output = output
version = re_version.match(output)
@@ -59,7 +59,7 @@ else:
# IM >= 5.5.8 separates options for source and target files
# See http://www.imagemagick.org/Usage/basics/#why
if im or gm:
-sopts = "-depth 8"
+sopts = ""
topts = ""
elif sys.platform == 'darwin':
command = 'lyxconvert'
possible loss of data warning in current 2.3.x branch
Compiling the current 2.3.x branch gives me this warning D:\LyXGit\2.3.x\src\RowPainter.cpp(528): warning C4244: 'argument': conversion from 'double' to 'int', possible loss of data [D:\LyXGit\2.3.x\compile-2015\src\LyX.vcxproj] D:\LyXGit\2.3.x\src\RowPainter.cpp(530): warning C4244: 'argument': conversion from 'double' to 'int', possible loss of data [D:\LyXGit\2.3.x\compile-2015\src\LyX.vcxproj] This should be fixed in my opinion. regards Uwe
missing file in 2.3.2 tarball
I compiled LyX 2.3.2 from the tarball and get one CMake error that the file lyx.ico is missing. I could fix it by putting it into the folder ~\development\cmake. Either the file is missing or Cmake needs to be adapted that there is no longer this file. regards Uwe
Re: Bug #11484
Le 06/02/2019 à 16:25, Jürgen Womser-Schütz a écrit : Hi, in the surrounding field of bug #11484 I tried to improve the "user experiance" by checking the existence of the user-specified listing file. I changed two files: src/frontends/qt4/GuiInclude.cpp src/frontends/qt4/GuiInclude.h The diff-output is attached. Dear Jürgen, I have a question: is the effect of your patch to disable the OK button when the file does not exist? If it is the case, I am not sure that it will considered as an improvement by everyone. I am not a heavy listings user, but I suspect that some people insert references to documents with placeholder names that they will update/create later. I think it would be better to warn in a different way. What I am trying to do is just start the discussion. It is up to heavy users of this feature to tell how they use it. JMarc PS: welcome anyway, and sorry for the delay in answering :)
Re: [LyX/master] Don't switch encodings to/from CJK if the document encoding is using the CJK package.
Am Sonntag, 10. Februar 2019 15:56:35 CET schrieb Guenter Milde
:
> On 2019-02-09, Kornel Benko wrote:
> > Am Samstag, 9. Februar 2019 20:41:00 CET schrieb Günter Milde
> > :
> >> commit 7bbf333fa1005a0eb9658b84e0c7d65e53fd9f20
>
> > After this commit following test fails
> > DEFAULTOUTPUT_export/export/latex/unicodesymbols/001-4-latin_euc-cn_pdf2
>
>
> > ! Font C10/fs/m/n/10/03=gsfs1403 at 10.0pt not loadable: Metric (TFM) file
> > not
> > found.
> >
> >relax
> > l.111 \v{E} ��
> >\^{G} \^{g} \u{G} \u{g}
> > ...
>
> Should be fixed now, thanks for reporting.
>
> Günter
Yes, confirmed. Thanks
Kornel
signature.asc
Description: This is a digitally signed message part.
Re: [LyX/master] Don't switch encodings to/from CJK if the document encoding is using the CJK package.
On 2019-02-09, Kornel Benko wrote:
> Am Samstag, 9. Februar 2019 20:41:00 CET schrieb Günter Milde
> :
>> commit 7bbf333fa1005a0eb9658b84e0c7d65e53fd9f20
> After this commit following test fails
> DEFAULTOUTPUT_export/export/latex/unicodesymbols/001-4-latin_euc-cn_pdf2
> ! Font C10/fs/m/n/10/03=gsfs1403 at 10.0pt not loadable: Metric (TFM) file
> not
> found.
>
>relax
> l.111 \v{E} ��
>\^{G} \^{g} \u{G} \u{g}
> ...
Should be fixed now, thanks for reporting.
Günter
Re: Bug #11484
Am Mittwoch, 6. Februar 2019 17:57:55 CET schrieb Jürgen Womser-Schütz : > ... and a patch to git-master for convenience. > > Jürgen > Jürgen, if we would apply your patches, we would need your explicit permission. Like a short message on this list containing: "I hereby grant permission to use my work for LyX under the license GPL version 2 or later." Kornel signature.asc Description: This is a digitally signed message part.
Re: Bug #11484
Hi, you are right - maybe I am a bit "over-enthusiastic" :-) Jürgen Am 09.02.2019 um 22:48 schrieb Richard Kimberly Heck: > On 2/8/19 8:53 PM, Scott Kostyshak wrote: >> On Fri, Feb 08, 2019 at 10:40:48PM +0100, Kornel Benko wrote: >>> Am Freitag, 8. Februar 2019 22:14:55 CET schrieb Jürgen Womser-Schütz >>> : Hi alltogether, as I can see: no volunteers desired. Best regards Jürgen Am 06.02.2019 um 16:25 schrieb Jürgen Womser-Schütz: > Hi, > > in the surrounding field of bug #11484 I tried to improve the "user > experiance" by checking the existence of the user-specified listing file. > I changed two files: > src/frontends/qt4/GuiInclude.cpp > src/frontends/qt4/GuiInclude.h > The diff-output is attached. > > Jürgen >>> Don't be disappointed. Sometimes it may take some time until some >>> experienced >>> developer checks your patch. >> +1 > And, just to be clear, traffic on the list has just generally been a bit > light lately. My sense is that a lot of people are very busy right now. > We're *all* volunteers with demanding day-jobs. I am as busy with > classes, etc, right now as I can ever remember being. And now I'm sick. :-( > > Riki > >
