Re: 2.4.0 Tarballs
Am 26.05.2024 um 04:45 schrieb Richard Kimberly Heck : > > Here: > > http://ftp.lyx.org/pub/lyx/devel/lyx-2.4/ > > Let's have a day or two of testing. Assuming all goes well, we can build > tarballs early next week, and release at the end of the week. I’m able to build the package and start it on Intel and Apple CPU without problems. BR, Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: TESTING Tarballs for 2.4.0
Am 13.05.2024 um 23:48 schrieb Richard Kimberly Heck : > > Hi, all, > > Tarballs for 2.4.0 are here: > > http://ftp.lyx.org/pub/lyx/devel/lyx-2.4/ > > Please test. Please let me know if I forgot to do or include anything. No problem to build the bundle on Mac. Stephan > > Hold off on binaries for now. > > Riki > > > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Version 2.4.0~RC4 Instant preview stops working when inserting floats or comments
> Am 15.05.2024 um 23:35 schrieb Jean-Marc Lasgouttes : > > Le 10/05/2024 à 18:16, fcana...@gmail.com a écrit : >> Yes, I still have the issue. I am attaching a screencast, recorded on M2 Mac >> with fresh install of version 2.4.0~RC4 after deleting all user-defined >> preferences from previous version. > > Thanks for the very clear screencast. I am still not able to reproduce the > issue on Linux. > > Do you see any error in View>Messages Pane? > > Alternatively, are you able to run LyX from a terminal in order to have other > error messages ? > > Stephan, can you confirm the issue? No, I cannot reproduce it. I’m testing on an Apple Mac mini M1 with TeX Live 2020 and the release candidate bundle 2.4.0~RC4. BR, Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: 2.3.8 Tarballs
Am 02.05.2024 um 22:47 schrieb Richard Kimberly Heck : > > Here: > > http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/ > > Please check that they build and run properly, especially export to and from > 2.4.x. > > When we've verified all is well, I'll give the signal to build binaries for > real. Now, I’ve built the binary and checked the import from 2.4.x with a large and complex document. No unit test but it works w/o problems. I had to correct my build script to get the hunspell dictionaries packaged with internal hunspell. BR, Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: 2.3.8 Ready To Go?
Am 02.05.2024 um 17:03 schrieb Richard Kimberly Heck : > > On 5/2/24 10:54, Richard Kimberly Heck wrote: >> Just double checking that all issues there have been resolved. If so, I'll >> build the tarballs. > > PS The ANNOUNCE file for 2.3.7 had this: > > One important note: Recent versions of Mac OSX do not include a working > version of Python. LyX needs this for proper functionality. See > "https://wiki.lyx.org/Mac/Mac#toc2 for information on how to install > Python, if you need to do so. The most obvious sympton is that, on > startup, LyX reports that it will have 'minimal functionality'. Another > symptom is that images or previews do not display properly. > > Do we will need that? No. LyX should display a proper message itself on startup. But I haven’t tested it recently though. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0 RC3
Am 20.04.2024 um 14:59 schrieb Jürgen Spitzmüller : > > Am Freitag, dem 19.04.2024 um 17:24 +0200 schrieb jspi...@gmail.com: >> Am Freitag, dem 19.04.2024 um 17:11 +0200 schrieb jspi...@gmail.com: >>> I am currently traveling, so I cannot test. But does the attached >>> patch help and provide a sufficient clues? >> >> Take this. The first one didn't link. > > I had a closer look and committed a better solution to master > (b8ff824a4f4ab4). This one checks for possible causes of the invalid > packages.lst format and tries to solve it, informing the user about > what has been done. Looks good. > Riki, although this introduces some new strings, I would advise to put > this to 2.4.0. This is something that could bite users on upgrade, and > it makes LyX unusable and is pretty hard to diagnose on your own. So an > untranslated warning here is probably better that no warning at all. Yes. +1. Stephan > > -- > Jürgen > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0 RC3
Am 14.02.2024 um 12:13 schrieb Jürgen Spitzmüller : > > Am Montag, dem 12.02.2024 um 22:59 -0700 schrieb list_em...@icloud.com: >> I’m sorry to report continuing problems on macOS 12.7.2, Monterey >> with LyX 2.4.0 RC3. >> >> Hangs (pinwheel) on first launch with only Apple and LyX menu items, >> then same on second launch. Very low CPU and memory use. Force quit >> both. >> >> Deleted /Users/me/Library/Application Support/LyX-2.4/ >> >> Re-launch. Opens “Welcome to LyX!”. Then I did Document -> View -> >> (PDF (pdflatex)). No PDF is created. Instead, rapid looping of some >> messages in the status bar, apparently involved with TeX stuff, such >> as “Indexing TeX files… .” Document -> Cancel Export has no effect. >> At the same time, about 24 files are being written or modified in >> /Users/me/Library/Application Support/LyX-2.4/ every 1-3 seconds. I >> am able to capture the contents of e.g. configure.log. Attempt to >> quit normally causes this dialog: " LyX could not be closed because >> documents are being processed by LyX.” >> >> Force quit again. >> >> Re-launch. Hangs as on first launch; no Welcome. >> >> Re-boot. Same sort of behavior. Safe boot. Same: Sometimes opens >> Welcome then hangs. Sometimes doesn’t finish drawing menu bar and >> hangs. Sometimes opens Welcome and hangs when trying to open a new >> file. Can no longer get to where I can attempt to make a PDF. > > Can you open LyX from a Terminal window and observe the output? Is it > possible that the configuration of LyX gets repeatedly run in a loop? > > I have had that when I first installed 2.4.x without version suffix, > and it turned out I had an old version of chkconfig.ltx in my personal > LyX directory (no idea how it ended there). As the configure syntax > significantly changed, this broke configuration. Removing the file > fixed the issue for me. > > Maybe LyX 2.4 also accesses some outdated configuration files in your > case. Or the configuration (or some conversion) fails for another > reason. > > Terminal output might help us pinpointing the issue. Now I got a clue how it happens. In LaTeXPackages::getAvailable() is a recursion implemented and in our case it happens to be endless. The reconfigure fails at first and in getAvailable() it is retried but fails again (and again and again). BR, Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Improved copy operation for user directory contents of previous major releases
This is a change I strongly suggest to port back to 2.4.0 and 2.4.1.
It will not harm and should avoid a possible problem like Jerry reported with
RC3.
Stephan
> Am 11.04.2024 um 18:32 schrieb Stephan Witt :
>
> commit 945a02e2e176e0f8fb9c599700c693032a01fa5d
> Author: Stephan Witt
> Date: Thu Apr 11 18:30:29 2024 +0200
>
>Improved copy operation for user directory contents of previous major
> releases
>
>- avoid copying of configure.log
>- avoid copying of chkconfig.ltx
> There is a report of a hang on first start of LyX with new major release.
> The removal of the chkconfig.ltx (leftover from early LyX versions)
> fixed the issue.
> ---
> lib/configure.py | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/configure.py b/lib/configure.py
> index 80cc787230..df0251268a 100644
> --- a/lib/configure.py
> +++ b/lib/configure.py
> @@ -157,8 +157,8 @@ def copy_tree(src, dst, preserve_symlinks=False, level=0):
> link_dest = os.readlink(src_name)
> os.symlink(link_dest, dst_name)
> outputs.append(dst_name)
> -elif level == 0 and name == 'cache':
> -logger.info("Skip cache %s", src_name)
> +elif level == 0 and name in [ 'cache', 'configure.log',
> 'chkconfig.ltx' ]:
> +logger.info("Skip copy of %s", src_name)
> elif os.path.isdir(src_name):
> outputs.extend(
> copy_tree(src_name, dst_name, preserve_symlinks, level=(level
> + 1)))
> --
> lyx-cvs mailing list
> lyx-...@lists.lyx.org
> http://lists.lyx.org/mailman/listinfo/lyx-cvs
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: INSTALL.MacOSX - last bit of qt4 piece
Am 11.04.2024 um 18:36 schrieb Pavel Sanda : > > Hi Stephan, > > our last piece item in TODO.killqt4 is to update INSTALL.MacOSX. > Would you have time to have a look on that these days? I’ll have a look. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Biginset branch has landed (sorry for the spam)
Am 11.04.2024 um 23:55 schrieb Jean-Marc Lasgouttes : > > Le 11/04/2024 à 18:21, Stephan Witt a écrit : >>> Is it new to master (i.e., the biginset branch)? >> I think it’s new. >>> If you have time to make a video I would be interested to see it because I >>> cannot reproduce on X (I have to try Wayland). >> Yes, I made two videos - one for 2.3.6.2 and one for 2.5 (master): >> https://my.hidrive.com/share/mvbnniztqa > > Thanks for the videos. It was not clear to me that the issue was when > splitting at bottom. Is it with yesterday's commit 83e7c74f6b4ce06936? It is at a6ba4c8c5c - so yes it is with 83e7c74f6b4ce06936. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Biginset branch has landed (sorry for the spam)
Am 11.04.2024 um 16:59 schrieb Jean-Marc Lasgouttes : > > Le 10/04/2024 à 18:52, Stephan Witt a écrit : >> Am 10.04.2024 um 15:10 schrieb Jean-Marc Lasgouttes : >>> >>> Le 10/04/2024 à 15:09, Kornel Benko a écrit : >>>> This patch definitely cured the behaviour here. >>> >>> Thanks for testing. Both for the math and the minibuffer examples? (this is >>> what I see, but I want to be sure). >>> >>> The problem is that most of the biginset branch was developed and debugged >>> using the xcb platform, and it has very different behavior from Wayland (or >>> macOS, actually). >> Ok, so I’ll do some testing too :) >> The first effect I’ve noticed: >> 1. open outline >> 2. change docked to floating window >> 3. move back to „sensitive“ area but don’t dock the window >> 4. the target place for dock-widget remains unused until one scrolls the >> work area > > Is it new to master (i.e., the biginset branch)? I think it’s new. > If you have time to make a video I would be interested to see it because I > cannot reproduce on X (I have to try Wayland). Yes, I made two videos - one for 2.3.6.2 and one for 2.5 (master): https://my.hidrive.com/share/mvbnniztqa Stephan > But obviously the detail of when repaint occur depends on the platform, so I > would not be surprised to see issues on macOS or windows. > > JMarc > > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0 RC3
Am 16.02.2024 um 07:53 schrieb list_em...@icloud.com: > > Sorry for the slow response. > > Running from a terminal indeed showed repeated configuration runs. Near the > top of the first run (and only the first run) were these lines: > > +Running LyX configure with Python 3.9.18 > Checking for upgrade from previous version. > Found directory "/Users/me/Library/Application Support/LyX-2.3". > Skip cache /Users/me/Library/Application Support/LyX-2.3/cache > Content copied from directory "/Users/me/Library/Application Support/LyX-2.3”. > > I found three identical copies of chkconfig.ltx in each of > > /Users/me/Library/Application Support/LyX-2.1/chkconfig.ltx > /Users/me/Library/Application Support/LyX-2.2/chkconfig.ltx > /Users/me/Library/Application Support/LyX-2.3/chkconfig.ltx > > > I zipped all of them and trashed the original. Now LyX 2.4.0 RC3 runs great. > > Thanks for that tip. > > I know how that file got there: LyX put it there. Maybe if the configuration > file has changed for 2.4 then it shouldn’t copy old versions. > > Note that 2.4 apparently just copies a bunch of stuff from the 2.3 directory > because now there is this file: > > /Users/me/Library/Application Support/LyX-2.4/chkconfig.ltx.zip > > which is obviously a copy of the file that I zipped, likely from the > corresponding 2.3 directory. > > There is now no chkconfig.ltx in the 2.4 directory. > > Jerry Hi Jerry, you’re right with your assumptions. The idea is to mimic the in-place update of LyX to avoid a reset of the user configuration to system defaults in case of an upgrade to a new LyX major version. Therefore the copy of the contents of the previous LyX major versions user directory to the fresh created one. This copy operation happens only once. I’m trying to reproduce your problem to find a solution for it. I’m unable to get repeated configuration runs. I’ve put the chkconfig.ltx as of version lyx-2.0.6 into ~/Library/Application Support/LyX-2.3 to test it. May I ask you to send me a copy of your chkconfig.ltx, please? (The old version causing the problem…) Thank you and best regards, Stephan >> On Feb 14, 2024, at 4:13 AM, Jürgen Spitzmüller wrote: >> >> Am Montag, dem 12.02.2024 um 22:59 -0700 schrieb list_em...@icloud.com: >>> I’m sorry to report continuing problems on macOS 12.7.2, Monterey >>> with LyX 2.4.0 RC3. >>> >>> Hangs (pinwheel) on first launch with only Apple and LyX menu items, >>> then same on second launch. Very low CPU and memory use. Force quit >>> both. >>> >>> Deleted /Users/me/Library/Application Support/LyX-2.4/ >>> >>> Re-launch. Opens “Welcome to LyX!”. Then I did Document -> View -> >>> (PDF (pdflatex)). No PDF is created. Instead, rapid looping of some >>> messages in the status bar, apparently involved with TeX stuff, such >>> as “Indexing TeX files… .” Document -> Cancel Export has no effect. >>> At the same time, about 24 files are being written or modified in >>> /Users/me/Library/Application Support/LyX-2.4/ every 1-3 seconds. I >>> am able to capture the contents of e.g. configure.log. Attempt to >>> quit normally causes this dialog: " LyX could not be closed because >>> documents are being processed by LyX.” >>> >>> Force quit again. >>> >>> Re-launch. Hangs as on first launch; no Welcome. >>> >>> Re-boot. Same sort of behavior. Safe boot. Same: Sometimes opens >>> Welcome then hangs. Sometimes doesn’t finish drawing menu bar and >>> hangs. Sometimes opens Welcome and hangs when trying to open a new >>> file. Can no longer get to where I can attempt to make a PDF. >> >> Can you open LyX from a Terminal window and observe the output? Is it >> possible that the configuration of LyX gets repeatedly run in a loop? >> >> I have had that when I first installed 2.4.x without version suffix, >> and it turned out I had an old version of chkconfig.ltx in my personal >> LyX directory (no idea how it ended there). As the configure syntax >> significantly changed, this broke configuration. Removing the file >> fixed the issue for me. >> >> Maybe LyX 2.4 also accesses some outdated configuration files in your >> case. Or the configuration (or some conversion) fails for another >> reason. >> >> Terminal output might help us pinpointing the issue. >> >> -- >> Jürgen >> -- >> lyx-devel mailing list >> lyx-devel@lists.lyx.org >> http://lists.lyx.org/mailman/listinfo/lyx-devel > > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Biginset branch has landed (sorry for the spam)
Am 10.04.2024 um 15:10 schrieb Jean-Marc Lasgouttes : > > Le 10/04/2024 à 15:09, Kornel Benko a écrit : >> This patch definitely cured the behaviour here. > > Thanks for testing. Both for the math and the minibuffer examples? (this is > what I see, but I want to be sure). > > The problem is that most of the biginset branch was developed and debugged > using the xcb platform, and it has very different behavior from Wayland (or > macOS, actually). Ok, so I’ll do some testing too :) The first effect I’ve noticed: 1. open outline 2. change docked to floating window 3. move back to „sensitive“ area but don’t dock the window 4. the target place for dock-widget remains unused until one scrolls the work area Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Smarter menu length calculation
Am 02.04.2024 um 14:43 schrieb Juergen Spitzmueller : > > commit f3a4602c4c1eca9bc79e7ba0b58395b79eafe9db > Author: Juergen Spitzmueller > Date: Tue Apr 2 14:41:54 2024 +0200 > >Smarter menu length calculation > >It is possible I have missed some shortcut conflicts, so please report >if you find any. Here I get the following warnings: frontends/qt/Menus.cpp (781): Menu warning: menu entries "Move Paragraph Up|h" and "Einfügen (vorherige Auswahl)|h" share the same shortcut. frontends/qt/Menus.cpp (781): Menu warning: menu entries "Plain Single Quotation Mark|S" and "Satzendepunkt|S" share the same shortcut. frontends/qt/Menus.cpp (781): Menu warning: menu entries "Move Paragraph Up|h" and "Einfügen (vorherige Auswahl)|h" share the same shortcut. frontends/qt/Menus.cpp (781): Menu warning: menu entries "Plain Single Quotation Mark|S" and "Satzendepunkt|S" share the same shortcut. I’d guess, the real problem is the missing translation. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Comment on ticket 12641 regarding handling of some short cuts on macos with qt6.
Am 28.03.2024 um 10:44 schrieb pdv : > > This contains a report on an issue discussed in > https://www.lyx.org/trac/ticket/12641. I have also looked at it and this is > my conclusion. At this time the only feasible partial remedy I see would be > to switch IM on/off depending on the language input selected by the user. > This would solve the problem for roman languages and limit it to asian > languages. Of course it would be better if qt6's switch of behaviour was > reversed. > If there are no objections I would like to send the following to a relevant > qt-forum. > > pdv Hi Patrick, I’d be more than happy if you’ll do this. Thank you. Stephan > > > Since qt commit https://github.com/qt/qtbase/commit/9e1875483ceaf90 the > handling of some short cuts by LyX (https://www.lyx.org/) on macos doesn't > work anymore. > > In that commit the default handling of key events was reversed. Before this > commit key events were send for all key presses unless they were handled by > the "input method" (IM) system primarely used by complex (asian) languages. > After this commit. IM became the default system and key events are only send > in 2 cases: simple text and commands involving a single modifier key. In a > later commit a cancel operation was added as a third exception. The only way > to revert to the former behaviour is to switch IM off by setting > WA_InputMethodEnabled=false. > > Before this change of behaviour LyX could deal with both systems with the IM > switched on by default. After the switch the issuing of commands involving 2 > modifier keys (e.g. ^CmdE to switch emphasis) did no longer work. > > A very similar problem was reported in QTBUG-106516 and contains this > comment, by Tor Arne Vestbø: > > "... Input methods should only be enabled for controls that are doing "text > input", where you want the text input system of the OS to play a part (for > example in composing characters for languages like Korean or Japanese). In > your case you are not doing text input, you are processing "raw" key events, > so disabling IM makes sense, including on Windows and Linux." > > Since the user might input asian language text, switching the IM off is not a > solution. LyX could switch IM on or off depending on the keyboad input chosen > by the user (asian or roman). This would solve the problem for roman > languages but not for asian languages. After all I suppose that al least some > 2-modifier commands also make sense for an asian language. > > The question arises why the behaviour of qt has been reversed. This was to > remedy QTDEBUG-46300. AquaSKK is an IM to input Japanese and it uses ^I to > switch the language on/off. In other words when inputting japanese characters > AquaSKK still expects that ^I is handled regularly, and therefore the > behaviour was reversed. (of course AquaSKK could easily have filtered out > this one command). But the change was justified as follows: > > "... The reason for this is that Qt's IM protocol was designed to handle > composited text, so sending non-composited (but IM-initiated) text input as > IM events is unexpected" > > Fair enough, but I suppose that commands involving 2 modifier keys (or even > more) also fall in this category and should also be handled as oridinary key > events and not by the IM. But this may just be the beginning of an endless > list of exceptions. > Was this reversion really the best possible solution for handling the initial > bug? > > Sources and references: > > qt commits > > https://github.com/qt/qtbase/commit/9e1875483ceaf90 > https://github.com/qt/qtbase/commit/60caec953f76b1c63ff526c84cc968b5f83eabdf > https://github.com/qt/qtbase/commit/57e99441102f96dd0180a6ead84d8e8b3bd6b6f0 > > qt bug reports > > https://bugreports.qt.io/browse/QTBUG-46300 > https://bugreports.qt.io/browse/QTBUG-71394 > https://bugreports.qt.io/browse/QTBUG-106516 > > = > > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4 RC4
Am 24.03.2024 um 23:36 schrieb Richard Kimberly Heck : > > One last RC, just to be on the safe side. > > http://ftp.lyx.org/pub/lyx/devel/lyx-2.4/ > > Please prepare binaries. Hi all, the binary package for mac is ready and sent to Riki. Best regards, Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Lyx 2.4.0 RC3 SVN Crash MAC OSX.
Am 19.02.2024 um 05:17 schrieb Robert Betz : > > I am currently using Lyx 2.4.0 RC3 on MAC OSX V14.2.1 (Sonoma) and if I try > and check in a Lyx document to an SVN repository Lyx crashes. Using the same > SVN version under Lyx V2.3.7 is OK. > > The Lyx crash log is: > > ( 1) 1 lyx 0x0001028e85c3 > _ZN3lyx8frontend5Alert7doErrorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b > : 1 lyx 0x0001028e85c3 > _ZN3lyx8frontend5Alert7doErrorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b > + 199 > ( 2) 2 lyx 0x0001028e893c > _ZN3lyx8frontend5Alert5errorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b > : 2 lyx 0x0001028e893c > _ZN3lyx8frontend5Alert5errorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b > + 139 > ( 3) 3 lyx 0x0001025edeff > _ZN3lyxL13error_handlerEi : 3 lyx > 0x0001025edeff _ZN3lyxL13error_handlerEi + 350 > ( 4) 4 libsystem_platform.dylib0x7ff8065d237d _sigtramp : > 4 libsystem_platform.dylib0x7ff8065d237d _sigtramp + 29 > ( 5) 5 ??? 0x7ff7bda4486e 0x0 : 5 > ??? 0x7ff7bda4486e 0x0 + 140702015309934 > ( 6) 6 lyx 0x000102717774 > _ZNK3lyx13InsetMathGrid4drawERNS_11PainterInfoEii : 6 lyx > 0x000102717774 > _ZNK3lyx13InsetMathGrid4drawERNS_11PainterInfoEii + 168 > ... > > Regards, > > Bob Hi Bob, thank you for testing the RC3 version. I tried to reproduce the crash but I failed. I suppose it happens for some documents only, i.e. for documents containing some MathGrid element. Is the crash reproducible for you or is it spurious? Is it possible to provide a MWE document? BR, Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0 RC3
Am 13.02.2024 um 05:19 schrieb Robert Betz : > > I am using MAC OSX 14.2.1 with Lyx V2.4.0 RC3. > > When I use forward search to a PDF in Skim everything works OK, but the > reverse search does not work. > > Incidentally, both forward and reverse search work with Lyx V2.3.7. > > Has anyone else had this trouble with V 2.4.0 RC3? Hi Bob, reverse search isn't working in case of a parallel installation of both LyX versions. Out-of-the-box it works with LyX in /Applications only. BR, Stephan > Regards, > > Bob > > Robert Betz > E: robertbe...@gmail.com > M: 0419249948 > > > Richard Kimberly Heck wrote on 12/2/2024 8:41 am: >> The third release candidate for 2.4.0 is available here: >> >> http://ftp.lyx.org/pub/lyx/devel/lyx-2.4/ >> >> The reason for the quick release of the third one was a bug preventing the >> editing of math in tables. That has been fixed, as has been another bug >> affecting the creation of LyX 'archives' on Windows. >> >> Please report any problems to lyx-devel@lists.lyx.org, which you should be >> able to do by replying to this message. >> >> Riki >> >> > > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: RC2 Tarballs
> Am 06.02.2024 um 23:17 schrieb Dr Eberhard W Lisse : > > Anyone doing the Mac version? Yes, it‘s already done. The upload is available to release management. BR, Stephan > greetings, el > >> On 2024-02-05 05:10, Richard Kimberly Heck wrote: >> are here: >> >> http://ftp.lyx.org/pub/lyx/devel/lyx-2.4/ >> >> Please prepare binaries. >> > > -- > To email me replace 'nospam' with 'el' > > > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: 2.4.0~RC1 hangs on macOS
Am 24.01.2024 um 09:02 schrieb José Matos : > > On Wed, 2024-01-24 at 00:48 -0700, list_em...@icloud.com wrote: >> Thanks, el. >> >> Getting rid of macports for homebrew is not an option for me. >> >> In my profile file, I have this: >> >> alias python=/opt/local/bin/python3 >> >> which is macports. Does LyX see this? This alias points to Python >> 3.9.18. There is a utility to switch to other versions. >> >> I already have the command line tools installed, with Python 3.9.6 at >> /usr/bin/phython3. >> >> I just now tried switching to this line in my profile file: >> >> alias python=/usr/bin/python3 >> >> with the same result. >> >> Remember that LyX 2.3.7 works fine. >> >> Jerry > > LyX tells what is the version used in Help->About LyX. > > Of course that the issue is that if it hangs before you can not see > that. > > Honestly I would be quite surprised if problems comes to be python > since reconfigure runs. > > The issue is why do you get the loop. > > One idea here is to output the Python version to the reconfigure > output. > > That is quite easy, since we already inside Python. > > The only thing that looks a bit strange is: > """ > +checking for "lilypond"... yes > + found LilyPond, but could not extract version number. > checking for a LilyPond book (LaTeX) -> LaTeX converter... > +checking for "lilypond-book"... yes > File "/Applications/LyX.app/Contents/MacOS//lilypond-book", line 12 >unset DISPLAY > ^ > SyntaxError: invalid syntax > """ > > This is a shell script that only goes in Mac distribution and the > reconfigure code seems to try to run it as Python? Yes, the version check in configure.py is executed twice. The first attempt is the simple call, the 2nd is a python call. The latter should be made on windows only as it is mentioned in the comment (~ line 1336). I’ve made the change and put it in. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ARM vs Universal Etf
Am 11.01.2024 um 23:14 schrieb Richard Kimberly Heck : > > On 1/11/24 16:27, Dr Eberhard W Lisse wrote: >> I see one for ARM, would a universal one be forthcoming? >> >> I have a mixed setup and am salivating :-)-O > > Stefan? I don’t know where you’re looking, Eberhard… This is the disk image I’ve produced and published to Riki: $ file /Volumes/Software/LyX/lyx-release/LyX-2.4.0~RC1+qt5-x86_64-arm64-cocoa.dmg /Volumes/Software/LyX/lyx-release/LyX-2.4.0~RC1+qt5-x86_64-arm64-cocoa.dmg: bzip2 compressed data, block size = 100k This is the LyX binary in the mounted image: $ file /Volumes/LyX-2.4.0~RC1/LyX.app/Contents/MacOS/lyx /Volumes/LyX-2.4.0~RC1/LyX.app/Contents/MacOS/lyx: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64] /Volumes/LyX-2.4.0~RC1/LyX.app/Contents/MacOS/lyx (for architecture x86_64): Mach-O 64-bit executable x86_64 /Volumes/LyX-2.4.0~RC1/LyX.app/Contents/MacOS/lyx (for architecture arm64): Mach-O 64-bit executable arm64 Ok? Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0 Schedule
Am 09.01.2024 um 11:11 schrieb Pavel Sanda : > > On Wed, Dec 20, 2023 at 08:47:01PM -0500, Richard Kimberly Heck wrote: >> I've sent a note to the translators making one final call for translations, >> asking for them to be delivered by the New Year. Shortly after that, I will >> package RC2, and hopefully we can aim at an actual release by the end of >> January. > > Breakdown of current bugs with 2.4 milestone: > #13022 - regression - LyX modifies unicode in ERT. Anyone to help? > #13017 - "aux file not found" at export - patch, but Riki is probably > waiting for Juergen's input > #10425 - the ongoing story, where to center the cursor after jump; seems > currently at JMarc decision how we move with this > #12935 - mac + japanese path encoding crash; Stephan, can you even reproduce? Yes, I can. The backtrace and terminal output with debug any is attached at ticket #12935. Stephan > #12880 - hebrew input/font ecoding - waiting on input from Udi > #13005 - bottom dock can't be enlarged if simple search is used; I can't work > on it now, but would like to see it fixed in 2.4, perhaps post RC phase.. > > Pavel > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Bug-report - LyX crash
Am 15.09.2023 um 15:26 schrieb Jean-Marc Lasgouttes : > > Le 15/09/2023 à 13:18, Stephan Witt a écrit : >>> To me, this looks like this one: >>> https://www.lyx.org/trac/ticket/12818 >>> >>> We have a problem on macOS with the interpretation of the return values of >>> QMessageBox. >>> >>> I see the patch there is not backported to 2.3.x. Is this normal? >> I think it’s not backported because it’s reported for 2.4.0dev. > > Yes, I saw that. Can you confirm that it does not happen in 2.3.x? Hm, I didn’t try it yet. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Bug-report - LyX crash
Am 15.09.2023 um 11:44 schrieb Jean-Marc Lasgouttes : > > Le 15/09/2023 à 11:40, luxhacker a écrit : >> Hi Pavel, >> Please create an account for me. I am very interested in LyX. >> It's difficult to reproduce or seize a problem without knowing anything >> about it. >> When looking at the stack, I get - perhaps wrongly - the impression it's >> user-interface related. Which surprises me a lot. > > To me, this looks like this one: > https://www.lyx.org/trac/ticket/12818 > > We have a problem on macOS with the interpretation of the return values of > QMessageBox. > > I see the patch there is not backported to 2.3.x. Is this normal? I think it’s not backported because it’s reported for 2.4.0dev. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Output python version in About dialog.
Am 05.09.2023 um 20:49 schrieb Pavel Sanda : > > On Mon, Sep 04, 2023 at 10:17:23PM +0100, José Matos wrote: >> Attached is a one-line patch to fix the documentation (in this case >> this can almost be applied manually). :-) > > It's in. Pavel Just for the record - the translated variant w/o python: Version 2.4.0~RC1.devel (26. Juni 2023) Erstellt aus Git-Revision 97ed7ded Qt-Version (Laufzeit): 5.15.10 (Plattform: cocoa) Qt-Version (bei Erstellung): 5.15.10 OS-Version (bei Erstellung): macOS 12.6 Python-Aufruf: None Looks nice - except the translation of the OS version - it’s at run-time, not compile-time. BR, Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Output python version in About dialog.
Am 04.09.2023 um 23:17 schrieb José Matos : > > On Mon, 2023-09-04 at 20:34 +0200, Pavel Sanda wrote: >> commit 625c61f1d545044f8c287434968b79f17004a078 >> Author: Pavel Sanda >> Date: Mon Sep 4 21:50:51 2023 +0200 >> >> Output python version in About dialog. >> >> Patch from Jose. > > @Stephan could you test this, please, to see if the output is > meaningful (on Mac)? I think so. BR, Stephan > > Attached is a one-line patch to fix the documentation (in this case > this can almost be applied manually). :-) > > Best regards, > -- > José Abílio > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Policy for opening url links in documents
Am 17.08.2023 um 01:00 schrieb Richard Kimberly Heck : > > On 8/16/23 18:29, Pavel Sanda wrote: >> On Wed, Aug 16, 2023 at 05:30:56PM -0400, Richard Kimberly Heck wrote: Now what are your opinions what we should do about it? 1) nothing. 2) add dialog before launching url. safer but super annoying. 3) add dialog before launching url + dont ask again checkbox. not implemented - we'll also need to add session keys, which get erased often. 4) add link target to context menu (non trivial to implement) 5) add (by default disabled) checkbox in security preference to allow opening links for citations and hyperlinks similarly as we do with scripts. 6) ? I tend to go for 5, but there might be other options I did not think of... >>> I'm always quite paranoid about this. I suppose (5) is OK if people know >>> what they're doing. Could we combine (3) and (5)? If we only have (5), then >>> people might not discover this functionality. >> If discoverability is a problem in the case of 5, we might simply let >> the item in context menu visible, but disabled, so people get curious... >> >>> But perhaps in the dialog we could say something like, "If you want to >>> disable this warning, see Tools> Preferences> Whatever". >> So you propose two RCs - one for 5) and one for disabling 3)? > > No, I meant one for (5), which would disable (3). > > Riki BTW, there is a RC already (but not evaluated in this code path) - citation_search. Perhaps it can be used here? Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: spell.m4
Am 07.08.2023 um 10:32 schrieb José Matos : > > On Sun, 2023-08-06 at 23:10 +0300, Nusret Balci wrote: >> In config/spell.m4, line 64: >> >> CXXFLAGS="$ENCHANT_CFLAGS $AM_CXXFLAGS $CXXFLAGS" >> >> Shouldn’t this line be: >> >> CXXFLAGS=“$HUNSPELL_CFLAGS $AM_CXXFLAGS $CXXFLAGS" >> >> Regards, >> >> Nusret > > Nope. > > Because Enchant is a wrapper around several spell checkers. One of > those is hunspell but it is not the only one: > https://en.wikipedia.org/wiki/Enchant_(software) I think, Nusret is right. The mentioned CXXFLAGS line is inside the test for working Hunspell (LYX_HAVE_HUNSPELL_CXXABI - and probably copied from enchant code block). Stephan > > -- > José Abílio > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Windows Dark Mode and "fusion" style
Am 05.07.2023 um 09:43 schrieb Yu Jin : > > Am Di., 4. Juli 2023 um 15:42 Uhr schrieb Pavel Sanda: > On Tue, Jul 04, 2023 at 10:55:14AM +0200, Yu Jin wrote: > > Am Di., 4. Juli 2023 um 10:40 Uhr schrieb Jürgen Spitzmüller: > > > > > Am Dienstag, dem 04.07.2023 um 10:33 +0200 schrieb Yu Jin: > > > > How do you switch on Linux/MacOS? Or does it just follow the system > > > > setting? > > > > > > It follows the system settings unless you use a dark style via cl > > > switch. > > On linux systems where desktop manager does not do it automatically, you > can use (in case of QT 5) qt5ct tool to set it up. E.g. you select fusion > style and "darker" (or any other you might like) color scheme. > > Then before running lyx you set the environment variable > QT_QPA_PLATFORMTHEME=qt5ct > and that should work (tested on oldstable debian). > > > What if we make "fusion" style default on windows then? That would make > > LyX's behavior the same as on Linux and MacOS. > > Given that you are now the principal maintainer of the windows port > I think that's up to you to decide. > > Advantage of fusion is that it will look the same across platform > disadvantage might be that it looks less native to windows than > other apps on your desktop? > > Actually Qt blog says that "their" preferred style on Windows is fusion > ¯\_(ツ)_/¯. > > So would that be something we want to set on all platforms? or only Windows? > I attached 2 patches accordingly, the style can be overwritten by the user > through command line arguments as before. > > Which one should I push? IMO the Windows platform only patch. On macOS the command line is not an option for the „ordinary“ user. The change in style of e.g scrollbars gives LyX a strange feeling. BR, Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyXMacros.patch for RC1 instead of rc1
Am 18.06.2023 um 23:15 schrieb Jean-Marc Lasgouttes : > > Le 18/06/2023 à 22:12, Stephan Witt a écrit : >> Hi Kornel, >> I need to patch LyXMacros.patch to get a working cmake build. W/o the patch >> I get: >> CMake Error at development/cmake/modules/LyXMacros.cmake:465 (message): >> "/Users/stephan/git/lyx/configure.ac": Unable to determine build-type from >> suffix "" in AC_INIT macro >> Call Stack (most recent call first): >> CMakeLists.txt:120 (determineversionandbuildtype) >> Is it only me or should the patch go in? The same problem will happen with >> BETA1 etc. of course. > > I think the patch should go in. Nobody knows what casing the maintainer will > use :) I’ve applied a more general solution with change f88986eff5. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
LyXMacros.patch for RC1 instead of rc1
Hi Kornel, I need to patch LyXMacros.patch to get a working cmake build. W/o the patch I get: CMake Error at development/cmake/modules/LyXMacros.cmake:465 (message): "/Users/stephan/git/lyx/configure.ac": Unable to determine build-type from suffix "" in AC_INIT macro Call Stack (most recent call first): CMakeLists.txt:120 (determineversionandbuildtype) Is it only me or should the patch go in? The same problem will happen with BETA1 etc. of course. Stephan LyXMacros.patch Description: Binary data -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: What is missing for LyX 2.4?
> Am 04.05.2023 um 11:35 schrieb Jean-Marc Lasgouttes : > > Le 04/05/2023 à 03:39, Richard Kimberly Heck a écrit : >> The big issue is the OSX shortcut bug, which I'm still not clear about. I >> don't think anything else is a must-have. > > This one can be solved for now by building with Qt5, right? Yes, that’s my plan. > Is there anything good enough on Qt6 for macOS that makes this a bad option? I don’t think so. The only bad thing is to not switch major Qt release with „major“ LyX release. Stephan > It might be that the problem will solve itself with time. > > JMarc > > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: QRegExp is deprecated in qt6
Am 02.03.2023 um 22:44 schrieb Richard Kimberly Heck : > > On 3/2/23 12:29, Stephan Witt wrote: >> >> ATM, Qt6 is unusable on Mac because of bug 12641. :( > > Does this just mean you can't build with Qt6? Or is this a blocker for > release? No, this means I can build both with Qt5 or Qt6. But I don’t know how to fix the bug, so the release shouldn’t be done with Qt6. It would be a good move to switch to Qt6 with a major release of LyX. But if it is not possible it’s better to release it with Qt5. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: QRegExp is deprecated in qt6
Am 02.03.2023 um 15:57 schrieb Jean-Marc Lasgouttes : > > Le 20/02/2023 à 17:47, Jean-Marc Lasgouttes a écrit : >> Le 13/02/2023 à 21:29, Richard Kimberly Heck a écrit : > Indeed! So we should get rid of QRegexp now. Riki, would that be OK? What I have in mind is that whatever bug with this newer code will be found earlier if more users are running it. >>> >>> Yes, fine with me. >>> >>> I have been waiting to talk about next steps until we have some idea what >>> to do about the shortcut problem on OSX. That seems a large issue. >> This patch removes all traces of QRegExp. It will obviously need testing, >> but this is already the code used with Qt6. > > Riki, is this OK to apply? > >> What I do not know is whether we can get rid of QtCore5Compat library. Is it >> useful for anything beyond QRegExp? > > Enrico, Stephan Kornel, do you know something about needing QCore5Compat? ATM, Qt6 is unusable on Mac because of bug 12641. :( OTOH, Scott and Kornel mentioned QTextCodec already. So, there is some work to do. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Beta 2 Tarballs
Am 11.01.2023 um 19:44 schrieb Richard Kimberly Heck : > > Here: > > http://ftp.lyx.org/pub/lyx/devel/lyx-2.4/ > > Please produce binaries. I’ve built the binaries for Mac and put them here: https://my.hidrive.com/share/ydfg5l8ppq * build on BigSur for Intel and Apple chips (minimum macOS 10.14 with Qt 6.4.1). + LyX-2.4.0-beta2+qt6-x86_64-arm64-cocoa.dmg + LyX-2.4.0-beta2+qt6-x86_64-arm64-cocoa.dmg.sig * build on Mojave for Intel chips (minimum macOS 10.12 with Qt 5.12.9). + LyX-2.4.0-beta2+qt5-x86_64-cocoa.dmg + LyX-2.4.0-beta2+qt5-x86_64-cocoa.dmg.sig Best regards, Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Difference of two MacOS binaries for 2.3.7?
Am 11.01.2023 um 15:00 schrieb Koji Yokota : > > Dear list, > > Congratulations on the release of LyX 2.3.7! > > Could someone teach me the difference of two MacOS binaries for 2.3.7? There > are two binaries, > (A) LyX-2.3.7+qt5-x86_64-arm64-cocoa.dmg and > (B) LyX-2.3.7+qt5-x86_64-cocoa.dmg for older OS. > > Question is: > > - Does it mean binary (A) doesn't work on older OS's? Or can it be run on any > OS versions? > - If not, which version of OS is exactly the threshold of these two? - LyX-2.3.7+qt5-x86_64-arm64-cocoa.dmg * build on BigSur for Intel and Apple chips (minimum macOS 10.14 with Qt 5.15.7). - LyX-2.3.7+qt5-x86_64-cocoa.dmg * build on Mojave for Intel chips (minimum macOS 10.12 with Qt 5.12.9). Best regards, Stephan > I'm currently checking the validity of Homebrew formula and it would be > helpful if you give me the information. > > Thank you for your help. > > Koji Yokota > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Lyx 2.3.7 maxima
Am 09.01.2023 um 23:25 schrieb Dr Eberhard W Lisse : > > Hi, > > I just saw the lyx-maxima script being installed with the new lyx. It > refers to a maxima.sh, which I can't find if I intall the App or the > tools from homebrew. > > What does the maxima.sh script do? Can someone send me a copy of it, please? It’s part of the Maxima.app - you may download it from: https://sourceforge.net/projects/maxima/files/Maxima-MacOS/ Probably you’re asking because you’re in trouble? Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Shebang Lines
Am 08.01.2023 um 20:34 schrieb Dr Eberhard W Lisse : > > I didn't mean it just for that script. > > I like the bash that is first in my path. That’s what I don’t like. The script works as expected with Apples /bin/bash and there is no need to fix something what’s not broken. > I like the env method for all scripts (perl, bash, python lua and > whatnot). I can see the point for python. Not for bash. > And, since Apple apparently prefers zsh to bash as the default > shell nowadays it may just be that they will remove it like the > did with python some time in the future. I don’t think it will happen. This will break many scripts. Not just LyX. Stephan > > On 08/01/2023 20:04, Stephan Witt wrote: >> Am 07.01.2023 um 19:11 schrieb Richard Kimberly Heck : >>> >>> On 1/7/23 10:00, Dr Eberhard W Lisse wrote: >>>> I see the >>>> >>>>/Applications/LyX.app/Contents/MacOS/inkscape >>>> >>>> script has >>>> >>>>#!/bin/bash >>>> >>>> as the shebang. Can that please be changed (in all shell >>>> scripts) to read >>>> >>>>#!/usr/bin/env bash >>> >>> Stefan, is this harmless? >>> >>> Anyone else have thoughts about this? >> >> I think this is not needed. I wouldn’t change it. >> >> The only reason to use the #!/usr/bin/env xxx thing is >> portability. But this script is not intended to be portable. >> It’s for macOS. >> >> There are possible drawbacks to use the #!/usr/bin/env xxx >> thing. The least one is the indirection José already mentioned. >> The next one is the inability to say which bash will be >> executed. If $HOME/bin is in PATH and the is some executable >> named bash it is started by the env utility. Do you like that? >> >> See also discussions here: >> https://unix.stackexchange.com/questions/29608/why-is-it-better-to-use-usr-bin-env-name-instead-of-path-to-name-as-my >> >> Eberhard, why do you see any real benefit here? >> >> BR, >> Stephan > > -- > Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist > e...@lisse.na / * | Telephone: +264 81 124 6733 (cell) > PO Box 8421 Bachbrecht \ / If this email is signed with GPG/PGP > 10007, Namibia ;/ Sect 20 of Act No. 4 of 2019 may apply > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Shebang Lines
Am 07.01.2023 um 19:11 schrieb Richard Kimberly Heck : > > On 1/7/23 10:00, Dr Eberhard W Lisse wrote: >> I see the >> >> /Applications/LyX.app/Contents/MacOS/inkscape >> >> script has >> >> #!/bin/bash >> >> as the shebang. Can that please be changed (in all shell scripts) to read >> >> #!/usr/bin/env bash > > Stefan, is this harmless? > > Anyone else have thoughts about this? I think this is not needed. I wouldn’t change it. The only reason to use the #!/usr/bin/env xxx thing is portability. But this script is not intended to be portable. It’s for macOS. There are possible drawbacks to use the #!/usr/bin/env xxx thing. The least one is the indirection José already mentioned. The next one is the inability to say which bash will be executed. If $HOME/bin is in PATH and the is some executable named bash it is started by the env utility. Do you like that? See also discussions here: https://unix.stackexchange.com/questions/29608/why-is-it-better-to-use-usr-bin-env-name-instead-of-path-to-name-as-my Eberhard, why do you see any real benefit here? BR, Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: macOS python issue
Am 04.01.2023 um 23:53 schrieb Richard Kimberly Heck : > > On 1/4/23 06:53, Stephan Witt wrote: >> Am 03.01.2023 um 10:36 schrieb Stephan Witt : >>> Am 03.01.2023 um 10:29 schrieb Pavel Sanda : >>>> On Tue, Jan 03, 2023 at 10:20:22AM +0100, Stephan Witt wrote: >>>>> Now I???ve reduced the image sizes to reduce the screen clutter. >>>>> >>>>> Do you think it is ok? >>>> Looks fine to me. >>>> >>>> What might be good to put at the begining some (textual) examples how >>>> missing python >>>> displays itself (can't convert older lyx files, can't reconfigure, can't >>>> load images, etc...) >>>> so users can associate these problems with python missing. >>> Ok, I’ll make it. >>> >>>> The real solutions though is IMHO to detect python presence and issues >>>> warning for installation… >>> Yes, that I’ll try to do - I have some ideas now. >> Hi all, >> >> finally - although late in the game - I came up with a proposal to solve the >> problem with missing python on macOS. >> >> It’s described here: https://www.lyx.org/trac/ticket/12523 and in more depth >> here: https://wiki.lyx.org/Mac/Mac >> >> Please see the attached patch. You may wonder why there is no mac specific >> code. I think it’s not needed as the problem isn’t specific to the OS or >> platform. It is very unlikely to happen on Linux systems as most of them has >> package managers and if the dependencies are correct there is no problem >> like that. > > Yes, that seems right. This could happen on other platforms. > > >> Probably the message text of the new Alert box should be reworded. > > It seems fine, though I wonder if we could possibly point people towards a > solution? I pushed commit bbc2270972cfbb1aa11836498c8a6c73be91f18d with slightly improved message. >> If the solution looks right I’d like to see it in 2.3.8 too. > > Definitely. I'd even be willing to re-release 2.3.7, for Mac at least, with > this patch. A patch for 2.3.x is attached at https://www.lyx.org/trac/ticket/12523 I’ll adjust the wiki when it’s applied. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: macOS python issue
Am 03.01.2023 um 10:36 schrieb Stephan Witt : > Am 03.01.2023 um 10:29 schrieb Pavel Sanda : >> >> On Tue, Jan 03, 2023 at 10:20:22AM +0100, Stephan Witt wrote: >>> Now I???ve reduced the image sizes to reduce the screen clutter. >>> >>> Do you think it is ok? >> >> Looks fine to me. >> >> What might be good to put at the begining some (textual) examples how >> missing python >> displays itself (can't convert older lyx files, can't reconfigure, can't >> load images, etc...) >> so users can associate these problems with python missing. > > Ok, I’ll make it. > >> The real solutions though is IMHO to detect python presence and issues >> warning for installation… > > Yes, that I’ll try to do - I have some ideas now. Hi all, finally - although late in the game - I came up with a proposal to solve the problem with missing python on macOS. It’s described here: https://www.lyx.org/trac/ticket/12523 and in more depth here: https://wiki.lyx.org/Mac/Mac Please see the attached patch. You may wonder why there is no mac specific code. I think it’s not needed as the problem isn’t specific to the OS or platform. It is very unlikely to happen on Linux systems as most of them has package managers and if the dependencies are correct there is no problem like that. Probably the message text of the new Alert box should be reworded. If the solution looks right I’d like to see it in 2.3.8 too. Stephan macos-python.patch Description: Binary data -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: 2.3.7 Tarballs Available
Am 02.01.2023 um 00:53 schrieb Richard Kimberly Heck : > > Here: > > http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/ > > Note that I've named these files as 2.3.7-1, but did not do that in > configure.ac, since we did not release anything yet. > > Please build binaries. I’ve built the binaries for Mac and put them here: https://my.hidrive.com/share/qr1.dh8gbw * build on BigSur for Intel and Apple chips (minimum macOS 10.14 with Qt 5.15.7). + LyX-2.3.7+qt5-x86_64-arm64-cocoa.dmg + LyX-2.3.7+qt5-x86_64-arm64-cocoa.dmg.sig * build on Mojave for Intel chips (minimum macOS 10.12 with Qt 5.12.9). + LyX-2.3.7+qt5-x86_64-cocoa.dmg + LyX-2.3.7+qt5-x86_64-cocoa.dmg.sig Best regards, Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: State of Stable and Master?
Am 17.12.2022 um 20:43 schrieb Richard Kimberly Heck : > > Hi, all, > > In amongst the latest grading frenzy (thankfully coming to an end), I've lost > track of where we are with 2.3.7 and 2.4-beta2. I know there were build > issues of various kinds with both of them. Have these now been resolved? Or, > at least, do we think they have? That is, are we ready to go with rebuilding > and trying again? I’m able to build the binaries for macOS with current state now. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Suspicious warning for fake int in PreviewLoader.cpp
Am 16.12.2022 um 00:48 schrieb Richard Kimberly Heck : > > On 12/15/22 17:02, Stephan Witt wrote: >> Hi all, >> >> I’m seeing this warning with more modern Apple compilers for lyx-2.3.x: >> >> lyx-2.3.x/src/graphics/PreviewLoader.cpp:730:28: warning: result of '2^20' >> is 22; did you mean '1 << 20' (1048576)? [-Wxor-used-as-pow] >> static atomic_int fake((2^20) + 1); >> ~^~~ >> 1 << 20 >> lyx-2.3.x/src/graphics/PreviewLoader.cpp:730:28: note: replace expression >> with '0x2 ^ 20' or use 'xor' instead of '^' to silence this warning >> >> This was fixed in master. Shouldn’t the fix be backport to 2.3.x? > > I suppose, but I'm confused. Why is 2^20 = 22? Overflow? Or does ^ not mean > what I thought it did? The ^ operator is the bitwise exclusive or (XOR) - but the intended operation is probably power(2,20) aka 1 << 20. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Suspicious warning for fake int in PreviewLoader.cpp
Hi all, I’m seeing this warning with more modern Apple compilers for lyx-2.3.x: lyx-2.3.x/src/graphics/PreviewLoader.cpp:730:28: warning: result of '2^20' is 22; did you mean '1 << 20' (1048576)? [-Wxor-used-as-pow] static atomic_int fake((2^20) + 1); ~^~~ 1 << 20 lyx-2.3.x/src/graphics/PreviewLoader.cpp:730:28: note: replace expression with '0x2 ^ 20' or use 'xor' instead of '^' to silence this warning This was fixed in master. Shouldn’t the fix be backport to 2.3.x? Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: 2.3.7 Tarballs
Am 15.12.2022 um 17:02 schrieb Richard Kimberly Heck : > > On 12/15/22 02:33, Stephan Witt wrote: >> Am 11.12.2022 um 17:16 schrieb Richard Kimberly Heck : >>> Tarballs for 2.3.7 are here: >>> >>> http://www.frege.org/transfer/ >>> >>> Because my IP has changed, I can't (right now) upload them to the ftp >>> server. I'll do that when I can. >>> >>> Please build the binaries! >> On Mac I cannot build the binary package w/o modification. >> >> The Intel build needs the backport of >> b0a73c0dfdbfa0541f04d7ee2578c4cd272ef7b9. Ok to do so? >> The build for Apple M1 doesn’t find the Qt frameworks - I have to >> investigate. Sorry. > > No problem. I'm going to have to rebuild anyway, due to a problem on Windows. > Go ahead and backport. Ok, I did it now (and some other modifications to enable builds on Apple cpus). Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: 2.3.7 Tarballs
Am 11.12.2022 um 17:16 schrieb Richard Kimberly Heck : > > Tarballs for 2.3.7 are here: > > http://www.frege.org/transfer/ > > Because my IP has changed, I can't (right now) upload them to the ftp server. > I'll do that when I can. > > Please build the binaries! On Mac I cannot build the binary package w/o modification. The Intel build needs the backport of b0a73c0dfdbfa0541f04d7ee2578c4cd272ef7b9. Ok to do so? The build for Apple M1 doesn’t find the Qt frameworks - I have to investigate. Sorry. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Problems with lyx
Am 10.12.2022 um 11:59 schrieb Jacob Christian Hede Dahlgaard : > > Hi > > I have problems with making lyx work optimal. I get this message every time… > <0.png> > > But I have downloaded mactex on the Mac… and also lyx, what can I do? You’re probably on macOS Monterey or Ventura and there is no usable Python utility on your system. LyX is using it for configuration and internal converter tasks. You should have been asked to download and install it on the first run. If that’s the case you have two options now. A) Download and install the Apple Python utility (agree to do so if the question comes) or B) Download and install the Python utility from the Python developers. Best regards, Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Add OS version info to About box.
Am 07.12.2022 um 14:36 schrieb Pavel Sanda :
>
> On Tue, Dec 06, 2022 at 11:12:37PM +0100, Stephan Witt wrote:
>> commit a66ee4109ee84a4a501dbaa29580cdefe1aadd36
>> Author: Stephan Witt
>> Date: Wed Dec 7 00:08:11 2022 +0100
>>
>>Add OS version info to About box.
>> ---
>> src/frontends/qt/GuiAbout.cpp |6 ++
>> 1 files changed, 6 insertions(+), 0 deletions(-)
>>
>> diff --git a/src/frontends/qt/GuiAbout.cpp b/src/frontends/qt/GuiAbout.cpp
>> index d4173fa..16f8be4 100644
>> --- a/src/frontends/qt/GuiAbout.cpp
>> +++ b/src/frontends/qt/GuiAbout.cpp
>> @@ -294,6 +294,12 @@ static QString version(bool const plain = false)
>> out << '\n';
>> else
>> out << "";
>> +out << toqstr(bformat(_("OS Version (run-time): %1$s"),
>> +qstring_to_ucs4(QSysInfo::prettyProductName(;
>
> This function was introduced in Qt 5.4. Until we agree on specific minor
> version
> I'd put it within ifdefs…
I did it now. (The style of version check here is not consistent. I decided to
use the more readable style.)
Stephan
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: About upgrading to MacOS 13
Am 07.12.2022 um 16:21 schrieb Daniel CLEMENT via lyx-users : > > Dear list members, > > I have monitored last month’s threads about LyX woes under macOS 13. There > wasn’t a definite conclusion it seems. > > Would you say it’s safe to upgrade to MacOS13 now (with LyX 2.3.6.2)? > > When I installed it, it complained about Python missing, but I somehow > managed to get Python installed too. > > I’m rather new to Mac, and in no hurry at all to do the upgrade. Perhaps it > would be best to wait for LyX 2.4? > > I’ll take your advice - best regards, Hi Daniel, I’m on Mojave for production as primary macOS (because I’m using Aperture from Apple - a 32bit application w/o 64bit upgrade option!). I have access to a M1 system with Big Sur for development builds of LyX. I don’t want to upgrade because I’ll loose the option to test LyX on Big Sur. I’ve tested LyX 2.3.6.2 on different VMs with macOS 12.x and didn’t have time and resources to try macOS 13 yet. My experience is: starting with Monterey 12.3 Apple dropped the support for Python 2.x and the upgrade from earlier versions removes it. There is a replacement Python 3 installed as a stub and if this gets called it asks the user to download and install the real thing from Apple. There is one report of having a problem after upgrade from Monterey to Ventura (macOS 13) with Python again. I couldn’t get the information how this happened. Probably the upgrade to Ventura breaks the installed Python 3 from Apple. One has to reinstall it manually. All this is a consequence of Apples decision to pass the responsibility for a working Python software to app developers and/or end users. So they cannot be blamed for security problems with it, IMO. It makes no sense to include a Python package with LyX and therefore it is ok to install either Apples or the „official“ open-source Python for Apple on the system. It’s an open task to detect the current situation on the users system and give more prominent and useful advice how to proceed. There is another issue I’m aware of. On some systems the gatekeeper keeps nagging and says the LyX binary is a suspicious one. Probably it’s because of the bundle permissions, the certificate used for signing or the security settings of users system. My advice would be to try the upgrade if you’re able to go back with time machine w/o hassle. I’ll be there to answer questions and help to solve problems. If you don’t want to risk anything I can understand it and you may wait for the results of my experiments in a virtual machine. Another option is to create a virtual machine yourself and try it there and contact me if something is broken. Hope that helps and regards, Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [PATCH] Allow removing words from the personal dictionary, that weren't previously added
Am 21.11.2022 um 19:00 schrieb Jürgen Spitzmüller : > > Am Montag, dem 21.11.2022 um 18:53 +0100 schrieb Stephan Witt: >> Not easy, this would require to rewrite the spell check chunk split >> algorithm. >> >> ATM the complete paragraph is passed to the Apple spell checker at >> once. >> Obviously it won’t mark the unlearned word as misspelled in this >> case. >> So LyX has to iterate in a 2nd pass over the paragraph and find the >> unlearned words. >> I’d rather suggest the person who wants that to switch to the >> Hunspell engine. > > OK, fair enough. > >>> >> Yes, but I’d propose to add more values. >> At least UNLEARNED for exclude list and IGNORED for NO_SPELLCHECK >> font. > > OK. > >>>>>> 2. There is no context menu option to revert the >>>>>> LFUN_FONT_NO_SPELLCHECK. >>>>>> One may use the font options dialog - but opening it resets >>>>>> the >>>>>> NO_SPELLCHECK from word immediately. >>>>> >>>>> There is: "Ignore This Occurrence". It shows when opening the >>>>> context >>>>> menu upon a misspelled word. This triggers the LFUN. >>>> >>>> Yes, but the „Unignore“ option is not in drop-down menu. >>> >>> What do you mean by "drop-down" menu? It is in the context menu and >>> in >>> the spell checker dialog. >> >> >> Sorry - I meant the context menu. >> >>>> The font options dialog resets NO_SPELLCHECK on open. >>> >>> Not here. >> >> Here it is missing because of the spellcheck of the marked word >> returns OK. >> With the enum expansion mentioned above it would be possible to >> handle that. >> >> I don’t understand why we have different behavior here… see screen >> shots below. > > Strange. Something seems wrong in the Apple spellchecker chain. Is this > also without your patches? Yes. It is the same w/o the patches. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Apply downstream macport patch?
Am 07.12.2022 um 00:38 schrieb Stephan Witt : > > Am 04.12.2022 um 16:28 schrieb Scott Kostyshak : >> >> On Thu, Dec 01, 2022 at 05:35:43PM +0100, Jean-Marc Lasgouttes wrote: >>> Le 01/12/2022 à 16:25, Scott Kostyshak a écrit : >>>> The following is a patch that (I think?) macports applies. I don't >>>> understand it at all, but is it something we want? >>>> >>>> https://github.com/macports/macports-ports/blob/master/aqua/LyX/files/patch-lyx-linkbackserver-older-nsalert.diff >>>> >>>> Does 101200 correspond to a macOS version that we will support for 2.4.0? > > The patch ensures to compile and link LyX for macOS versions before 10.12 > (Sierra as of 2016) (10.11 is El Capitan). > > The use of these systems is not recommended, AFAIK. > >>> This closes the following ticket >>> https://trac.macports.org/ticket/61108 >> >> Stephan, any thoughts? > > Yes. > > 1. IMO, the link back server is a problem with Apple sandbox strategy in > general. > See e.g. https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg200962.html > > 2. I cannot see any movement with the project. > https://www.linkbackproject.org/about/ > > 3. E.g. Qt 5.12 don’t support macos less than 10.12 too > https://doc.qt.io/archives/qt-5.12/macos.html > > I think this patch isn’t critical - but it wouldn’t hurt either. BTW: If I try to build LyX 2.4 with minimum os version 10.11 I get this: /Users/lyx/git/lyx/src/insets/ExternalTransforms.cpp:334:20: error: 'any_cast > (std::__1::basic_string)> >' is unavailable: introduced in macOS 10.14 Factory factory = any_cast(any_factory); Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Apply downstream macport patch?
Am 04.12.2022 um 16:28 schrieb Scott Kostyshak : > > On Thu, Dec 01, 2022 at 05:35:43PM +0100, Jean-Marc Lasgouttes wrote: >> Le 01/12/2022 à 16:25, Scott Kostyshak a écrit : >>> The following is a patch that (I think?) macports applies. I don't >>> understand it at all, but is it something we want? >>> >>> https://github.com/macports/macports-ports/blob/master/aqua/LyX/files/patch-lyx-linkbackserver-older-nsalert.diff >>> >>> Does 101200 correspond to a macOS version that we will support for 2.4.0? The patch ensures to compile and link LyX for macOS versions before 10.12 (Sierra as of 2016) (10.11 is El Capitan). The use of these systems is not recommended, AFAIK. >> This closes the following ticket >> https://trac.macports.org/ticket/61108 > > Stephan, any thoughts? Yes. 1. IMO, the link back server is a problem with Apple sandbox strategy in general. See e.g. https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg200962.html 2. I cannot see any movement with the project. https://www.linkbackproject.org/about/ 3. E.g. Qt 5.12 don’t support macos less than 10.12 too https://doc.qt.io/archives/qt-5.12/macos.html I think this patch isn’t critical - but it wouldn’t hurt either. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Put OS information in Help > About > Version ?
Am 06.12.2022 um 22:12 schrieb Pavel Sanda : > > On Tue, Dec 06, 2022 at 12:25:53PM -0500, Scott Kostyshak wrote: >> For a macOS user, can we tell whether they are on Ventura or not? > > I???ll try QSysInfo::productVersion() ??? This will show up like that: With Ventura it should be: 13.0 >>> >>> This would be the patch w/o I18N ??? >> >> Tested and works well here! I would say commit (unless someone else >> disagrees). >> >> For me, the version showed up as "22.04". I actually expected my kernel >> version to show up. > > I guess that's what QSysInfo::kernelType() is for. > Anyway quickly checking members of QSysInfo you might actually > want to use QSysInfo::prettyProductName(). Indeed. This prints "macOS Mojave (10.14)“ here. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Put OS information in Help > About > Version ?
Am 06.12.2022 um 18:08 schrieb Stephan Witt : > > Am 06.12.2022 um 17:15 schrieb Stephan Witt : >> >> Am 06.12.2022 um 16:34 schrieb Scott Kostyshak : >>> >>> On Sun, Dec 04, 2022 at 10:13:11PM +0100, Jean-Marc Lasgouttes wrote: >>>> Le 04/12/2022 à 21:41, Scott Kostyshak a écrit : >>>>> When collecting information, it might be nice to have OS information. >>>>> That way, the user only has to go to Help > About and click on "Copy >>>>> Version Info" and all important information is copied; rather than >>>>> having to ask them to separately state it. >>>>> >>>>> Is it OK if I add OS information? I'm not sure when I will get around to >>>>> actually doing it but since it came up now I thought I would ask. >>>> >>>> Note that in the About LyX dialog, we have platform which gives the GUI >>>> information. What else would you like? >>> >>> For a macOS user, can we tell whether they are on Ventura or not? >> >> I’ll try QSysInfo::productVersion() … > > This will show up like that: > > > > With Ventura it should be: 13.0 This would be the patch w/o I18N … Stephan GuiAbout.patch Description: Binary data -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Put OS information in Help > About > Version ?
Am 06.12.2022 um 17:15 schrieb Stephan Witt : > > Am 06.12.2022 um 16:34 schrieb Scott Kostyshak : >> >> On Sun, Dec 04, 2022 at 10:13:11PM +0100, Jean-Marc Lasgouttes wrote: >>> Le 04/12/2022 à 21:41, Scott Kostyshak a écrit : >>>> When collecting information, it might be nice to have OS information. >>>> That way, the user only has to go to Help > About and click on "Copy >>>> Version Info" and all important information is copied; rather than >>>> having to ask them to separately state it. >>>> >>>> Is it OK if I add OS information? I'm not sure when I will get around to >>>> actually doing it but since it came up now I thought I would ask. >>> >>> Note that in the About LyX dialog, we have platform which gives the GUI >>> information. What else would you like? >> >> For a macOS user, can we tell whether they are on Ventura or not? > > I’ll try QSysInfo::productVersion() … This will show up like that: With Ventura it should be: 13.0 Stephan-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Put OS information in Help > About > Version ?
Am 06.12.2022 um 16:34 schrieb Scott Kostyshak : > > On Sun, Dec 04, 2022 at 10:13:11PM +0100, Jean-Marc Lasgouttes wrote: >> Le 04/12/2022 à 21:41, Scott Kostyshak a écrit : >>> When collecting information, it might be nice to have OS information. >>> That way, the user only has to go to Help > About and click on "Copy >>> Version Info" and all important information is copied; rather than >>> having to ask them to separately state it. >>> >>> Is it OK if I add OS information? I'm not sure when I will get around to >>> actually doing it but since it came up now I thought I would ask. >> >> Note that in the About LyX dialog, we have platform which gives the GUI >> information. What else would you like? > > For a macOS user, can we tell whether they are on Ventura or not? I’ll try QSysInfo::productVersion() … Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: State of the killqt4 branch (Stephan?)
Am 25.11.2022 um 00:55 schrieb Stephan Witt : > > Am 25.11.2022 um 00:29 schrieb Jean-Marc Lasgouttes : >> >> Le 25/11/2022 à 00:18, Stephan Witt a écrit : >>> This is a profiler run with Apple Instruments - I built the LyX binary for >>> profiling. >>> https://my.hidrive.com/share/6t6dr1c.4o >>> The experiment was to open the german tutorial and start scrolling from top >>> to bottom and back to top. >>> The left side is the profiler run with cache and the opposite side is >>> without cache. Sorry, I didn’t say what I’ve used for it. The code is the master branch from origin. I’ve built it with a Xcode project created by cmake and self compiled Qt 6.3.1 frameworks (release mode). The system is MacBook Pro (15 Zoll, 2019) with macOS 10.14.6 Mojave, 2.4 GHz Intel Core i9, Radeon Pro 560X 4GB graphics. Stephan >> >> What is the difference between the two images you uploaded. > > The deepness of the open call graph is different. The 2nd shows more details > inside of the getTextLayout_helper function. > >> It seems that the cache is needed. Can you make a view where all the >> versions of getTextLayout are visible? There is a second one that uses a >> TextLayoutHelper parameter. > > I'm not sure how to do that - this is an excerpt of the heaviest stack trace. > > I’ve changed the filter from „matches all“ to „matches any“ (?) and then I > tried to locate examples of these. > > The result is the 3rd image now. > >> It seems anyway that the cache should be kept on a mac. > > Yes. It seems so. > > Stephan > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: State of the killqt4 branch (Stephan?)
Am 25.11.2022 um 00:29 schrieb Jean-Marc Lasgouttes : > > Le 25/11/2022 à 00:18, Stephan Witt a écrit : >> This is a profiler run with Apple Instruments - I built the LyX binary for >> profiling. >> https://my.hidrive.com/share/6t6dr1c.4o >> The experiment was to open the german tutorial and start scrolling from top >> to bottom and back to top. >> The left side is the profiler run with cache and the opposite side is >> without cache. > > What is the difference between the two images you uploaded. The deepness of the open call graph is different. The 2nd shows more details inside of the getTextLayout_helper function. > It seems that the cache is needed. Can you make a view where all the versions > of getTextLayout are visible? There is a second one that uses a > TextLayoutHelper parameter. I'm not sure how to do that - this is an excerpt of the heaviest stack trace. I’ve changed the filter from „matches all“ to „matches any“ (?) and then I tried to locate examples of these. The result is the 3rd image now. > It seems anyway that the cache should be kept on a mac. Yes. It seems so. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: State of the killqt4 branch (Stephan?)
Am 24.11.2022 um 17:32 schrieb Jean-Marc Lasgouttes : > > What would be great is to find the discussion that led to this change. I > tried a bit, but did not succeed. > > Yes scrolling around in user guide is not bad. > > Uncomment DISABLE_PMPROF at the start of the file and run with a release or > profile build. > > JMarc This is a profiler run with Apple Instruments - I built the LyX binary for profiling. https://my.hidrive.com/share/6t6dr1c.4o The experiment was to open the german tutorial and start scrolling from top to bottom and back to top. The left side is the profiler run with cache and the opposite side is without cache. Stephan >>> What would remain is the code in GuiFontMetrics.cpp. The best is to use the >>> existing instrumentation using pmprof. >> >> Ok, what is the use case to look for? Just scrolling around? What document >> size and complexity should I choose? >> >> Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: State of the killqt4 branch (Stephan?)
Am 24.11.2022 um 12:20 schrieb Jean-Marc Lasgouttes : > > Le 23/11/2022 à 22:41, Stephan Witt a écrit : >> I’m alive but not able to react right now. Sorry. >> This week I cannot spend enough time to dive into LyX issues. >> Next week I'll start with checkout of the branch and contribute code. > > If you are confident that you can have a look next week, then I'll wait for > you. > > The other solution is to merge the branch now, since we know that you will > have to update everything before next release. > > What would remain is the code in GuiFontMetrics.cpp. The best is to use the > existing instrumentation using pmprof. Ok, what is the use case to look for? Just scrolling around? What document size and complexity should I choose? Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: State of the killqt4 branch (Stephan?)
Am 22.11.2022 um 17:21 schrieb Jean-Marc Lasgouttes : > > Le 20/11/2022 à 21:12, Jean-Marc Lasgouttes a écrit : >> Dear all, >> I think I have done everything I can do on the branch (actually I just >> noticed a few remnants in config/, I will handle that). > > Hello Stephan, > > Following the heroic effort of Kornel, most of what remains needs the > attention of Stephan : > > The last FIXME KILLQT4 in the source, to know whether we still need to > cache QTextLayout objects in Qt/Mac. They are correctly cached by Qt on > other platforms (see commit 5354c64b273eac7b8). > > development/LyX-Mac-binary-release.sh mentions qt4 too. > > INSTALL.cmake > INSTALL.MacOSX (time to rename this one?) Hi JMarc, I’m alive but not able to react right now. Sorry. This week I cannot spend enough time to dive into LyX issues. Next week I'll start with checkout of the branch and contribute code. BR, Stephan > I propose that we just let the following rot: >> development/autotests/keytest.py >> development/keystest/report_html.sh >> development/keystest/setup.sh >> development/lyx.rpm.README >> development/lyxserver/server_monitor.cpp >> development/tools/count_lines_of_included_code.sh >> development/tools/count_total_lines_of_compiled_code.sh >> development/tools/numbers > > JMarc > -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [PATCH] Allow removing words from the personal dictionary, that weren't previously added
Am 20.11.2022 um 12:01 schrieb Jürgen Spitzmüller : > > Am Mittwoch, dem 16.11.2022 um 07:55 +0100 schrieb Stephan Witt: >> I’ve made two patches on top of Isaacs patch to make it work again on >> Mac. >> See attached patches. 1st one is the patch from Isaac, 2nd and 3rd >> are mine. > > Thanks! > >> 1. There are code paths with SpellChecker::WORD_OK with WordLangTuple >> not being assigned anywhere. >> IMO a check for it is required to avoid a crash when using the lang >> pointer later. > > Shouldn't you rather (or additionally) check for !wl.lang()? Or is it > clear that !wl.word.empty() means we have a lang() pointer? Yes, actually it is clear. But an additionally check for !wl.lang() is more save. >> 2. Spell checkers in paragraph check mode (Apple) aren’t using the >> exclude word list at all. >> IMO it's the right thing to skip the option to add words to the >> exclude word list then. > > But don't you disable the removal from Apple's personal dictionary > (AppleSpellChecker::remove) with this as well? Didn't this work before > the patch? Yes, it never worked before. If unlearnWord is called it has an effect for learned words only. There is no call interface to unlearn a word in main dictionary. >> Please test and give feedback for it… >> >> I’ve noticed two additional problems while testing: >> >> 1. The new feature with exclude word lists doesn’t work for me with >> Hunspell. >> But this may be a defect of my private hunspell framework. > > It works for me with Hunspell (note that the lists are only saved upon > LyX closure). > > What I find odd, though, is the naming in the menu. When I click on a > word that is in the main dictionary, e.g. "table", it offers me to > "Remove from personal dictionary". But this is wrong. It doesn't remove > it from any dictionary, but adds it on personal exclusion list. So the > menu entry here should read "Treat this word as incorrect". > > Likewise, if I "un-ignore" such a word, the menu offers me to "Add to > personal dictionary". This is wrong as well. Should read > "Don't treat this word as incorrect“. Yes, this probably is an effect of the handling of the spell checker result in LyXs hunspell interface implementation. The solution would be to add and use more SpellChecker::Result values in HunspellChecker::check() to get the option to differentiate here. >> 2. There is no context menu option to revert the >> LFUN_FONT_NO_SPELLCHECK. >> One may use the font options dialog - but opening it resets the >> NO_SPELLCHECK from word immediately. > > There is: "Ignore This Occurrence". It shows when opening the context > menu upon a misspelled word. This triggers the LFUN. Yes, but the „Unignore“ option is not in drop-down menu. The font options dialog resets NO_SPELLCHECK on open. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [PATCH] Allow removing words from the personal dictionary, that weren't previously added
Am 25.10.2022 um 09:19 schrieb Jürgen Spitzmüller : > > I'd like this nice feature not to be forgotten. > > Stephan, do you think the problems on Mac can be resolved? Could we add > the patch with Mac support disabled for the time being? > > Thanks, > Jürgen I’ve made two patches on top of Isaacs patch to make it work again on Mac. See attached patches. 1st one is the patch from Isaac, 2nd and 3rd are mine. 1. There are code paths with SpellChecker::WORD_OK with WordLangTuple not being assigned anywhere. IMO a check for it is required to avoid a crash when using the lang pointer later. 2. Spell checkers in paragraph check mode (Apple) aren’t using the exclude word list at all. IMO it's the right thing to skip the option to add words to the exclude word list then. Please test and give feedback for it… I’ve noticed two additional problems while testing: 1. The new feature with exclude word lists doesn’t work for me with Hunspell. But this may be a defect of my private hunspell framework. 2. There is no context menu option to revert the LFUN_FONT_NO_SPELLCHECK. One may use the font options dialog - but opening it resets the NO_SPELLCHECK from word immediately. BR, Stephan > Am Montag, dem 30.05.2022 um 06:39 + schrieb Isaac Oscar Gariano: >> Dear Stephen, >> Sorry for the delay, I had other pressing work to do. >> Thank you so much for looking at my patch! >> >> What exactly was the problem on MacOSX? Where you getting compilation >> errors? >> >> I just noticed the following line in src/AppleSpellChecker.cpp: >>> status == SPELL_CHECK_LEARNED ? LEARNED_WORD : WORD_OK ; >> Which I should've changed to: >> WORD_OK ; >> >> If you can try and compile it and test it for me that would be great! >> Although I'll try getting myself a Mac VM so I can do so myself. >> >> The way the text is passed in chunks should hopefully not be a >> problem, >> the main problem I see is what happens when you call this >> method https://developer.apple.com/documentation/appkit/nsspellchecke >> r/1525147-unlearnword when you haven't previously >> called https://developer.apple.com/documentation/appkit/nsspellchecke >> r/1534837-learnword >> >> The documentation dosen't explain sadly. >> If my code doesn't work, I could always write a post-processing loop >> to check for unlearned words, (which will be slower). >> In fact that's pretty much what I made the Hunspell/Aspell backends >> do. >> >> I should probably do some performance testing, but I've been using >> this patch for a while now and haven't noticed any extra lag in spell >> checking. >> >> >> >> — Isaac Oscar Gariano >> From: Stephan Witt >> Sent: Monday, 16 May 2022 2:07 AM >> To: Isaac Oscar Gariano >> Cc: lyx-devel@lists.lyx.org >> Subject: Re: [PATCH] Allow removing words from the personal >> dictionary, that weren't previously added >> >> Am 26.04.2022 um 09:27 schrieb Isaac Oscar Gariano >> : >>> >>> I've made the "Remove from personal dictionary" function/context >>> menu item work for words that haven't been previously added, but >>> instead are in the system-wide dictionary. >>> I've modified the behaviour so that it will cause the word to be >>> marked as incorrectly spelt, regardless of whether it is in the >>> user's personal dictionary, or the system-wide dictionary. >>> I've attached two patches, one that can be applied on the latest >>> release branch 2.3.6.1, and the other works on the master branch) >>> >>> Previously, this only worked for words not in the system-wide >>> dictionary, e.g.: >>> • write "ello", it will be red squiggly underlined >>> • right click and go "Add to personal dictionary" >>> • now the underline will disappear >>> • right click it and go "Remove from personal dictionary" >>> • it will now be red underlined again >>> Now you can also do: >>> • write "hello" >>> • right click on it, and click "Remove from personal >>> dictionary" >>> • there should now be a red squiggly underline under >>> "hello", i.e. it is no longer considered a word >>> (The above also works with the corresponding lyx-functions >>> spelling-add and spelling-remove) >>> It might be better to change the text of the context menu button, >>> e.g., "Add to personal bad words list" or something, but then it'd >>> need to be transl
Re: LyX on macOS
Am 11.11.2022 um 12:47 schrieb Kornel Benko : > > Beginn der weitergeleiteten Nachricht: > > Datum: Fri, 11 Nov 2022 11:45:32 +0100 > Von: Herbert Voss > An: kor...@lyx.org > Betreff: LyX on macOS > > > Hallo Kornel, > > kannst du das mal an die devel-Liste weiterleiten. > Ich bin nicht auf der Liste und es kümmert sich wohl > keiner um das Weiterleiten bei Nicht-Teilnehmern ... > > Gruß > Herbert Hallo Herbert, das wird mit LyX 2.3.7 behoben sein. Sorry, ich habe mich mit der Beschreibung in der Version geirrt. In der letzten öffentlichen Version - 2.3.6.2 - ist es leider noch nicht korrigiert. Der Bericht dazu ist im Ticket https://www.lyx.org/trac/ticket/12305. BG Stephan > > > > Weitergeleitete Nachricht > Betreff: LyX on macOS > Datum:Sat, 5 Nov 2022 08:30:59 +0100 > Von: Herbert Voss > An: lyx-de...@ly.org > > > > Hello all, > > I have a case sensitive file system on my Mac. This is > the reason why I have to link > > QtDBus.framework -> QtDbus.framework > > in fact of the wrong file name (lowercase b). This is > not a problem on the deafult macOS filesystem which > is case _in_sensitive. > > You should correct the filename to get rid of the link. > > Herbert > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX on macOS
Am 11.11.2022 um 12:47 schrieb Kornel Benko : > > Beginn der weitergeleiteten Nachricht: > > Datum: Fri, 11 Nov 2022 11:45:32 +0100 > Von: Herbert Voss > An: kor...@lyx.org > Betreff: LyX on macOS > > > Hallo Kornel, > > kannst du das mal an die devel-Liste weiterleiten. > Ich bin nicht auf der Liste und es kümmert sich wohl > keiner um das Weiterleiten bei Nicht-Teilnehmern ... > > Gruß > Herbert Hallo Herbert, das sollte mit LyX 2.3.6.2 eigentlich behoben sein. BG Stephan > > > > Weitergeleitete Nachricht > Betreff: LyX on macOS > Datum:Sat, 5 Nov 2022 08:30:59 +0100 > Von: Herbert Voss > An: lyx-de...@ly.org > > > > Hello all, > > I have a case sensitive file system on my Mac. This is > the reason why I have to link > > QtDBus.framework -> QtDbus.framework > > in fact of the wrong file name (lowercase b). This is > not a problem on the deafult macOS filesystem which > is case _in_sensitive. > > You should correct the filename to get rid of the link. > > Herbert > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [PATCH] Allow removing words from the personal dictionary, that weren't previously added
Am 25.10.2022 um 09:19 schrieb Jürgen Spitzmüller : > > I'd like this nice feature not to be forgotten. > > Stephan, do you think the problems on Mac can be resolved? Could we add > the patch with Mac support disabled for the time being? I’ll review the patch again and post a modified version here. Thanks for the reminder. Stephan > > Thanks, > Jürgen > > Am Montag, dem 30.05.2022 um 06:39 + schrieb Isaac Oscar Gariano: >> Dear Stephen, >> Sorry for the delay, I had other pressing work to do. >> Thank you so much for looking at my patch! >> >> What exactly was the problem on MacOSX? Where you getting compilation >> errors? >> >> I just noticed the following line in src/AppleSpellChecker.cpp: >>> status == SPELL_CHECK_LEARNED ? LEARNED_WORD : WORD_OK ; >> Which I should've changed to: >> WORD_OK ; >> >> If you can try and compile it and test it for me that would be great! >> Although I'll try getting myself a Mac VM so I can do so myself. >> >> The way the text is passed in chunks should hopefully not be a >> problem, >> the main problem I see is what happens when you call this >> method https://developer.apple.com/documentation/appkit/nsspellchecke >> r/1525147-unlearnword when you haven't previously >> called https://developer.apple.com/documentation/appkit/nsspellchecke >> r/1534837-learnword >> >> The documentation dosen't explain sadly. >> If my code doesn't work, I could always write a post-processing loop >> to check for unlearned words, (which will be slower). >> In fact that's pretty much what I made the Hunspell/Aspell backends >> do. >> >> I should probably do some performance testing, but I've been using >> this patch for a while now and haven't noticed any extra lag in spell >> checking. >> >> >> >> — Isaac Oscar Gariano >> From: Stephan Witt >> Sent: Monday, 16 May 2022 2:07 AM >> To: Isaac Oscar Gariano >> Cc: lyx-devel@lists.lyx.org >> Subject: Re: [PATCH] Allow removing words from the personal >> dictionary, that weren't previously added >> >> Am 26.04.2022 um 09:27 schrieb Isaac Oscar Gariano >> : >>> >>> I've made the "Remove from personal dictionary" function/context >>> menu item work for words that haven't been previously added, but >>> instead are in the system-wide dictionary. >>> I've modified the behaviour so that it will cause the word to be >>> marked as incorrectly spelt, regardless of whether it is in the >>> user's personal dictionary, or the system-wide dictionary. >>> I've attached two patches, one that can be applied on the latest >>> release branch 2.3.6.1, and the other works on the master branch) >>> >>> Previously, this only worked for words not in the system-wide >>> dictionary, e.g.: >>> • write "ello", it will be red squiggly underlined >>> • right click and go "Add to personal dictionary" >>> • now the underline will disappear >>> • right click it and go "Remove from personal dictionary" >>> • it will now be red underlined again >>> Now you can also do: >>> • write "hello" >>> • right click on it, and click "Remove from personal >>> dictionary" >>> • there should now be a red squiggly underline under >>> "hello", i.e. it is no longer considered a word >>> (The above also works with the corresponding lyx-functions >>> spelling-add and spelling-remove) >>> It might be better to change the text of the context menu button, >>> e.g., "Add to personal bad words list" or something, but then it'd >>> need to be translated >>> >>> >>> The main use cases I have for this feature are: >>> • removing rare words that are common misspellings, e.g., >>> if you often write "whet" instead of "wet", you can mark the former >>> as invalid. >>> • ensure you consistently use the same variant of a word , >>> e.g., make "spelled" an error if you prefer "spelt" (the latter >>> being a word in the en_GB dictionary) >>> This change is backwards compatible: any words you had previously >>> added to the personal dictionary will still be recognised. >>> >>> I have fully tested this on Linux (specifically OpenSUSE >>> Tumbleweed, with Aspell v0.60.8, Enchant v2.2.15, and, Hunspell &
Re: [RFC][PATCH] Improved synctex support
Am 14.09.2022 um 20:17 schrieb Enrico Forestieri : > > On Sun, Aug 14, 2022 at 11:44:52PM +0200, Enrico Forestieri wrote: >> >> Only a suggestion: I would simply check for "-synctex=" rather than >> "--synctex=1" because the double dash is optional and any value >> different from 0 would do (I don't think someone would specify it). > > I did that at 90551a03. Thank you. I forgot about it :( - sorry. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Compile fail
Am 01.09.2022 um 22:00 schrieb Stephan Witt : > > Am 01.09.2022 um 19:40 schrieb Christopher Menzel : >> >> LyX folk: >> >> I’ve successfully compiled LyX from sources under Linux but my attempts to >> do so under MacOS for my M1 Macs (since I don’t want to use Rosetta 2). I >> installed QT5 using homebrew and I’m using what seem to me to be the right >> flags for the configure script, viz., > > Hi Chris, > > I’d recommend to build in a dedicated sibling directory of your LyX sources. > But this is not your problem, IMO. > >> % ./configure --enable-qt5 --with-version-suffix=-2.3 --with-x=no >> --with-qt-dir=/opt/homebrew/opt/qt5/ >> >> but I keep getting the following error: >> >>> checking for Qt library name... failed >>> configure: error: cannot compile a simple Qt executable. Check you have the >>> right $QTDIR. >> >> I’ve tried adding both “bin” and “lib” to the QT5 path but to no avail. I >> can’t afford to spend a ton of time on this but if there is something easy >> and obvious I’m missing that might solve the problem I’d appreciate hearing >> about it! > > I see no obvious problem. But I may see it if you send me the configure.log > (in PM as it may big). Sorry, it’s name is config.log Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Compile fail
Am 01.09.2022 um 19:40 schrieb Christopher Menzel : > > LyX folk: > > I’ve successfully compiled LyX from sources under Linux but my attempts to do > so under MacOS for my M1 Macs (since I don’t want to use Rosetta 2). I > installed QT5 using homebrew and I’m using what seem to me to be the right > flags for the configure script, viz., Hi Chris, I’d recommend to build in a dedicated sibling directory of your LyX sources. But this is not your problem, IMO. > % ./configure --enable-qt5 --with-version-suffix=-2.3 --with-x=no > --with-qt-dir=/opt/homebrew/opt/qt5/ > > but I keep getting the following error: > >> checking for Qt library name... failed >> configure: error: cannot compile a simple Qt executable. Check you have the >> right $QTDIR. > > I’ve tried adding both “bin” and “lib” to the QT5 path but to no avail. I > can’t afford to spend a ton of time on this but if there is something easy > and obvious I’m missing that might solve the problem I’d appreciate hearing > about it! I see no obvious problem. But I may see it if you send me the configure.log (in PM as it may big). Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Improved synctex support
Am 13.08.2022 um 17:34 schrieb Pavel Sanda : > > On Sat, Aug 13, 2022 at 02:41:30AM +0200, Enrico Forestieri wrote: >>> 2) >>> The LFUN_FORWARD_SEARCH implementation relies on the correct check in >>> getStatus. The patch adds the explicit check for presence of current >>> buffer and active output_sync state. Regarding the latter I???m not sure >>> if someone is unhappy with it. In case of preamble code to activate >>> synctex the LFUN_FORWARD_SEARCH would work but LyX doesn???t know that >>> and it???s disabled. What is your opinion here? >> >> You can always initiate a forward search by simply defining the pdflatex >> converter as "pdflatex --synctex=1 $$i", without any modification to the >> sources. Now I have lost this possibility. > > Apart from reverting that maybe adding optional "force" argument ot the lfun > would solve it for you? > Pavel I’ve pushed an enhancement with converter check instead of revert it. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Runtime error (macOS)
Am 13.08.2022 um 10:56 schrieb Christoph Schmitz : > > I deleted my local LyX repository and cloned it again from Git. Now LyX works > again. I should have tried that before. > > Stephan, I have seen that you are one of the co-authors of the INSTALL.MacOSX > file. This file contains a lot of information for older systems. Have you > ever considered to update the document to cover current machines and newer Qt > and macOS versions? Yes, and I’ve promised it already :( and never finished it. > That's the way it currently works for me (on macOS 13.0 Beta 5 Ventura on > both platforms, AMD64 and ARM64): > > - Qt6, automake, gettext, and pkgconfig are installed with Homebrew. > - LyX is cloned from Git. > - Cd into LyX folder. This I wouldn’t recommend. Making a separate build directory makes it easier to start over from scratch (or do a bisect :). > ./autogen.sh > > ./configure \ > --with-version-suffix=-2.4 \ > --prefix=/Users/chris/Desktop/LyX.app \ > --with-x=no \ > --disable-stdlib-debug \ > --with-included-hunspell \ > --with-libiconv-prefix=/usr \ > --enable-qt6 \ > --with-macos-deployment-target=12.0 > > make -j8 && make install-strip The resulting app is usable for you only. It neither can be started on another CPU-arch nor can it run on a system without Homebrew+Qt6. But of course you can work with it. I’m building Qt with frameworks myself (as universal bundles on M1) and build an LyX app with these frameworks included (on a M1 system with M1 and Intel CPU). I’ll document this procedure the next weeks. BR, Stephan >> Am 13.08.2022 um 09:37 schrieb Stephan Witt : >> >> Am 13.08.2022 um 09:26 schrieb Christoph Schmitz : >>> >>> Since a few days I get the following error message when starting a newly >>> compiled version of LyX: >>> >>> Unable to determine the system directory having searched >>> /Users/chris/Desktop/LyX.app/Contents/Resources/ >>> Use the '-sysdir' command line parameter or set the environment variable >>> LYX_DIR_24x to the Lyx system directory containing the file "chkconfig.Itx'. >>> >>> The contents of the folder ./LyX.app/Contents/Resources/ is completely >>> different when compared with the contents of the last working version. If >>> you manually copy the contents to the newly compiled version, the program >>> starts up again. >>> >>> I have the same problem on two different computers running macOS: an Intel >>> machine and an M1 machine. >> >> I’m using autotools to create the app and a disk image and don’t have this >> problem. >> >> Are you able to bisect with git? >> >> Stephan >> > > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Improved synctex support
Am 13.08.2022 um 02:41 schrieb Enrico Forestieri mailto:for...@lyx.org>>: > > On Mon, Aug 08, 2022 at 04:46:54PM +0200, Stephan Witt wrote: >> >> Hi all, >> >> I recently had a discussion on lyx-users regarding synctex (Subject: >> Syncing skim with LyX) which lead me to the attached patch to improve >> the usability of the document setting in GuiDocument::outputModule. >> >> I want to be sure the patch is an improvement. Therefor I ask you for >> comments. > > Sorry for chiming in late, but for me it is not an improvement. > >> 1) >> AFAICS the synctex activation is possible for more than pfdlatex >> output only. I’ve tried dvi, luatex and xetex and all of them work for >> me. So I’ve changed the check in BufferParams::writeLaTeX to use >> OutputParams::isLaTeX. Is someone to tell if this change is the right >> one? Perhaps it’s superfluous in BufferParams::writeLaTeX at all and >> one can output it w/o the check for the flavor here? >> >> 2) >> The LFUN_FORWARD_SEARCH implementation relies on the correct check in >> getStatus. The patch adds the explicit check for presence of current >> buffer and active output_sync state. Regarding the latter I’m not sure >> if someone is unhappy with it. In case of preamble code to activate >> synctex the LFUN_FORWARD_SEARCH would work but LyX doesn’t know that >> and it’s disabled. What is your opinion here? > > You can always initiate a forward search by simply defining the pdflatex > converter as "pdflatex --synctex=1 $$i", without any modification to the > sources. Now I have lost this possibility. Please, also look at the > converter for enabling the context menu or revert that part. I’ve pushed the enhancement with the converter check. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org <mailto:lyx-devel@lists.lyx.org> http://lists.lyx.org/mailman/listinfo/lyx-devel <http://lists.lyx.org/mailman/listinfo/lyx-devel>-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Runtime error (macOS)
Am 13.08.2022 um 09:26 schrieb Christoph Schmitz : > > Since a few days I get the following error message when starting a newly > compiled version of LyX: > > Unable to determine the system directory having searched > /Users/chris/Desktop/LyX.app/Contents/Resources/ > Use the '-sysdir' command line parameter or set the environment variable > LYX_DIR_24x to the Lyx system directory containing the file "chkconfig.Itx'. > > The contents of the folder ./LyX.app/Contents/Resources/ is completely > different when compared with the contents of the last working version. If you > manually copy the contents to the newly compiled version, the program starts > up again. > > I have the same problem on two different computers running macOS: an Intel > machine and an M1 machine. I’m using autotools to create the app and a disk image and don’t have this problem. Are you able to bisect with git? Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Improved synctex support
Am 13.08.2022 um 02:41 schrieb Enrico Forestieri : > > On Mon, Aug 08, 2022 at 04:46:54PM +0200, Stephan Witt wrote: >> >> Hi all, >> >> I recently had a discussion on lyx-users regarding synctex (Subject: >> Syncing skim with LyX) which lead me to the attached patch to improve >> the usability of the document setting in GuiDocument::outputModule. >> >> I want to be sure the patch is an improvement. Therefor I ask you for >> comments. > > Sorry for chiming in late, but for me it is not an improvement. > >> 1) >> AFAICS the synctex activation is possible for more than pfdlatex >> output only. I’ve tried dvi, luatex and xetex and all of them work for >> me. So I’ve changed the check in BufferParams::writeLaTeX to use >> OutputParams::isLaTeX. Is someone to tell if this change is the right >> one? Perhaps it’s superfluous in BufferParams::writeLaTeX at all and >> one can output it w/o the check for the flavor here? >> >> 2) >> The LFUN_FORWARD_SEARCH implementation relies on the correct check in >> getStatus. The patch adds the explicit check for presence of current >> buffer and active output_sync state. Regarding the latter I’m not sure >> if someone is unhappy with it. In case of preamble code to activate >> synctex the LFUN_FORWARD_SEARCH would work but LyX doesn’t know that >> and it’s disabled. What is your opinion here? > > You can always initiate a forward search by simply defining the pdflatex > converter as "pdflatex --synctex=1 $$i", without any modification to the > sources. Now I have lost this possibility. Please, also look at the > converter for enabling the context menu or revert that part. I’ll check it. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC][PATCH] Improved synctex support
Am 11.08.2022 um 09:37 schrieb Pavel Sanda :
>
Thanks for having a look at it.
> On Mon, Aug 08, 2022 at 04:46:54PM +0200, Stephan Witt wrote:
>> 1)
>> AFAICS the synctex activation is possible for more than pfdlatex output
>> only. I???ve tried dvi, luatex and xetex and all of them work for me. So
>> I???ve changed the check in BufferParams::writeLaTeX to use
>> OutputParams::isLaTeX. Is someone to tell if this change is the right one?
>> Perhaps it???s superfluous in BufferParams::writeLaTeX at all and one can
>> output it w/o the check for the flavor here?
>
> This is very long time ago and my memory might be failing, but I think the
> disctinction between srcltx vs synctex was there because srcltx was working
> for dvi.
> So perhaps enabling synctex for luatex and xetex is a safer than testing that
> without srcltx dvi works on other platforms?
Hmm. I wanted to say to use a simple else instead on another if statement with
the check for isLaTeX() or for pdflatex. The test for LaTeX with the srcltx if
should remain.
That would be:
if (output_sync) {
if (!output_sync_macro.empty())
os << from_utf8(output_sync_macro) +"\n";
else if (features.runparams().flavor == Flavor::LaTeX)
os << "\\usepackage[active]{srcltx}\n";
else
os << "\\synctex=-1\n";
}
>> 2)
>> The LFUN_FORWARD_SEARCH implementation relies on the correct check in
>> getStatus. The patch adds the explicit check for presence of current buffer
>> and active output_sync state. Regarding the latter I???m not sure if someone
>> is unhappy with it. In case of preamble code to activate synctex the
>> LFUN_FORWARD_SEARCH would work but LyX doesn???t know that and it???s
>> disabled. What is your opinion here?
>
> - I would naively expect that check for buffer is enforced by dispatch
> (unless NoBuffer flag for lfun is specified, which won't be in this case).
> But I might miss something.
You’re right. But there is the check for a valid buffer in many (most?) other
cases and the comment in dispatch claims that getStatus checks it. So one
should at least change the comment? :)
> - It did not happen to me that I needed direct preamble editing for sync so
> it seems we are rather on the safe side to check output_sync state. On the
> other hand what is the drawback of allowing the lfun regardless of
> output_sync state?
The drawback for users is the missing visual feedback that w/o active
output_sync state the forward search is not possible.
Stephan
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
[RFC][PATCH] Improved synctex support
Hi all, I recently had a discussion on lyx-users regarding synctex (Subject: Syncing skim with LyX) which lead me to the attached patch to improve the usability of the document setting in GuiDocument::outputModule. I want to be sure the patch is an improvement. Therefor I ask you for comments. 1) AFAICS the synctex activation is possible for more than pfdlatex output only. I’ve tried dvi, luatex and xetex and all of them work for me. So I’ve changed the check in BufferParams::writeLaTeX to use OutputParams::isLaTeX. Is someone to tell if this change is the right one? Perhaps it’s superfluous in BufferParams::writeLaTeX at all and one can output it w/o the check for the flavor here? 2) The LFUN_FORWARD_SEARCH implementation relies on the correct check in getStatus. The patch adds the explicit check for presence of current buffer and active output_sync state. Regarding the latter I’m not sure if someone is unhappy with it. In case of preamble code to activate synctex the LFUN_FORWARD_SEARCH would work but LyX doesn’t know that and it’s disabled. What is your opinion here? BR, Stephan synctex-1.patch Description: Binary data -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Missing icons
Am 08.08.2022 um 10:14 schrieb jspi...@gmail.com: > > Am Montag, dem 08.08.2022 um 03:26 +0200 schrieb Daniel: >>> The problem is present with installed LyX but not with LyX running >>> from source, AFAICS. >>> >>> Stephan >> >> Indeed, I am always using the installed version (since I never got it >> running from source). > > The file icon.aliases was installed in the top dir, whereas it is > searched in images/ > > I corrected this for autotools. Something similar probably needs to be > done for cmake. Your patch solves the problem. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Missing icons
Am 07.08.2022 um 14:58 schrieb Daniel : > > On 2022-08-06 18:55, Jean-Pierre Chrétien wrote: >> 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. > > I see the same. Me too. On mac. The output of lyx with gui debug enabled is: frontends/qt/GuiApplication.cpp (653): Cannot find icon for command "dialog-toggle(findreplace)" frontends/qt/GuiApplication.cpp (653): Cannot find icon for command "dialog-toggle(findreplaceadv)“ frontends/qt/GuiApplication.cpp (653): Cannot find icon for command "dialog-toggle(toc)" frontends/qt/GuiApplication.cpp (653): Cannot find icon for command "toolbar-set(math on)" frontends/qt/GuiApplication.cpp (653): Cannot find icon for command "toolbar-set(math off)" frontends/qt/GuiApplication.cpp (653): Cannot find icon for command "toolbar-set(math auto)" frontends/qt/GuiApplication.cpp (653): Cannot find icon for command "toolbar-set(table on)" frontends/qt/GuiApplication.cpp (653): Cannot find icon for command "toolbar-set(table off)" frontends/qt/GuiApplication.cpp (653): Cannot find icon for command "toolbar-set(table auto)" frontends/qt/GuiApplication.cpp (653): Cannot find icon for command "toolbar-set(review on)" frontends/qt/GuiApplication.cpp (653): Cannot find icon for command "toolbar-set(review off)" frontends/qt/GuiApplication.cpp (653): Cannot find icon for command "toolbar-set(review auto)" and there is no such icon indeed. It’s dialog-show_findreplace.svgz, dialog-show_findreplaceadv.svgz and dialog-show_toc.svgz The problem is present with installed LyX but not with LyX running from source, AFAICS. Stephan > > Daniel > > > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Interesting discovery from automatic tools (python code)
Am 01.08.2022 um 09:05 schrieb José Matos : > > On Sun, 2022-07-31 at 23:33 +0200, Stephan Witt wrote: >> With Python 3.8.13 on macOS there is no difference in configure.log >> before and after change c041925261. >> >> Stephan > > Thank you, this is good in the sense that what worked before still > works now. This is important for some reason. :-) > > For those who test this patch please also compare lyxrc.defaults that > is the file where the changes will be applied. Yes, of course. The lyxrc.defaults has no difference too on my system. The result with Python 2.7.16 is the same. I’m fine with these results. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Interesting discovery from automatic tools (python code)
Am 31.07.2022 um 12:41 schrieb José Matos : > > On Sun, 2022-07-31 at 11:16 +0200, Pavel Sanda wrote: >> Sure, whatever you need :) >> The patch is in. >> >> Pavel > > First attempt. :-) > > The code is straightforward, on my system it works in both python2 and > python3. FWIW the only difference is: > > --- configure2.log 2022-07-31 11:32:45.733253492 +0100 > +++ configure.log 2022-07-31 11:33:20.607195627 +0100 > @@ -1,4 +1,4 @@ > -INFO: +Running LyX configure with Python 2.7.18 > +INFO: +Running LyX configure with Python 3.10.5 > INFO: checking for a Latex2e program... > DEBUG: (latex $$i,latex2e $$i) > INFO: +checking for "latex"... yes > > And of course that is the expected. > > FWIW the code should work on any system/OS... famous last words, I > know. :-D > > Please test it. With Python 3.8.13 on macOS there is no difference in configure.log before and after change c041925261. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Toggled text inside a bold inset is output differently on master than 2.3.x
> Am 26.07.2022 um 21:19 schrieb Scott Kostyshak : > > On Tue, Jul 26, 2022 at 04:31:13PM +0200, Daniel wrote: >> On 2022-07-26 16:25, Scott Kostyshak wrote: >>> See the attached example. The text "text part 2" is output as bold in >>> 2.3.x, but is not output as bold in master (although it is displayed as >>> bold in the LyX display). >>> >>> I can bisect if it would be worth the time. >>> >>> Scott >> >> For some reason, I cannot open the attached document (neither 2.3 nor 2.4): >> ".../mwe.23.lyx is not a readable LyX document". > > Strange. I wonder if it's an encoding thing. > > Scott I have no problem to open it with LyX-2.3.6.1 MacOS version and with LyX-2.4.0dev. I can confirm the different PDF output with TeX Live 2020. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [PATCH] Allow removing words from the personal dictionary, that weren't previously added
Am 26.04.2022 um 09:27 schrieb Isaac Oscar Gariano : > > I've made the "Remove from personal dictionary" function/context menu item > work for words that haven't been previously added, but instead are in the > system-wide dictionary. > I've modified the behaviour so that it will cause the word to be marked as > incorrectly spelt, regardless of whether it is in the user's personal > dictionary, or the system-wide dictionary. > I've attached two patches, one that can be applied on the latest release > branch 2.3.6.1, and the other works on the master branch) > > Previously, this only worked for words not in the system-wide dictionary, > e.g.: > • write "ello", it will be red squiggly underlined > • right click and go "Add to personal dictionary" > • now the underline will disappear > • right click it and go "Remove from personal dictionary" > • it will now be red underlined again > Now you can also do: > • write "hello" > • right click on it, and click "Remove from personal dictionary" > • there should now be a red squiggly underline under "hello", i.e. it > is no longer considered a word > (The above also works with the corresponding lyx-functions spelling-add and > spelling-remove) > It might be better to change the text of the context menu button, e.g., "Add > to personal bad words list" or something, but then it'd need to be translated > > > The main use cases I have for this feature are: > • removing rare words that are common misspellings, e.g., if you often > write "whet" instead of "wet", you can mark the former as invalid. > • ensure you consistently use the same variant of a word , e.g., make > "spelled" an error if you prefer "spelt" (the latter being a word in the > en_GB dictionary) > This change is backwards compatible: any words you had previously added to > the personal dictionary will still be recognised. > > I have fully tested this on Linux (specifically OpenSUSE Tumbleweed, with > Aspell v0.60.8, Enchant v2.2.15, and, Hunspell 1.7.0), and Windows 11 (using > the included Hunspell v1.6.2), I don't have a Mac so I can't test the > AppleSpeller/Native backend. > > How it works: > > • Enchant already supports this feature out of the box, so I didn't > need to change the backend at all, all I needed to do was to make the "Remove > from personal dictionary" context menu button show up for all correctly spelt > words (and not just those in the personal dictionary). > Specifically, enchant uses two files ~/.config./enchant/.dic and > ~/.config/enchant/.exc to store the personal dictionary. The former > contains all words that you have clicked "Add to personal dictionary", and > the latter uses all that you have clicked "Remove from personal dictionary" > for. > Note that words are added to .dic and .exc even if unnecessary (because the > word is in the system-wide dictionary, or not in it, respectively). > The ".exc" file appears to take precedence over .dic, so if a word is in > both, it is considered misspelt. > • Aspell and Hunspell currently uses a file > $LYX_USERDIR/pwl_.dict to store words you have clicked "Add to > personal dictionary" for. LyX now also uses the$LYX_USERDIR/pwl_.excl > file for words you have "Remove from personal dictionary". For consistency, > my code treats these files like the enchant .dic and .exc files above, > specifically the .excl file takes precedence of the .dict file, and words > may be added to these files even if redundant/unnecessary. > The Hunspell backend already natively supports removing words from the > dictionary at runtime, however Aspell does not, so after spell checking a > word, my code manually checks for it's presence in the .excl list, which I > have not optimised at all, and so it is an O(n) operation, where n is the > number of words in the .excl file. > AppleSpeller/Native: this may work out of the box like Enchant, or not. I > have no idea, as I can't test it and the documentation is unhelpful (e.g. > https://developer.apple.com/documentation/appkit/nsspellchecker/1525147-unlearnword) > Note: I have deleted LEARNED_WORD from the SpellChecker::Result enum, as > the code no longer distinguishes between words in the personal dictionary and > the base dictionary. I also removed the ROOT_FOUND, COMPOUND_WORD, and > IGNORED_WORD variants as they were never used. > > For the master branch, I haven't modified the "Remove from document > dictionary" option to also work with words not in said dictionary; I'd have > to modify the LyX file format to support a \spellchecker_reject or something > like, but I can probably work out how to do that if you're happy with the > idea. Hi Isaac, thank you for your work on LyX. I’ve tried your patch and unfortunately it doesn’t work on Mac. Despite the fact that it relies on the existence of the LEARNED_WORD in the SpellChecker::Result enum there is IMO a problem
Re: cannot run lyx on MacOS 10.15 catalina
Am 19.03.2022 um 15:28 schrieb Uwe Brauer : > >>>> "SW" == Stephan Witt writes: > >> Am 19.03.2022 um 09:04 schrieb Uwe Brauer : >>> Hi >>> >>> I usually run LyX on Ubuntu, but I gave a MacOS laptop a try, so I >>> downloaded it from >>> https://www.lyx.org/Download#toc4 > >> There are two binaries. Did you try both? > > Ah, I only saw one : LyX-2.3.6.2+qt5-12-x86_64-cocoa.dmg, a > the other is supposed for older systems (and 10.15 is not that old but well I > can give it a try) Yes, it’s meant to be useful for El Capitan e.g. > >>> installed and started it. >>> >>> The usually blocking message appeared (this is a 3rd pkg app) so I gave >>> permission to open it and it died unexpectedly. > >> Sorry for that, I’m afraid it’s not tested with Catalina. (I’m running >> Mojave because of depending on 32-bit apps.) > > I see, mine was shipped with 10.15 and I did not upgrade because I am > using fink (hm I have to see whether fink ships lyx, but most likely it > will be older) Meanwhile I’ve installed Catalina in a virtual machine (10.15.7) and tried to install LyX-2.3.6.2+qt5-12-x86_64-cocoa.dmg from LyX download area. I had to clear the download attributes to get it running. After copying the app to /Applications I started this command in Terminal: xattr -rc /Applications/LyX.app BG Stephan > >>> A long log popped up to be sent to Apple. >>> >>> At this point I have to ask you. >>> Is this a bug of sorts, and can it be resolved or >>> is this not known and I shall sent a bug report? > >> It would be handy to have the crash report. Please send me a mail with it or >> create a ticket in LyX bug tracker and attach it. > > Ok I will first some more testing and then if it does not help I send > you the report. > > Uwe > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: cannot run lyx on MacOS 10.15 catalina
Am 19.03.2022 um 09:04 schrieb Uwe Brauer : > Hi > > I usually run LyX on Ubuntu, but I gave a MacOS laptop a try, so I > downloaded it from > https://www.lyx.org/Download#toc4 There are two binaries. Did you try both? > installed and started it. > > The usually blocking message appeared (this is a 3rd pkg app) so I gave > permission to open it and it died unexpectedly. Sorry for that, I’m afraid it’s not tested with Catalina. (I’m running Mojave because of depending on 32-bit apps.) > A long log popped up to be sent to Apple. > > At this point I have to ask you. > Is this a bug of sorts, and can it be resolved or > is this not known and I shall sent a bug report? It would be handy to have the crash report. Please send me a mail with it or create a ticket in LyX bug tracker and attach it. Thank you. BR Stephan > > Regards > > Uwe Brauer > > -- > I strongly condemn Putin's war of aggression against the Ukraine. > I support to deliver weapons to Ukraine's military. > I support the ban of Russia from SWIFT. > I support the EU membership of the Ukraine. > (https://how-to-help-ukraine-now.super.site) > > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX for Mac
Am 19.02.2022 um 12:34 schrieb Hal Kierstead via lyx-users : > >> On Feb 18, 2022, at 8:11 PM, Tom Goldring via lyx-users >> wrote: >> >> I don't know how to adjust the cursor blink rate in Apple Mail, Thunderbird, >> Safari, etc. (if anyone does, please tell me!) but since I'm not spending a >> lot of time typing text into a window when I use a web browser, it isn't >> that much of an issue. When composing email, I usually type my text into an >> emacs buffer (which does allow me to turn off the blink) and then paste it >> into the mail client. In Windows you can turn off the blink via Control >> Panel -> Keyboard Properties. >> >> On 2/18/22 8:38 PM, Stephan Witt wrote: >>> Am 18.02.2022 um 20:46 schrieb Tom Goldring via lyx-users >>> : >>>> I have version 2.3.6.2 on my MacBook Pro. I consider it a poor substitute >>>> for the Windows version. I can't turn off the blinking cursor (extremely >>>> annoying!), I can't change the background color (white background gives me >>>> a headache), hotkeys don't work, etc. Is there an alternative binary that >>>> I could download? >>> Regarding the blinking cursor… it is quite common to have a blinking >>> cursor. I agree it might be desirable to adjust the frequency or turn it >>> off - but at a system wide level. I don’t know of a setting to read this >>> parameter from. How do you adjust the cursor in Apple Mail or Safari? How >>> do you adjust it with the Windows version? >>> >>> BR, >>> Stephan >>> > Does > https://www.macissues.com/2014/12/08/how-to-change-your-macs-text-cursor-blink-rate/ > help? No, not really. I knew this tipp and it doesn’t help with LyX on Mac. It has an effect for Safari and e.g. SourceTree but not with Apple Mail or LyX. Qt doesn’t care for it. === 8< Qt documentation >8 === cursorFlashTime : int This property holds the text cursor's flash (blink) time in milliseconds The flash time is the time required to display, invert and restore the caret display. Usually the text cursor is displayed for half the cursor flash time, then hidden for the same amount of time, but this may vary. The default value on X11 is 1000 milliseconds. On Windows, the Control Panel value is used and setting this property sets the cursor flash time for all applications. === 8< Qt documentation >8 === IMO it is an Qt bug. One may work around it. But I’m not sure how to do it right. BR, Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Avoid static members zoom_min_ and zoom_max_
Am 09.02.2022 um 12:17 schrieb Kornel Benko : > > Am Wed, 9 Feb 2022 10:27:06 +0100 (CET) > schrieb Stephan Witt : > >> commit cd995a2bc6449c8d9d3dee494ecffcf9abdcb50f >> Author: Stephan Witt >> Date: Wed Feb 9 10:59:18 2022 +0100 >> >>Avoid static members zoom_min_ and zoom_max_ >> >>Some compilers cannot use static class members by reference. std::min() >> and >> std::max() are passing parameters by const reference. --- >> src/frontends/qt/GuiView.h |4 ++-- >> 1 files changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/src/frontends/qt/GuiView.h b/src/frontends/qt/GuiView.h >> index bd39d26..27d230b 100644 >> --- a/src/frontends/qt/GuiView.h >> +++ b/src/frontends/qt/GuiView.h >> @@ -519,9 +519,9 @@ private: >> /// from the default zoom pref >> double zoom_ratio_ = 1.0; >> /// Minimum zoom percentage >> -static int const zoom_min_ = 10; >> +int const zoom_min_ = 10; >> /// Maximum zoom percentage >> -static int const zoom_max_ = 1000; >> +int const zoom_max_ = 1000; >> >> // movability flag of all toolbars >> bool toolbarsMovable_; > > I still think we should keep 'const', but do the initialization in GuiView.cpp This is the alternate solution. My patch was ready - therefore I put it in. I prefer the assignment at declaration approach. But the other one works too. The third one would be the declaration of an inline function. Please change it at your taste… BR, Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Python related system prompt "Lyx must be updated" on macOS
Am 04.01.2022 um 01:37 schrieb José Abílio Matos : > > On Friday, 31 December 2021 13.03.57 WET Stephan Witt wrote: > > I’m curious how difficult it would be to ignore python2 and present a > > message box for users to tell them how to get a python3 interpreter. > > > > BR, Stephan > > For now we always search for Python 3 before Python 2. We know what is the > version that we are using. So that warn can be done, but then we probably > only want to show it once, or at least have an option to turn it off. Interestingly on my system the python3 is detected only if I install the Python package from python.org. The python3 in /usr/bin is not tried? Sorry, I didn’t read the code yet. > Probably the case you want to can be best done through documentation, no? Yes, at first this is the best option probably. My question for the future is how to act on next move of Apple. Neither I know when it will happen nor I know what happens. They announced to remove the preinstalled python altogether. ATM they provide python3 as wrapper. It’s asking the user to download and install the Command Line Developer Tools from Apple instead of doing anything useful. The exit status is 1. Currently LyX is using python (python2) and the warning info pops up once: „LyX needs to be updated“. Obviously this is wrong now. Python3 needs to be installed instead. So I’ll have to investigate further. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] #12434 add event handler for pinch-to-zoom gesture
Am 03.01.2022 um 16:15 schrieb Scott Kostyshak : > > On Mon, Jan 03, 2022 at 07:07:45AM +0100, Stephan Witt wrote: >> commit d4324034300f73f76e5ac34fb1e7653fa6e2ddf5 >> Author: Stephan Witt >> Date: Mon Jan 3 07:37:03 2022 +0100 >> >>#12434 add event handler for pinch-to-zoom gesture >> --- > > Cool. I do not actually use the touch screen, but I just tested and it > works well. Thank you. > I do not imagine you want to go down this rabbit hole, but just in case: > > - when I use pinch to zoom, LyX starts selecting text. Should we not > change the selection when pinch-to-zoom is executing? Do I understand it right? You get a selection when using pinch-to-zoom? This is not the case on my system. The zoom factor is changed only. > What is the expected way to scroll down in a document using the touch > screen? Also two fingers? Yes. But this is the case (on Mac at least) w/o the patch already. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Python related system prompt "Lyx must be updated" on macOS
Am 29.12.2021 um 11:38 schrieb Stephan Witt :
>
> Am 28.12.2021 um 13:55 schrieb José Abílio Matos :
>>
>> On Tuesday, 28 December 2021 12.33.57 WET Stephan Witt wrote:
>>> The LyX tasks here are IMO:
>>> 1. Assure the detected python3 is used consequently. This is not the case
>>> ATM.
>>> 2. Document the meaning of the prompts the LyX user is seeing on
>>> Monterey.
>>> 3. Provide a working python3 or give appropriate feedback on
>>> first start about users option to install python3.
>>>
>>> AFAIK, José Abílio is working on a solution for 1. I’m able to help with the
>>> Mac part of the problem.
>>
>> I am not working on 1, the issue that I am working is a bit different,
>> although related.
>
> I referred to your proposal to consequently use the detected python version
> in our scripts.
>
> ATM on Mac with python3 installed there are hardcoded calls of python e.g. in
> configure.py
> or - as you’ve pointed out - in the generated converter calls triggering the
> warning
> „LyX“ needs to be updated we want to avoid.
With latest changes to configure.py LyX is using python3 exclusively on first
configuration run.
(as of commit 77670bc9983392e32abb1cec236e5741b4d8c84b)
Now I have two options to get the rest of python2 calls eliminated:
1. the replacement of the hard coded „python“ RC configuration entries with
$${python} (your proposal) or
2. the drop-in of a python wrapper script for the Mac package. This script may
check for python3
and start this instead of the system python (which is python2 and should be
avoided).
The implementation of option 1 makes option 2 superfluous and is better. So
I’ll see how you proceed.
BTW, did you ever check how LyX behaves on a system w/o any python interpreter
installed?
I’m curious how difficult it would be to ignore python2 and present a message
box for users to tell them how to get a python3 interpreter.
BR, Stephan
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: configure.py assumes "python" command exists
Am 27.12.2021 um 20:30 schrieb José Abílio Matos :
>
> On Saturday, 25 December 2021 18.32.21 WET Scott Kostyshak wrote:
> > On Sun, Oct 31, 2021 at 12:58:19PM -0400, Scott Kostyshak wrote:
>
> Hi Scott,
> I find you choice of dates very convenient. :-)
>
> https://journeys.dartmouth.edu/folklorearchive/2016/11/12/halloween-and-christmas/
>
> “Why do programmers always mix up Halloween and Christmas?”
> “Because Oct 31 = Dec 25.”
>
> > Bump.
> >
> > Scott
>
> Regarding the problem at hand, as an example, my suggestion is to change:
>
> \converter pdf4 pdf8 "python $$s/scripts/convert_pdf.py $$i $$o ebook"
>
> to
>
> \converter pdf4 pdf8 "$${python} $$s/scripts/convert_pdf.py $$i $$o ebook"
>
> The idea is to use the converter code, e.g. the $$i $$o ..., and add there
> the substitution from $${python} to the python path that we have already
> determined in os::find_python.
I like your proposal.
Regarding the use of python calls in configure.py I’ve stolen your idea to use
sys.executable and made a patch.
This avoids the warning '„LyX“ needs to be updated‘ (see my RFC mail thread)
and lyx starts as usual if I install python3 at first
(https://www.python.org/downloads/release/python-3101)
Stephan
python-in-configure.patch
Description: Binary data
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [RFC] Python related system prompt "Lyx must be updated" on macOS
Am 28.12.2021 um 13:55 schrieb José Abílio Matos : > > On Tuesday, 28 December 2021 12.33.57 WET Stephan Witt wrote: > > The LyX tasks here are IMO: > > 1. Assure the detected python3 is used consequently. This is not the case > > ATM. > > 2. Document the meaning of the prompts the LyX user is seeing on > > Monterey. > > 3. Provide a working python3 or give appropriate feedback on > > first start about users option to install python3. > > > > AFAIK, José Abílio is working on a solution for 1. I’m able to help with the > > Mac part of the problem. > > I am not working on 1, the issue that I am working is a bit different, > although related. I referred to your proposal to consequently use the detected python version in our scripts. ATM on Mac with python3 installed there are hardcoded calls of python e.g. in configure.py or - as you’ve pointed out - in the generated converter calls triggering the warning „LyX“ needs to be updated we want to avoid. > In the case of mac we can > What I suggest is to use by default the latest python version available in > the system. That’s part of the problem. „Virgin“ systems have python 2 only. > As it is now we search for a python version and stick with it. > What I propose is to test the different versions available and pick the > latest. > > Python 3 has been tested extensively and so it is ready to be the default > option. Yes, I agree. > > Regarding the point 3 - Apples recommendation to bundle python with LyX > > (49764202) - I’m not sure if this is a real option. The Windows package > > contains python, IMO. So it is possible. But is it clever? I don’t like the > > solution to point the user to homebrew or macports to install python. Too > > much terminal work, IMO. > > > > What do others think about the situation? > > How do you deal with the latex installation in mac? LyX starts fine w/o it and the user has to install some TeX distribution to use it. There is a recommended one: MacTeX - having a installable disc image for download on it’s web site. This is easy to use. For Python the situation is a little bit different. The macOS „blames“ LyX at the first configure run if the user didn’t install a recent python 3 already. Either we live with it and document this near the download link at lyx.org or we try to inform the user at LyX startup and give the opportunity to download and install python 3 and refuse to run configure with the system python. This solves the problem we run into if Apple removes python altogether. The homebrew or macports packages are the other option for experienced users. Some of them have an installation on the system already. So we should detect it and be fine with it too. In any case we should ensure the detected usable python is used consequently. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: "Lyx must be updated"
Am 17.12.2021 um 06:57 schrieb Daniel : > > On 2021-12-16 22:16, Stephan Witt wrote: >> Am 16.12.2021 um 09:56 schrieb Murat Yildizoglu via lyx-users >> : >>> >>> I have tried to send this to lyx-devel but I am not a member. >>> >>>> Begin forwarded message: >>>> >>>> From: lyx-devel-ow...@lists.lyx.org >>>> Subject: "Lyx must be updated" >>>> Date: 16 December 2021 at 15:55:19 GMT+7 >>>> To: myi...@gmail.com >>>> >>>> Due to the massive amount of spam that this list receives, non-members >>>> are not permitted to post to this list. Please subscribe if you would >>>> like to post. (If you are trying to file a bug report, you can instead >>>> do that at https://www.lyx.org/trac/newticket. >>>> >>>> >>>> From: Murat Yildizoglu >>>> Subject: "Lyx must be updated" >>>> Date: 16 December 2021 at 15:55:13 GMT+7 >>>> To: LyX Developers >>>> >>>> >>>> This is what OSX 12.1 tells me now with Lyx LyX-2.3.6.2. >>>> >>>> ""LyX" needs to be updated >>>> This app will not work with future versions of >>>> macOS and needs to be updated to improve >>>> compatibility. Contact the developer for more >>>> information.” >>>> >>>> I imagine that the next version will be good with future versions of OSX. >>>> >>>> I have just wanted to inform. >>>> >>>> Best regards, >>>> Murat >> Hi Murat, >> that’s probably because of the LyX-2.3.6.2 package is pure Intel code and >> the friendly OS wants to warn you about the fact the Apple company is on the >> way to drop the support for the Intel CPUs. > > Searching on the wen for the warning, I've only found evidence for the > warning being triggered by the python version. What makes you think that this > is not the case? Hi Daniel, I didn’t say it’s not the case. I said it’s probably because of the CPU architecture. Maybe I’m wrong. I remember to see the very same warning with macOS High Sierra 10.13.4 for programs using 32bit Intel CPU code. Best regards, Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: "Lyx must be updated"
Am 16.12.2021 um 09:56 schrieb Murat Yildizoglu via lyx-users : > > I have tried to send this to lyx-devel but I am not a member. > >> Begin forwarded message: >> >> From: lyx-devel-ow...@lists.lyx.org >> Subject: "Lyx must be updated" >> Date: 16 December 2021 at 15:55:19 GMT+7 >> To: myi...@gmail.com >> >> Due to the massive amount of spam that this list receives, non-members >> are not permitted to post to this list. Please subscribe if you would >> like to post. (If you are trying to file a bug report, you can instead >> do that at https://www.lyx.org/trac/newticket. >> >> >> From: Murat Yildizoglu >> Subject: "Lyx must be updated" >> Date: 16 December 2021 at 15:55:13 GMT+7 >> To: LyX Developers >> >> >> This is what OSX 12.1 tells me now with Lyx LyX-2.3.6.2. >> >> ""LyX" needs to be updated >> This app will not work with future versions of >> macOS and needs to be updated to improve >> compatibility. Contact the developer for more >> information.” >> >> I imagine that the next version will be good with future versions of OSX. >> >> I have just wanted to inform. >> >> Best regards, >> Murat Hi Murat, that’s probably because of the LyX-2.3.6.2 package is pure Intel code and the friendly OS wants to warn you about the fact the Apple company is on the way to drop the support for the Intel CPUs. The upcoming LyX-2.4 and the next LyX-2.3 release will be build for both CPU architectures - the Intel and the Apple M1 chips. Best regards, Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Qt6 pixmaps are always HiDPI - avoid deprecate warning for setAttribute
Am 07.12.2021 um 18:32 schrieb Jean-Marc Lasgouttes : > > Le 07/12/2021 à 09:34, Stephan Witt a écrit : >> commit ae56fb617184114329d1e5b9b5fbd6e2bc112231 >> Author: Stephan Witt >> Date: Tue Dec 7 10:02:05 2021 +0100 >> Qt6 pixmaps are always HiDPI - avoid deprecate warning for setAttribute > >> -#if QT_VERSION > 0x050100 >> +#if QT_VERSION >= 0x05 && QT_VERSION < 0x06 >> setAttribute(Qt::AA_UseHighDpiPixmaps,true); >> #endif > > I am not sure why you change the reference to qt 5.1 to a reference to 5.2. > AFAIK, this enum has been introduced in Qt 5.1 (I do not know why there was a > >, though). You’re right. I don’t know why I changed it. Probably I thought it was a typo. I’ve changed the check accordingly (5.1.0 <= version < 6.0.0). Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Compile Error under macOS
Am 07.12.2021 um 07:38 schrieb Stephan Witt :
>
> Am 06.12.2021 um 14:43 schrieb Christoph Schmitz :
>>
>> Stephan,
>>
>> Many thanks! Adding the new config parameter
>> "--with-macos-deployment-target=11.1" solved the issue. On both computers.
>
> Ok, that’s fine.
>
>> Qt is installed on my system via homebrew. The currently installed version
>> is 6.2.2.
>
> I’ve checked the source and the file qtbase/cmake/QtAutoDetect.cmake in
> qt-everywhere-src-6.2.2 defines 10.14 as Qt default.
>
> The self-compiled universal (Intel+M1) Qt-6.2.2 frameworks can be used with
> --with-macos-deployment-target=10.14.
>
> I think the homebrew Qt is build with non-default configuration. I cannot say
> why.
Another possibility is the Xcode version you’re (or homebrew is) using.
The Qt web page https://doc.qt.io/qt-6/supported-platforms.html says it is
Xcode 12 (11 SDK).
On my system it is:
-- CMAKE_OSX_SYSROOT:
"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk"
-- CMAKE_OSX_DEPLOYMENT_TARGET: "10.14"
-- QT_MAC_SDK_VERSION: "11.1"
-- QT_MAC_XCODE_VERSION: "Xcode 12.4 Build version 12D4e“
Stephan
>>> Am 06.12.2021 um 07:35 schrieb Stephan Witt :
>>>
>>> Am 06.12.2021 um 06:25 schrieb Christoph Schmitz :
>>>>
>>>> I compile LyX on two MacBooks (one Intel Core i7, and one Apple M1), both
>>>> running macOS 12.1 Beta (21C5045a).
>>>
>>> Sorry, this doesn’t answer the question about your Qt version.
>>>
>>> The error message tells us it’s impossible to compile LyX with your
>>> Qt-version for macOS 10.14.
>>>
>>> You may run configure with --with-macos-deployment-target=10.15 or
>>> --with-macos-deployment-target=11.1 …
>>>
>>> My goal is to build LyX for macOS 10.14 on 11.1 and to tell elder macOS the
>>> package cannot be used.
>>> I couldn’t achieve this w/o explicitly putting this information into
>>> Info.plist.
>>> So I decided to make it a configure option and this leads to your problem.
>>> I wanted to get the entry
>>> in Info.plist in sync with the compiler options and I added the auto
>>> detection of the lowest possible value.
>>>
>>> On your system this value is too low apparently.
>>>
>>> Stephan
>>>
>>>>> Am 05.12.2021 um 22:49 schrieb Stephan Witt :
>>>>>
>>>>> Am 05.12.2021 um 22:32 schrieb Christoph Schmitz :
>>>>>>
>>>>>> The latest changes have introduced an issue for macOS X (Qt 6).
>>>>>
>>>>> What’s your Qt version? I’m using 6.2.0 on macOS 11.1 (with 11.1 SDK) and
>>>>> it works with minimum of macOS 10.14.
>>>>>
>>>>> Stephan
>>>>>
>>>>>>
>>>>>> These are the last lines of the output before the error occurs:
>>>>>>
>>>>>> file included from filetools.cpp:42:
>>>>>> In file included from /opt/homebrew/lib/QtCore.framework/Headers/QDir:1:
>>>>>> In file included from
>>>>>> /opt/homebrew/lib/QtCore.framework/Headers/qdir.h:45:
>>>>>> /opt/homebrew/lib/QtCore.framework/Headers/qfileinfo.h:118:14: error:
>>>>>> '~path' is unavailable: introduced in macOS 10.15
>>>>>> { return QtPrivate::toFilesystemPath(filePath()); }
>>>>>> ^
>>>>>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/filesystem:961:3:
>>>>>> note: '~path' has been explicitly marked unavailable here
>>>>>> ~path() = default;
>>>>>> ^
>>>>>> In file included from filetools.cpp:42:
>>>>>> In file included from /opt/homebrew/lib/QtCore.framework/Headers/QDir:1:
>>>>>> In file included from
>>>>>> /opt/homebrew/lib/QtCore.framework/Headers/qdir.h:45:
>>>>>> /opt/homebrew/lib/QtCore.framework/Headers/qfileinfo.h:120:14: error:
>>>>>> '~path' is unavailable: introduced in macOS 10.15
>>>>>> { return QtPrivate::toFilesystemPath(absoluteFilePath()); }
>>>>>> ^
>>>>>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/filesystem:961:3:
>>>>>> note: '~path' has been explicitly marked unavailable here
>>>>>> ~path() = default;
>>>>>> ^
>>>>>> fatal error: too many errors emitted, stopping now [-ferror-limit=]
>>>>>> 20 errors generated.
>>>>>> make[5]: *** [filetools.o] Error 1
>>>>>> make[4]: *** [all] Error 2
>>>>>> make[3]: *** [all-recursive] Error 1
>>>>>> make[2]: *** [all] Error 2
>>>>>> make[1]: *** [all-recursive] Error 1
>>>>>> make: *** [all] Error 2
>>>>>>
>>>>>> I also try to attach the full log, but last time it was removed from the
>>>>>> mailer.
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>>
>>>>>> --
>>>>>> lyx-devel mailing list
>>>>>> lyx-devel@lists.lyx.org
>>>>>> http://lists.lyx.org/mailman/listinfo/lyx-devel
>>>>>
>>>>
>>>> --
>>>> lyx-devel mailing list
>>>> lyx-devel@lists.lyx.org
>>>> http://lists.lyx.org/mailman/listinfo/lyx-devel
>>>
>>
>> --
>> lyx-devel mailing list
>> lyx-devel@lists.lyx.org
>> http://lists.lyx.org/mailman/listinfo/lyx-devel
>
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Compile Error under macOS
Am 06.12.2021 um 14:43 schrieb Christoph Schmitz :
>
> Stephan,
>
> Many thanks! Adding the new config parameter
> "--with-macos-deployment-target=11.1" solved the issue. On both computers.
Ok, that’s fine.
> Qt is installed on my system via homebrew. The currently installed version is
> 6.2.2.
I’ve checked the source and the file qtbase/cmake/QtAutoDetect.cmake in
qt-everywhere-src-6.2.2 defines 10.14 as Qt default.
The self-compiled universal (Intel+M1) Qt-6.2.2 frameworks can be used with
--with-macos-deployment-target=10.14.
I think the homebrew Qt is build with non-default configuration. I cannot say
why.
Stephan
>> Am 06.12.2021 um 07:35 schrieb Stephan Witt :
>>
>> Am 06.12.2021 um 06:25 schrieb Christoph Schmitz :
>>>
>>> I compile LyX on two MacBooks (one Intel Core i7, and one Apple M1), both
>>> running macOS 12.1 Beta (21C5045a).
>>
>> Sorry, this doesn’t answer the question about your Qt version.
>>
>> The error message tells us it’s impossible to compile LyX with your
>> Qt-version for macOS 10.14.
>>
>> You may run configure with --with-macos-deployment-target=10.15 or
>> --with-macos-deployment-target=11.1 …
>>
>> My goal is to build LyX for macOS 10.14 on 11.1 and to tell elder macOS the
>> package cannot be used.
>> I couldn’t achieve this w/o explicitly putting this information into
>> Info.plist.
>> So I decided to make it a configure option and this leads to your problem. I
>> wanted to get the entry
>> in Info.plist in sync with the compiler options and I added the auto
>> detection of the lowest possible value.
>>
>> On your system this value is too low apparently.
>>
>> Stephan
>>
>>>> Am 05.12.2021 um 22:49 schrieb Stephan Witt :
>>>>
>>>> Am 05.12.2021 um 22:32 schrieb Christoph Schmitz :
>>>>>
>>>>> The latest changes have introduced an issue for macOS X (Qt 6).
>>>>
>>>> What’s your Qt version? I’m using 6.2.0 on macOS 11.1 (with 11.1 SDK) and
>>>> it works with minimum of macOS 10.14.
>>>>
>>>> Stephan
>>>>
>>>>>
>>>>> These are the last lines of the output before the error occurs:
>>>>>
>>>>> file included from filetools.cpp:42:
>>>>> In file included from /opt/homebrew/lib/QtCore.framework/Headers/QDir:1:
>>>>> In file included from
>>>>> /opt/homebrew/lib/QtCore.framework/Headers/qdir.h:45:
>>>>> /opt/homebrew/lib/QtCore.framework/Headers/qfileinfo.h:118:14: error:
>>>>> '~path' is unavailable: introduced in macOS 10.15
>>>>> { return QtPrivate::toFilesystemPath(filePath()); }
>>>>> ^
>>>>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/filesystem:961:3:
>>>>> note: '~path' has been explicitly marked unavailable here
>>>>> ~path() = default;
>>>>> ^
>>>>> In file included from filetools.cpp:42:
>>>>> In file included from /opt/homebrew/lib/QtCore.framework/Headers/QDir:1:
>>>>> In file included from
>>>>> /opt/homebrew/lib/QtCore.framework/Headers/qdir.h:45:
>>>>> /opt/homebrew/lib/QtCore.framework/Headers/qfileinfo.h:120:14: error:
>>>>> '~path' is unavailable: introduced in macOS 10.15
>>>>> { return QtPrivate::toFilesystemPath(absoluteFilePath()); }
>>>>> ^
>>>>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/filesystem:961:3:
>>>>> note: '~path' has been explicitly marked unavailable here
>>>>> ~path() = default;
>>>>> ^
>>>>> fatal error: too many errors emitted, stopping now [-ferror-limit=]
>>>>> 20 errors generated.
>>>>> make[5]: *** [filetools.o] Error 1
>>>>> make[4]: *** [all] Error 2
>>>>> make[3]: *** [all-recursive] Error 1
>>>>> make[2]: *** [all] Error 2
>>>>> make[1]: *** [all-recursive] Error 1
>>>>> make: *** [all] Error 2
>>>>>
>>>>> I also try to attach the full log, but last time it was removed from the
>>>>> mailer.
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>> --
>>>>> lyx-devel mailing list
>>>>> lyx-devel@lists.lyx.org
>>>>> http://lists.lyx.org/mailman/listinfo/lyx-devel
>>>>
>>>
>>> --
>>> lyx-devel mailing list
>>> lyx-devel@lists.lyx.org
>>> http://lists.lyx.org/mailman/listinfo/lyx-devel
>>
>
> --
> lyx-devel mailing list
> lyx-devel@lists.lyx.org
> http://lists.lyx.org/mailman/listinfo/lyx-devel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX 2.4.0
Am 05.12.2021 um 18:46 schrieb Richard Kimberly Heck : > > On 12/4/21 06:26, Stephan Witt wrote: >> Am 01.12.2021 um 22:48 schrieb Richard Kimberly Heck : >>> Hi, all, >>> >>> Things got a bit crazy again, but I now should have a bit of time. Where do >>> people think we stand with 2.4.0? I've seen a bit of activity in the >>> interim. Do we need to do one more alpha? Or should we proceed directly to >>> beta 1? >>> >>> What if anything needs to be done before we move to whatever the next stage >>> is? >> I have two things pending: >> >> 1. Changes to make LyX to compile with Qt 6.2 on Mac >> 2. Configure option parameter to define the minimum target OS version for Mac >> >> I’d like to push them to be ready for build of LyX package with Qt 6.2 for >> Intel and M1 CPUs on Mac. > > I'm ignorant of such things. I would think you could go ahead. The changes > look pretty minor. > > I did notice that your patch sometimes uses QT_VERSION < QT_VERSION_CHECK(6, > 0, 0) and sometimes uses QT_VERSION < 0x06 type syntax. I would guess we > should be consistent, but I don't know which is best. I’m using the variant I see in the code above or below. Personally I prefer the QT_VERSION_CHECK macro. But it’s not possible everywhere - moc don’t know it and it doesn’t work in headers read by moc. So to be consistent is possible with the 0x0yzblah syntax. Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Compile Error under macOS
Am 06.12.2021 um 06:25 schrieb Christoph Schmitz :
>
> I compile LyX on two MacBooks (one Intel Core i7, and one Apple M1), both
> running macOS 12.1 Beta (21C5045a).
Sorry, this doesn’t answer the question about your Qt version.
The error message tells us it’s impossible to compile LyX with your Qt-version
for macOS 10.14.
You may run configure with --with-macos-deployment-target=10.15 or
--with-macos-deployment-target=11.1 …
My goal is to build LyX for macOS 10.14 on 11.1 and to tell elder macOS the
package cannot be used.
I couldn’t achieve this w/o explicitly putting this information into
Info.plist.
So I decided to make it a configure option and this leads to your problem. I
wanted to get the entry
in Info.plist in sync with the compiler options and I added the auto detection
of the lowest possible value.
On your system this value is too low apparently.
Stephan
>> Am 05.12.2021 um 22:49 schrieb Stephan Witt :
>>
>> Am 05.12.2021 um 22:32 schrieb Christoph Schmitz :
>>>
>>> The latest changes have introduced an issue for macOS X (Qt 6).
>>
>> What’s your Qt version? I’m using 6.2.0 on macOS 11.1 (with 11.1 SDK) and it
>> works with minimum of macOS 10.14.
>>
>> Stephan
>>
>>>
>>> These are the last lines of the output before the error occurs:
>>>
>>> file included from filetools.cpp:42:
>>> In file included from /opt/homebrew/lib/QtCore.framework/Headers/QDir:1:
>>> In file included from /opt/homebrew/lib/QtCore.framework/Headers/qdir.h:45:
>>> /opt/homebrew/lib/QtCore.framework/Headers/qfileinfo.h:118:14: error:
>>> '~path' is unavailable: introduced in macOS 10.15
>>> { return QtPrivate::toFilesystemPath(filePath()); }
>>>^
>>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/filesystem:961:3:
>>> note: '~path' has been explicitly marked unavailable here
>>> ~path() = default;
>>> ^
>>> In file included from filetools.cpp:42:
>>> In file included from /opt/homebrew/lib/QtCore.framework/Headers/QDir:1:
>>> In file included from /opt/homebrew/lib/QtCore.framework/Headers/qdir.h:45:
>>> /opt/homebrew/lib/QtCore.framework/Headers/qfileinfo.h:120:14: error:
>>> '~path' is unavailable: introduced in macOS 10.15
>>> { return QtPrivate::toFilesystemPath(absoluteFilePath()); }
>>>^
>>> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/filesystem:961:3:
>>> note: '~path' has been explicitly marked unavailable here
>>> ~path() = default;
>>> ^
>>> fatal error: too many errors emitted, stopping now [-ferror-limit=]
>>> 20 errors generated.
>>> make[5]: *** [filetools.o] Error 1
>>> make[4]: *** [all] Error 2
>>> make[3]: *** [all-recursive] Error 1
>>> make[2]: *** [all] Error 2
>>> make[1]: *** [all-recursive] Error 1
>>> make: *** [all] Error 2
>>>
>>> I also try to attach the full log, but last time it was removed from the
>>> mailer.
>>>
>>> Chris
>>>
>>>
>>> --
>>> lyx-devel mailing list
>>> lyx-devel@lists.lyx.org
>>> http://lists.lyx.org/mailman/listinfo/lyx-devel
>>
>
> --
> lyx-devel mailing list
> lyx-devel@lists.lyx.org
> http://lists.lyx.org/mailman/listinfo/lyx-devel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] introduce LSMinimumSystemVersion for Mac package with automatic Qt-version based detection plus configure option to choose it manually
Am 05.12.2021 um 17:18 schrieb Jean-Marc Lasgouttes : > > Le 05/12/2021 à 10:43, Stephan Witt a écrit : >> commit d1d22a1433e503c3f36aa982c2a7ec9d1f79273d >> Author: Stephan Witt >> Date: Sun Dec 5 11:10:11 2021 +0100 >> introduce LSMinimumSystemVersion for Mac package with automatic >> Qt-version based detection plus configure option to choose it manually > > I can't compile on Linux anymore… Yes, I forgot to care for appropriate guards. Is it better now? Stephan -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
