Re: Bug: note displays bold incorrectly
On Tue, Sep 11, 2018 at 11:23:28AM -0400, Scott Kostyshak wrote: > On Sat, Aug 25, 2018 at 05:37:42PM +0200, Kornel Benko wrote: > > Am Samstag, 25. August 2018 11:05:52 CEST schrieb Paul A. Rubin > > : > > > > 1. Start a new file. > > > > 2. Toggle bold (e.g., ctrl + b). > > > > 3. Start a LyX note. > > > > 4. Type "A" > > > > 5. Toggle bold (e.g., ctrl + b). > > > > 6. Type "a". > > > > > > > > I guess this might be a feature, since the whole inset is bold because > > > > of (1). So even if there is unbolded text inside it, it should (?) be > > > > displayed as bold. When I disolve the inset, then the text is free to > > > > reclaim its previously ignored properties. > > > > > > > > Scott > > > > I think too. Mark, that you do not toggle between 'bold' and 'medium' > > but between 'bold' and 'standard', whatever that may be. > > Good point. > > > > I guess I would tend to think that, in all matters of formatting or > > > style, the innermost setting (the setting most proximate to the text) > > > should rule. So I would expect that lower case "a" to be normal weight, > > > even with the bolding of the entire note. The one exception might be an > > > option to strip all formatting from the cursor selection, which would > > > overrule (and remove) any format stuff no matter how deeply nested. > > > > > > That said, I would not be shocked if some users wanted to keep things > > > the way they are. > > > > > > Paul > > > > Like me. > > Makes sense. I wonder if we could display somehow that the inset is > bold. Otherwise, it might be confusing to the user. One idea would be to > apply the bold to the text inside the inset rectangle thing (in this > case, to "Note"). Note that the behavior is not consistent. Indeed, when turning the note into a comment (by context menu) the "a" is not displayed bold anymore. I think this is the correct behavior and the one with "note" is a bug. -- Enrico
Re: Crash
On Tue, Sep 11, 2018 at 02:40:23PM +0200, Daniel wrote: > On 10/09/2018 12:56, Andrew Parsloe wrote: > > On 10/09/2018 8:20 p.m., Daniel wrote: > > > On 10/09/2018 08:30, Andrew Parsloe wrote: > > > > LyX 2.3.1, windows 7 > > > > > > > > 1. Create a new document, type a letter > > > > > > > > 2. View the pdf (eyes button) > > > > > > > > 3. From the pdf 'Save as' to a permanent directory. > > > > > > > > 4. Close the pdf viewer > > > > > > > > 5. Click on LyX -- crash. > > > > > > > > I often work in this way, viewing the pdf, correcting the LyX > > > > source, and then 'Saving as' from the pdf in the temp directory > > > > to a permanent one. LyX crashes on perhaps 80% of attempts. It > > > > seems to 'help' if, after 'Save as', I wait about half a minute > > > > before closing the pdf viewer. I use Sumatra, but also tested > > > > (once) with Adobe Reader and still got the crash. > > > > > > > > I can't generate the crash with LyX 2.2.3 (about 4 attempts). > > > > > > > > Andrew > > > > > > Might be the same or related to this one: > > > https://www.lyx.org/trac/ticket/11210 ? > > > > > > Daniel > > > > > Yes, exactly that, including the 30 second wait before closing the pdf > > viewer. > > > > Andrew > > It seems to be a very serious bug nonetheless. I am wondering whether it can > be recommended to people working on Windows to update to 2.3 while it isn't > fixed. (Once you know how the bug works it's okay, I guess.) Note that it is not LyX crashing but rather Qt. Indeed, the crash occurs in the QtCore library. It was introduced in Qt 5.10 and is still present in Qt 5.11. Hence, the only way to solve this issue is either recompiling LyX using Qt 5.9 or waiting for a solution in the next Qt versions. The crash does not occur with LyX 2.2 only because Qt 5.9 is used there. -- Enrico
Re: Bug: note displays bold incorrectly
On 09/11/2018 11:23 AM, Scott Kostyshak wrote: On Sat, Aug 25, 2018 at 05:37:42PM +0200, Kornel Benko wrote: Am Samstag, 25. August 2018 11:05:52 CEST schrieb Paul A. Rubin : 1. Start a new file. 2. Toggle bold (e.g., ctrl + b). 3. Start a LyX note. 4. Type "A" 5. Toggle bold (e.g., ctrl + b). 6. Type "a". I guess this might be a feature, since the whole inset is bold because of (1). So even if there is unbolded text inside it, it should (?) be displayed as bold. When I disolve the inset, then the text is free to reclaim its previously ignored properties. Scott I think too. Mark, that you do not toggle between 'bold' and 'medium' but between 'bold' and 'standard', whatever that may be. Good point. I guess I would tend to think that, in all matters of formatting or style, the innermost setting (the setting most proximate to the text) should rule. So I would expect that lower case "a" to be normal weight, even with the bolding of the entire note. The one exception might be an option to strip all formatting from the cursor selection, which would overrule (and remove) any format stuff no matter how deeply nested. That said, I would not be shocked if some users wanted to keep things the way they are. Paul Like me. Makes sense. I wonder if we could display somehow that the inset is bold. Otherwise, it might be confusing to the user. One idea would be to apply the bold to the text inside the inset rectangle thing (in this case, to "Note"). Scott That sounds like a good idea to me. Paul
Re: Bug: note displays bold incorrectly
On Sat, Aug 25, 2018 at 05:37:42PM +0200, Kornel Benko wrote: > Am Samstag, 25. August 2018 11:05:52 CEST schrieb Paul A. Rubin > : > > > 1. Start a new file. > > > 2. Toggle bold (e.g., ctrl + b). > > > 3. Start a LyX note. > > > 4. Type "A" > > > 5. Toggle bold (e.g., ctrl + b). > > > 6. Type "a". > > > > > > I guess this might be a feature, since the whole inset is bold because > > > of (1). So even if there is unbolded text inside it, it should (?) be > > > displayed as bold. When I disolve the inset, then the text is free to > > > reclaim its previously ignored properties. > > > > > > Scott > > I think too. Mark, that you do not toggle between 'bold' and 'medium' > but between 'bold' and 'standard', whatever that may be. Good point. > > I guess I would tend to think that, in all matters of formatting or > > style, the innermost setting (the setting most proximate to the text) > > should rule. So I would expect that lower case "a" to be normal weight, > > even with the bolding of the entire note. The one exception might be an > > option to strip all formatting from the cursor selection, which would > > overrule (and remove) any format stuff no matter how deeply nested. > > > > That said, I would not be shocked if some users wanted to keep things > > the way they are. > > > > Paul > > Like me. Makes sense. I wonder if we could display somehow that the inset is bold. Otherwise, it might be confusing to the user. One idea would be to apply the bold to the text inside the inset rectangle thing (in this case, to "Note"). Scott signature.asc Description: PGP signature
Odd experience with the Windows installer
I'm trying to help a colleague (on Windoze) whom I persuaded to try LyX (resulting in a borked MiKTeX system). So I decided to install both MiKTeX and LyX on a Win 10 virtual machine running on my Linux PC. My /tmp folder is shared with the VM (as drive X: in Windows), and I parked both installers there. The MiKTeX installation ran fine, and I tested it successfully by exporting the LyX intro help document to TeX and running pdflatex against it. The adventure came when I tried to install LyX. The Windows file explorer showed LyX-230-Installer-005.exe with the correct file size. So did the dir command run in a command shell in the X:\ folder. When I tried to run it (either by double-clicking on the file in file explorer or by running it from the command line), however, the system said it couldn't find the file. (Note that, in the case of the command line, it said this after I used tab completion to fill in the line!) So I went back to Linux, renamed the file in /tmp to "installer.exe", returned to the VM and the installer executed. (It's currently running the config script, which for some reason is excruciatingly slow on this setup.) I don't see anything in the file name that should offend Microsoft's sensibilities, so I'm at a loss as to why it could not find the file that it had no trouble finding. Thought I'd mention it here just in case someone else trips over it. Paul
Re: Indentation bars not adjusted to limited text width
Le 11/09/2018 à 16:05, Scott Kostyshak a écrit : On Tue, Sep 11, 2018 at 10:28:14AM +0200, Jean-Marc Lasgouttes wrote: Le 10/09/2018 à 10:40, Daniel a écrit : When setting Preferences > Editing > Control > Limited text width, the indentation bars are not adjusted to the new text width but stay at the left border of the work area. Is that a bug or a feature? I tend to think its a bug because it makes it harder to see where a bar belongs to. Please file a bug and assign it to me. For archive purposes, the bug was opened here: https://www.lyx.org/trac/ticket/11286 I committed a fix to master. Please try it and tell me whether I broke something. This is a real possibility since this code is a bit mysterious to me. JMarc
Re: Indentation bars not adjusted to limited text width
On Tue, Sep 11, 2018 at 10:28:14AM +0200, Jean-Marc Lasgouttes wrote: > Le 10/09/2018 à 10:40, Daniel a écrit : > > When setting Preferences > Editing > Control > Limited text width, the > > indentation bars are not adjusted to the new text width but stay at the > > left border of the work area. Is that a bug or a feature? I tend to > > think its a bug because it makes it harder to see where a bar belongs > > to. > > Please file a bug and assign it to me. For archive purposes, the bug was opened here: https://www.lyx.org/trac/ticket/11286 Scott signature.asc Description: PGP signature
Re: [LyX/master] Aesthetics: off-by-one in line drawing
On Tue, Sep 11, 2018 at 09:49:24AM +0200, Jean-Marc Lasgouttes wrote: > Le 11/09/2018 à 02:48, Scott Kostyshak a écrit : > > > Scott, would you say it is worth backporting? > > > > I would say only if we want testing (I use the 2.3.x branch the most). > > So we do not really care, right? No, but I appreciate your asking. > Let's skip it, then. Sounds good. Scott signature.asc Description: PGP signature
Re: Crash
On 10/09/2018 12:56, Andrew Parsloe wrote: On 10/09/2018 8:20 p.m., Daniel wrote: On 10/09/2018 08:30, Andrew Parsloe wrote: LyX 2.3.1, windows 7 1. Create a new document, type a letter 2. View the pdf (eyes button) 3. From the pdf 'Save as' to a permanent directory. 4. Close the pdf viewer 5. Click on LyX -- crash. I often work in this way, viewing the pdf, correcting the LyX source, and then 'Saving as' from the pdf in the temp directory to a permanent one. LyX crashes on perhaps 80% of attempts. It seems to 'help' if, after 'Save as', I wait about half a minute before closing the pdf viewer. I use Sumatra, but also tested (once) with Adobe Reader and still got the crash. I can't generate the crash with LyX 2.2.3 (about 4 attempts). Andrew Might be the same or related to this one: https://www.lyx.org/trac/ticket/11210 ? Daniel Yes, exactly that, including the 30 second wait before closing the pdf viewer. Andrew It seems to be a very serious bug nonetheless. I am wondering whether it can be recommended to people working on Windows to update to 2.3 while it isn't fixed. (Once you know how the bug works it's okay, I guess.) Daniel
Re: Indentation bars not adjusted to limited text width
Le 10/09/2018 à 10:40, Daniel a écrit : When setting Preferences > Editing > Control > Limited text width, the indentation bars are not adjusted to the new text width but stay at the left border of the work area. Is that a bug or a feature? I tend to think its a bug because it makes it harder to see where a bar belongs to. Please file a bug and assign it to me. JMarc
Re: [LyX/master] Aesthetics: off-by-one in line drawing
Le 11/09/2018 à 02:48, Scott Kostyshak a écrit : Scott, would you say it is worth backporting? I would say only if we want testing (I use the 2.3.x branch the most). So we do not really care, right? Let's skip it, then. JMarc
