Re: Bug report: "Format cross-references in the work area" is incorrect for included listings

[Richard Kimberly Heck]

On 2/12/24 03:23, Léo de Souza wrote:

On 10/02/2024 01:56, Richard Kimberly Heck wrote:

Should be fixed for RC3, at 91bd457a.

Riki

I confirm that this is fixed in RC3. Thanks a lot.


Thanks!

Riki


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

Re: Bug report: "Format cross-references in the work area" is incorrect for included listings

[Léo de Souza]

On 10/02/2024 01:56, Richard Kimberly Heck wrote:
> Should be fixed for RC3, at 91bd457a.
> 
> Riki

I confirm that this is fixed in RC3. Thanks a lot.

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

Re: Bug report: "Format cross-references in the work area" is incorrect for included listings

[Richard Kimberly Heck]

On 2/7/24 11:57, Richard Kimberly Heck wrote:

On 2/7/24 04:41, Léo de Souza wrote:

Hello,

I would like to report that LyX doesn't show the correct reference in 
the work area for included listings when the option to do so is active.


Environment:

I compiled LyX 2.4.0~RC2 on Ubuntu 22.04 with Qt6 enabled.

Steps to reproduce:

1. Create a new document: File > New
2. Open Document > Settings... and check "Format cross-references in 
the work area"

3. Enter some text and switch the layout to "Section"
4. On a new line, open the dialog to insert a child document: Insert 
> File > Child Document...
5. Add a file name, set the include type to "Program Listing", add a 
label such as "lis:program-listing" and press "OK"

6. Insert a cross-reference to this listing: Insert > Cross-Reference...

Expected result: The reference counter value is shown in the work 
area as "1 (listing)" like it would be for an ordinary listing.


Actual result: The reference counter value is shown in the work area 
as "Section 1".


Thanks for this report. I'll have a look.


Should be fixed for RC3, at 91bd457a.

Riki


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

Re: Bug report: "Format cross-references in the work area" is incorrect for included listings

[Richard Kimberly Heck]

On 2/7/24 04:41, Léo de Souza wrote:

Hello,

I would like to report that LyX doesn't show the correct reference in the work 
area for included listings when the option to do so is active.

Environment:

I compiled LyX 2.4.0~RC2 on Ubuntu 22.04 with Qt6 enabled.

Steps to reproduce:

1. Create a new document: File > New
2. Open Document > Settings... and check "Format cross-references in the work 
area"
3. Enter some text and switch the layout to "Section"
4. On a new line, open the dialog to insert a child document: Insert > File > 
Child Document...
5. Add a file name, set the include type to "Program Listing", add a label such as 
"lis:program-listing" and press "OK"
6. Insert a cross-reference to this listing: Insert > Cross-Reference...

Expected result: The reference counter value is shown in the work area as "1 
(listing)" like it would be for an ordinary listing.

Actual result: The reference counter value is shown in the work area as "Section 
1".


Thanks for this report. I'll have a look.

Riki


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

Bug report: "Format cross-references in the work area" is incorrect for included listings

[Léo de Souza]

Hello,

I would like to report that LyX doesn't show the correct reference in the work 
area for included listings when the option to do so is active.

Environment:

I compiled LyX 2.4.0~RC2 on Ubuntu 22.04 with Qt6 enabled.

Steps to reproduce:

1. Create a new document: File > New
2. Open Document > Settings... and check "Format cross-references in the work 
area"
3. Enter some text and switch the layout to "Section"
4. On a new line, open the dialog to insert a child document: Insert > File > 
Child Document...
5. Add a file name, set the include type to "Program Listing", add a label such 
as "lis:program-listing" and press "OK"
6. Insert a cross-reference to this listing: Insert > Cross-Reference...

Expected result: The reference counter value is shown in the work area as "1 
(listing)" like it would be for an ordinary listing.

Actual result: The reference counter value is shown in the work area as 
"Section 1".
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Bug report: SIGSEGV when copying cross-reference from "description" layout on LyX 2.4.0 beta 5

[Jürgen Spitzmüller]

Am Freitag, dem 15.09.2023 um 16:23 +0200 schrieb Jürgen Spitzmüller:
> Am Freitag, dem 15.09.2023 um 15:41 +0200 schrieb Thibaut Cuvelier:
> > Your patch looks fine to me.
> > 
> > It looks cumbersome, especially if we need to do that several
> > times;
> > maybe we could have a method at the inset level, say
> > getLocalFontOrDefault(const OutputParams&), to return either
> > OutputParams::local_font if it exists or buffer().params()
> > otherwise?
> > It would make correct code (much) easier to write.
> 
> I agree. Do you want to do that?

Did it.

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

Re: [Bug Report] Encoding Problem on Windows 10 while Reconfiguring

[José Matos]

On Mon, 2023-09-18 at 13:28 +0200, Pavel Sanda wrote:
> Actually maybe the python default in lyx's windows release is now v3
> so we don't need to do anything...

My thinking as well. :-)
-- 
José Abílio
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [Bug Report] Encoding Problem on Windows 10 while Reconfiguring

[Pavel Sanda]

On Mon, Sep 18, 2023 at 01:25:34PM +0200, Pavel Sanda wrote:
> On Mon, Sep 18, 2023 at 12:06:52PM +0100, José Matos wrote:
> > On Mon, 2023-09-18 at 10:39 +0200, Pavel Sanda wrote:
> > > Jose, does it mean that you propose patching Python source? Can't we
> > > fix this ourselves?
> > > Pavel
> > 
> > This issue is discussed here. And now I understand why the need for
> > reload:
> > https://stackoverflow.com/questions/3828723/why-should-we-not-use-sys-setdefaultencodingutf-8-in-a-py-script
> > 
> > As far as I can see this is only related with Python 2 (it is
> > unnecessary in Python 3) and so I am quite reluctant to touch this even
> > with a ten foot pole. :-)
> 
> So perhaps we should put this into RELEASE-NOTES?
> Or even remove the statement that we support python 2.7
> from README/INSTALL?

Actually maybe the python default in lyx's windows release is now v3
so we don't need to do anything...

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

Re: [Bug Report] Encoding Problem on Windows 10 while Reconfiguring

[Pavel Sanda]

On Mon, Sep 18, 2023 at 12:06:52PM +0100, José Matos wrote:
> On Mon, 2023-09-18 at 10:39 +0200, Pavel Sanda wrote:
> > Jose, does it mean that you propose patching Python source? Can't we
> > fix this ourselves?
> > Pavel
> 
> This issue is discussed here. And now I understand why the need for
> reload:
> https://stackoverflow.com/questions/3828723/why-should-we-not-use-sys-setdefaultencodingutf-8-in-a-py-script
> 
> As far as I can see this is only related with Python 2 (it is
> unnecessary in Python 3) and so I am quite reluctant to touch this even
> with a ten foot pole. :-)

So perhaps we should put this into RELEASE-NOTES?
Or even remove the statement that we support python 2.7
from README/INSTALL?

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

Re: [Bug Report] Encoding Problem on Windows 10 while Reconfiguring

[José Matos]

On Mon, 2023-09-18 at 10:39 +0200, Pavel Sanda wrote:
> Jose, does it mean that you propose patching Python source? Can't we
> fix this ourselves?
> Pavel

This issue is discussed here. And now I understand why the need for
reload:
https://stackoverflow.com/questions/3828723/why-should-we-not-use-sys-setdefaultencodingutf-8-in-a-py-script

As far as I can see this is only related with Python 2 (it is
unnecessary in Python 3) and so I am quite reluctant to touch this even
with a ten foot pole. :-)

-- 
José Abílio
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [Bug Report] Encoding Problem on Windows 10 while Reconfiguring

[Pavel Sanda]

On Sun, Sep 17, 2023 at 04:55:32PM +0100, José Matos wrote:
> On Sun, 2023-09-17 at 11:48 +0800, Dai Longzhi ? wrote:
> > How to fix:
> > I found a way in Zhihu.com. It add this: 
> > import sys
> > reload(sys)
> > sys.setdefaultencoding("utf-8")
> > in "C:\Program Files\LyX 2.3\Python\Lib\subprocess.py". Then the
> > Reconfiguring works.
> > 
> > I am not sure someone will read this. If anyone readed this, please
> > reply to this mail about the progress. Or I will try other way to
> > feedback this bug.
> 
> The code above only works if you are using python 2.
> By now python 3 is the best choice.
> 
> On the other hand you do not need to reload the module at all. So your
> fix should be enough:
> 
> import sys
> sys.setdefaultencoding("utf-8")

Jose, does it mean that you propose patching Python source? Can't we fix this 
ourselves?
Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [Bug Report] Encoding Problem on Windows 10 while Reconfiguring

[José Matos]

On Sun, 2023-09-17 at 11:48 +0800, Dai Longzhi 戴龙至 wrote:
> How to fix:
> I found a way in Zhihu.com. It add this: 
> import sys
> reload(sys)
> sys.setdefaultencoding("utf-8")
> in "C:\Program Files\LyX 2.3\Python\Lib\subprocess.py". Then the
> Reconfiguring works.
> 
> I am not sure someone will read this. If anyone readed this, please
> reply to this mail about the progress. Or I will try other way to
> feedback this bug.

The code above only works if you are using python 2.
By now python 3 is the best choice.

On the other hand you do not need to reload the module at all. So your
fix should be enough:

import sys
sys.setdefaultencoding("utf-8")

-- 
José Abílio
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

[Bug Report] Encoding Problem on Windows 10 while Reconfiguring

[Dai Longzhi 戴龙至]

Bacis Info  Reproduce:

  System: Windows 10 22H2 64-bit System Language is Chinese (Simplified)


  Lyx: Fresh new installed LyX Version 2.3.7 with Texlive 
full-installed

  Path to Install: C:\Program Files\LyX 
2.3\ # (Non-Chinese Path)





Debug message:
11:09:54.257: (buffer-new: Ctrl+N)



11:09:59.180: Running configure...

11:09:59.248: python -tt "C:/Program Files/LyX 2.3/Resources/configure.py" 
--binary-dir="C:/Program Files/LyX 2.3/bin/"

11:09:59.838: checking for DVI to DTL converter...

11:09:59.839: +checking for "dv2dt"... yes

11:09:59.839: checking for DTL to DVI converter...

11:09:59.839: +checking for "dt2dv"... yes

11:09:59.839: checking for a Latex2e program...

11:09:59.840: +checking for "latex"... yes

11:09:59.840: checking for a DVI postprocessing program...

11:09:59.840: +checking for "pplatex"... no

11:09:59.840: checking for pLaTeX, the Japanese LaTeX...

11:09:59.841: +checking for "platex"... yes

11:09:59.841: Traceback (most recent call last):

11:09:59.841:  File "C:/Program Files/LyX 2.3/Resources/configure.py", 
line 1955, in -- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

[Bug Report] Encoding Problem on Windows 10 while Reconfiguring

[Dai Longzhi 戴龙至]

Bacis Info  Reproduce:

  System: Windows 10 22H2 64-bit System Language is Chinese (Simplified)


  Lyx: Fresh new installed LyX Version 2.3.7 with Texlive 
full-installed

  Path to Install: C:\Program Files\LyX 
2.3\ # (Non-Chinese Path)





Debug message:
11:09:54.257: (buffer-new: Ctrl+N)



11:09:59.180: Running configure...

11:09:59.248: python -tt "C:/Program Files/LyX 2.3/Resources/configure.py" 
--binary-dir="C:/Program Files/LyX 2.3/bin/"

11:09:59.838: checking for DVI to DTL converter...

11:09:59.839: +checking for "dv2dt"... yes

11:09:59.839: checking for DTL to DVI converter...

11:09:59.839: +checking for "dt2dv"... yes

11:09:59.839: checking for a Latex2e program...

11:09:59.840: +checking for "latex"... yes

11:09:59.840: checking for a DVI postprocessing program...

11:09:59.840: +checking for "pplatex"... no

11:09:59.840: checking for pLaTeX, the Japanese LaTeX...

11:09:59.841: +checking for "platex"... yes

11:09:59.841: Traceback (most recent call last):

11:09:59.841:  File "C:/Program Files/LyX 2.3/Resources/configure.py", 
line 1955, in -- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Bug report: Nomenclature no longer works on LyX 2.4.0 beta 5

[Jürgen Spitzmüller]

Am Mittwoch, dem 13.09.2023 um 14:45 +0200 schrieb Léo de Souza:
> I would like to report that the nomenclature function no longer works
> for me on LyX 2.4.0 beta 5.

Thanks. Confirmed and fixed in master.

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

Re: Bug report: SIGSEGV when copying cross-reference from "description" layout on LyX 2.4.0 beta 5

[Jean-Marc Lasgouttes]

Le 15/09/2023 à 16:23, Jürgen Spitzmüller a écrit :

(Wasn't this bug caught at some point by a static analyser? It seems
to be a too common error in C++ for it to slip through.)


Apparently not.


Coverity scan only tags this if in some other places of the code there 
is a test for a null pointer, AFAIU.


JMarc

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

Re: Bug report: SIGSEGV when copying cross-reference from "description" layout on LyX 2.4.0 beta 5

[Jürgen Spitzmüller]

Am Freitag, dem 15.09.2023 um 15:41 +0200 schrieb Thibaut Cuvelier:
> Your patch looks fine to me.
> 
> It looks cumbersome, especially if we need to do that several times;
> maybe we could have a method at the inset level, say
> getLocalFontOrDefault(const OutputParams&), to return either
> OutputParams::local_font if it exists or buffer().params() otherwise?
> It would make correct code (much) easier to write.

I agree. Do you want to do that?

> (Wasn't this bug caught at some point by a static analyser? It seems
> to be a too common error in C++ for it to slip through.)

Apparently not.

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

Re: Bug report: SIGSEGV when copying cross-reference from "description" layout on LyX 2.4.0 beta 5

[Thibaut Cuvelier]

On Fri, 15 Sept 2023 at 11:36, Jürgen Spitzmüller  wrote:

> Am Freitag, dem 15.09.2023 um 10:45 +0200 schrieb Léo de Souza:
> > 1. Create new document: File > New
> > 2. Insert label: Insert > Label...
> > 3. On a new line, switch layout to "Labeling" or "Description"
> > 4. Insert cross-reference: Insert > Cross-Reference...
> > 5. Try copying this cross-reference
> >
> > Expected result (LyX 2.3.6): The cross-reference is copied to the
> > clipboard.
> >
> > Actual result (LyX 2.4.0 beta 5): LyX crashes with the message
> > "SIGSEGV signal caught!"
>
>
> Nullpointer issue due to local_font being non-defined in
> InsetRef::xhtml().
>
> The attached patch fixes this particular case, but there are many
> similar uses in insets's xhtml methods which would need to be audited.
>
> Thibaut, Riki?
>

Your patch looks fine to me.

It looks cumbersome, especially if we need to do that several times; maybe
we could have a method at the inset level, say getLocalFontOrDefault(const
OutputParams&), to return either OutputParams::local_font if it exists or
buffer().params() otherwise? It would make correct code (much) easier to
write.

(Wasn't this bug caught at some point by a static analyser? It seems to be
a too common error in C++ for it to slip through.)
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Bug-report - LyX crash

[Stephan Witt]

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

[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?

JMarc

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

Re: Bug-report - LyX crash

[Stephan Witt]

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: Bug-report - LyX crash

[Pavel Sanda]

On Fri, Sep 15, 2023 at 09:40:08AM +, luxhacker wrote:
> Please create an account for me. I am very interested in LyX.

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

Re: Bug-report - LyX crash

[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?

JMarc


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

Re: Bug-report - LyX crash

[luxhacker]

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. 


Could you please give me some pointers what it could be.

As a bloody beginner, one always makes curious things, and these bugs are 
important because they deter beginners

I shall revert to you.

Best regards, Mathias

Sent with Proton Mail secure email.

--- Original Message ---
On Friday, September 15th, 2023 at 11:18 AM, Pavel Sanda  wrote:


> On Fri, Sep 15, 2023 at 06:39:22AM +, luxhacker wrote:
>
> > New to LyX and appreciating it ! found no way to register. Is this ok ? 
> > therefore mailing bug report
>
>
> It's ok. I can create the account if you are interested.
>
> > What I do before ;) ?
> >
> > Immediately when crashing, I was searching for help (keyword : non breaking 
> > blank -> not found)
>
>
> Can you reproduce your problem again? If yes, can you write us exact recipy 
> so we can try to reproduce on our machines?
>
> Thanks,
> Pavel

publickey - luxhacker@proton.me - 0x467E9812.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Bug report: SIGSEGV when copying cross-reference from "description" layout on LyX 2.4.0 beta 5

[Jürgen Spitzmüller]

Am Freitag, dem 15.09.2023 um 10:45 +0200 schrieb Léo de Souza:
> 1. Create new document: File > New
> 2. Insert label: Insert > Label...
> 3. On a new line, switch layout to "Labeling" or "Description"
> 4. Insert cross-reference: Insert > Cross-Reference...
> 5. Try copying this cross-reference
> 
> Expected result (LyX 2.3.6): The cross-reference is copied to the
> clipboard.
> 
> Actual result (LyX 2.4.0 beta 5): LyX crashes with the message
> "SIGSEGV signal caught!"


Nullpointer issue due to local_font being non-defined in
InsetRef::xhtml().

The attached patch fixes this particular case, but there are many
similar uses in insets's xhtml methods which would need to be audited.

Thibaut, Riki?

-- 
Jürgen
diff --git a/src/insets/InsetRef.cpp b/src/insets/InsetRef.cpp
index 746b9ea870..c7434a6a02 100644
--- a/src/insets/InsetRef.cpp
+++ b/src/insets/InsetRef.cpp
@@ -431,8 +431,11 @@ docstring InsetRef::xhtml(XMLStream & xs, OutputParams const & op) const
 	// appropriate sort of text here. But to do that, we need to associate
 	// some sort of counter with the label, and we don't have that yet.
 	docstring const attr = "href=\"#" + xml::cleanAttr(ref) + '"';
+	string const lang = (op.local_font != nullptr)
+			? op.local_font->language()->lang()
+			: buffer().params().language->lang();
 	xs << xml::StartTag("a", to_utf8(attr));
-	xs << displayString(ref, cmd, op.local_font->language()->lang());;
+	xs << displayString(ref, cmd, lang);
 	xs << xml::EndTag("a");
 	return docstring();
 }
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Bug-report - LyX crash

[Pavel Sanda]

On Fri, Sep 15, 2023 at 06:39:22AM +, luxhacker wrote:
> New to LyX and appreciating it ! found no way to register. Is this ok ? 
> therefore mailing bug report

It's ok. I can create the account if you are interested.

> What I do before ;) ?
> 
> Immediately when crashing, I was searching for help (keyword : non breaking 
> blank -> not found)

Can you reproduce your problem again? If yes, can you write us exact recipy so 
we can try to reproduce on our machines?

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

Re: Bug report: SIGSEGV when copying cross-reference from "description" layout on LyX 2.4.0 beta 5

[Anders Ekberg]

Can repeat on Mac Ventura 13.5.2.

/Anders

> On 15 Sep 2023, at 10:45, Léo de Souza  wrote:
> 
> Hello,
> 
> I would like to report that LyX crashes with SIGSEGV when copying a cross 
> reference from a "labeled list" or "description" layout on LyX 2.4.0 beta 5.
> 
> Environment:
> 
> I compiled LyX 2.4.0 beta 5 on Ubuntu 22.04 with Qt6 enabled and my Tex Live 
> install is up to date.
> 
> Steps to reproduce:
> 
> 1. Create new document: File > New
> 2. Insert label: Insert > Label...
> 3. On a new line, switch layout to "Labeling" or "Description"
> 4. Insert cross-reference: Insert > Cross-Reference...
> 5. Try copying this cross-reference
> 
> Expected result (LyX 2.3.6): The cross-reference is copied to the clipboard.
> 
> Actual result (LyX 2.4.0 beta 5): LyX crashes with the message "SIGSEGV 
> signal caught!"
> 
> Log:
> 
> ```
> (  1) lyx-devel: 
> lyx::frontend::Alert::doError(std::__cxx11::basic_string std::char_traits, std::allocator > const&, 
> std::__cxx11::basic_string, 
> std::allocator > const&, bool)
> (  2) lyx-devel: 
> lyx::frontend::Alert::error(std::__cxx11::basic_string std::char_traits, std::allocator > const&, 
> std::__cxx11::basic_string, 
> std::allocator > const&, bool)
> (  3) lyx-devel: lyx-devel(+0x4d49c7) [0x561db228f9c7]
> (  4) /lib/x86_64-linux-gnu/libc.so.6: 
> /lib/x86_64-linux-gnu/libc.so.6(+0x42520) [0x7f7669100520]
> (  5) lyx-devel: lyx::InsetRef::xhtml[abi:cxx11](lyx::XMLStream&, 
> lyx::OutputParams const&) const
> (  6) lyx-devel: lyx::Paragraph::firstWordLyXHTML(lyx::XMLStream&, 
> lyx::OutputParams const&) const
> (  7) lyx-devel: lyx-devel(+0x522df7) [0x561db22dddf7]
> (  8) lyx-devel: lyx::xhtmlParagraphs(lyx::Text const&, lyx::Buffer const&, 
> lyx::XMLStream&, lyx::OutputParams const&)
> (  9) lyx-devel: lyx::Buffer::writeLyXHTMLSource(std::basic_ostream std::char_traits >&, lyx::OutputParams const&, 
> lyx::Buffer::OutputWhat) const
> ( 10) lyx-devel: lyx-devel(+0x45f751) [0x561db221a751]
> ( 11) lyx-devel: lyx::cap::copySelection(lyx::Cursor const&, 
> std::__cxx11::basic_string, 
> std::allocator > const&)
> ( 12) lyx-devel: lyx::cap::copySelection(lyx::Cursor const&)
> ( 13) lyx-devel: lyx::BufferView::dispatch(lyx::FuncRequest const&, 
> lyx::DispatchResult&)
> ( 14) lyx-devel: 
> lyx::frontend::GuiView::dispatchToBufferView(lyx::FuncRequest const&, 
> lyx::DispatchResult&)
> ( 15) lyx-devel: lyx::frontend::GuiView::dispatch(lyx::FuncRequest const&, 
> lyx::DispatchResult&)
> ( 16) lyx-devel: lyx::frontend::GuiApplication::dispatch(lyx::FuncRequest 
> const&, lyx::DispatchResult&)
> ( 17) lyx-devel: lyx::frontend::GuiApplication::dispatch(lyx::FuncRequest 
> const&)
> ( 18) lyx-devel: lyx::frontend::GuiApplication::processKeySym(lyx::KeySymbol 
> const&, unsigned int)
> ( 19) /lib/x86_64-linux-gnu/libQt6Core.so.6: 
> /lib/x86_64-linux-gnu/libQt6Core.so.6(+0x1ac273) [0x7f76697c7273]
> ( 20) lyx-devel: lyx::frontend::CompressorProxy::signal(lyx::KeySymbol, 
> unsigned int)
> ( 21) lyx-devel: lyx::frontend::CompressorProxy::slot(lyx::KeySymbol, 
> unsigned int, bool)
> ( 22) lyx-devel: lyx-devel(+0x91bcf9) [0x561db26d6cf9]
> ( 23) /lib/x86_64-linux-gnu/libQt6Core.so.6: QObject::event(QEvent*)
> ( 24) /lib/x86_64-linux-gnu/libQt6Widgets.so.6: 
> QApplicationPrivate::notify_helper(QObject*, QEvent*)
> ( 25) lyx-devel: lyx::frontend::GuiApplication::notify(QObject*, QEvent*)
> ( 26) /lib/x86_64-linux-gnu/libQt6Core.so.6: 
> QCoreApplication::notifyInternal2(QObject*, QEvent*)
> ( 27) /lib/x86_64-linux-gnu/libQt6Core.so.6: 
> QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)
> ( 28) /lib/x86_64-linux-gnu/libQt6Core.so.6: 
> /lib/x86_64-linux-gnu/libQt6Core.so.6(+0x37c637) [0x7f7669997637]
> ( 29) /lib/x86_64-linux-gnu/libglib-2.0.so.0: 
> /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x26b) 
> [0x7f7668fd2d3b]
> ( 30) /lib/x86_64-linux-gnu/libglib-2.0.so.0: 
> /lib/x86_64-linux-gnu/libglib-2.0.so.0(+0xab258) [0x7f7669028258]
> ( 31) /lib/x86_64-linux-gnu/libglib-2.0.so.0: 
> /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x33) 
> [0x7f7668fd03e3]
> ( 32) /lib/x86_64-linux-gnu/libQt6Core.so.6: 
> QEventDispatcherGlib::processEvents(QFlags)
> ( 33) /lib/x86_64-linux-gnu/libQt6Core.so.6: 
> QEventLoop::exec(QFlags)
> ( 34) /lib/x86_64-linux-gnu/libQt6Core.so.6: QCoreApplication::exec()
> ( 35) lyx-devel: lyx::LyX::exec(int&, char**)
> ( 36) lyx-devel: lyx-devel(main+0x59) [0x561db2124229]
> ( 37) /lib/x86_64-linux-gnu/libc.so.6: 
> /lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7f76690e7d90]
> ( 38) /lib/x86_64-linux-gnu/libc.so.6: 
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x7f76690e7e40]
> ( 39) lyx-devel: lyx-devel(_start+0x25) [0x561db2132c65]
> ```
> -- 
> 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

Bug report: SIGSEGV when copying cross-reference from "description" layout on LyX 2.4.0 beta 5

[Léo de Souza]

Hello,

I would like to report that LyX crashes with SIGSEGV when copying a cross 
reference from a "labeled list" or "description" layout on LyX 2.4.0 beta 5.

Environment:

I compiled LyX 2.4.0 beta 5 on Ubuntu 22.04 with Qt6 enabled and my Tex Live 
install is up to date.

Steps to reproduce:

1. Create new document: File > New
2. Insert label: Insert > Label...
3. On a new line, switch layout to "Labeling" or "Description"
4. Insert cross-reference: Insert > Cross-Reference...
5. Try copying this cross-reference

Expected result (LyX 2.3.6): The cross-reference is copied to the clipboard.

Actual result (LyX 2.4.0 beta 5): LyX crashes with the message "SIGSEGV signal 
caught!"

Log:

```
(  1) lyx-devel: 
lyx::frontend::Alert::doError(std::__cxx11::basic_string, std::allocator > const&, 
std::__cxx11::basic_string, 
std::allocator > const&, bool)
(  2) lyx-devel: 
lyx::frontend::Alert::error(std::__cxx11::basic_string, std::allocator > const&, 
std::__cxx11::basic_string, 
std::allocator > const&, bool)
(  3) lyx-devel: lyx-devel(+0x4d49c7) [0x561db228f9c7]
(  4) /lib/x86_64-linux-gnu/libc.so.6: 
/lib/x86_64-linux-gnu/libc.so.6(+0x42520) [0x7f7669100520]
(  5) lyx-devel: lyx::InsetRef::xhtml[abi:cxx11](lyx::XMLStream&, 
lyx::OutputParams const&) const
(  6) lyx-devel: lyx::Paragraph::firstWordLyXHTML(lyx::XMLStream&, 
lyx::OutputParams const&) const
(  7) lyx-devel: lyx-devel(+0x522df7) [0x561db22dddf7]
(  8) lyx-devel: lyx::xhtmlParagraphs(lyx::Text const&, lyx::Buffer const&, 
lyx::XMLStream&, lyx::OutputParams const&)
(  9) lyx-devel: lyx::Buffer::writeLyXHTMLSource(std::basic_ostream >&, lyx::OutputParams const&, 
lyx::Buffer::OutputWhat) const
( 10) lyx-devel: lyx-devel(+0x45f751) [0x561db221a751]
( 11) lyx-devel: lyx::cap::copySelection(lyx::Cursor const&, 
std::__cxx11::basic_string, 
std::allocator > const&)
( 12) lyx-devel: lyx::cap::copySelection(lyx::Cursor const&)
( 13) lyx-devel: lyx::BufferView::dispatch(lyx::FuncRequest const&, 
lyx::DispatchResult&)
( 14) lyx-devel: lyx::frontend::GuiView::dispatchToBufferView(lyx::FuncRequest 
const&, lyx::DispatchResult&)
( 15) lyx-devel: lyx::frontend::GuiView::dispatch(lyx::FuncRequest const&, 
lyx::DispatchResult&)
( 16) lyx-devel: lyx::frontend::GuiApplication::dispatch(lyx::FuncRequest 
const&, lyx::DispatchResult&)
( 17) lyx-devel: lyx::frontend::GuiApplication::dispatch(lyx::FuncRequest 
const&)
( 18) lyx-devel: lyx::frontend::GuiApplication::processKeySym(lyx::KeySymbol 
const&, unsigned int)
( 19) /lib/x86_64-linux-gnu/libQt6Core.so.6: 
/lib/x86_64-linux-gnu/libQt6Core.so.6(+0x1ac273) [0x7f76697c7273]
( 20) lyx-devel: lyx::frontend::CompressorProxy::signal(lyx::KeySymbol, 
unsigned int)
( 21) lyx-devel: lyx::frontend::CompressorProxy::slot(lyx::KeySymbol, unsigned 
int, bool)
( 22) lyx-devel: lyx-devel(+0x91bcf9) [0x561db26d6cf9]
( 23) /lib/x86_64-linux-gnu/libQt6Core.so.6: QObject::event(QEvent*)
( 24) /lib/x86_64-linux-gnu/libQt6Widgets.so.6: 
QApplicationPrivate::notify_helper(QObject*, QEvent*)
( 25) lyx-devel: lyx::frontend::GuiApplication::notify(QObject*, QEvent*)
( 26) /lib/x86_64-linux-gnu/libQt6Core.so.6: 
QCoreApplication::notifyInternal2(QObject*, QEvent*)
( 27) /lib/x86_64-linux-gnu/libQt6Core.so.6: 
QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)
( 28) /lib/x86_64-linux-gnu/libQt6Core.so.6: 
/lib/x86_64-linux-gnu/libQt6Core.so.6(+0x37c637) [0x7f7669997637]
( 29) /lib/x86_64-linux-gnu/libglib-2.0.so.0: 
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x26b) 
[0x7f7668fd2d3b]
( 30) /lib/x86_64-linux-gnu/libglib-2.0.so.0: 
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0xab258) [0x7f7669028258]
( 31) /lib/x86_64-linux-gnu/libglib-2.0.so.0: 
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x33) 
[0x7f7668fd03e3]
( 32) /lib/x86_64-linux-gnu/libQt6Core.so.6: 
QEventDispatcherGlib::processEvents(QFlags)
( 33) /lib/x86_64-linux-gnu/libQt6Core.so.6: 
QEventLoop::exec(QFlags)
( 34) /lib/x86_64-linux-gnu/libQt6Core.so.6: QCoreApplication::exec()
( 35) lyx-devel: lyx::LyX::exec(int&, char**)
( 36) lyx-devel: lyx-devel(main+0x59) [0x561db2124229]
( 37) /lib/x86_64-linux-gnu/libc.so.6: 
/lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7f76690e7d90]
( 38) /lib/x86_64-linux-gnu/libc.so.6: 
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x7f76690e7e40]
( 39) lyx-devel: lyx-devel(_start+0x25) [0x561db2132c65]
```
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Bug-report - LyX crash

[luxhacker]

Dear All,

New to LyX and appreciating it ! found no way to register. Is this ok ? 
therefore mailing bug report

Please find hereafter a crash of the LyX-system:

(  1) 1   lyx                                 0x00010bde4ddd 
_ZN3lyx8frontend5Alert7doErrorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b
 : 1   lyx                                 0x00010bde4ddd 
_ZN3lyx8frontend5Alert7doErrorERKNSt3__112basic_stringIwNS2_11char_traitsIwEENS2_9allocatorIwSA_b
 + 199(  2) 2   lyx                                 0x00010bf7a6b1 
_ZN3lyx8frontend18IntoGuiThreadMover18qt_static_metacallEP7QObjectN11QMetaObject4CallEiPPv
 : 2   lyx                                 0x00010bf7a6b1 
_ZN3lyx8frontend18IntoGuiThreadMover18qt_static_metacallEP7QObjectN11QMetaObject4CallEiPPv
 + 115
(  3) 3   QtCore                              0x00010d773894 
_ZN7QObject5eventEP6QEvent : 3   QtCore                              
0x00010d773894 _ZN7QObject5eventEP6QEvent + 900
(  4) 4   QtWidgets                           0x00010caeadf6 
_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent : 4   QtWidgets       
                    0x00010caeadf6 
_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent + 262
(  5) 5   QtWidgets                           0x00010caec1a2 
_ZN12QApplication6notifyEP7QObjectP6QEvent : 5   QtWidgets                      
     0x00010caec1a2 _ZN12QApplication6notifyEP7QObjectP6QEvent + 466
(  6) 6   lyx                                 0x00010bdf3cf3 
_ZN3lyx8frontend14GuiApplication6notifyEP7QObjectP6QEvent : 6   lyx             
                    0x00010bdf3cf3 
_ZN3lyx8frontend14GuiApplication6notifyEP7QObjectP6QEvent + 21
(  7) 7   QtCore                              0x00010d74a0d6 
_ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent : 7   QtCore           
                   0x00010d74a0d6 
_ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent + 166
(  8) 8   QtCore                              0x00010d74b213 
_ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData : 8   
QtCore                              0x00010d74b213 
_ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData + 803
(  9) 9   libqcocoa.dylib                     0x00010dbc4252 
qt_plugin_instance : 9   libqcocoa.dylib                     0x00010dbc4252 
qt_plugin_instance + 197842
( 10) 10  libqcocoa.dylib                     0x00010dbc4958 
qt_plugin_instance : 10  libqcocoa.dylib                     0x00010dbc4958 
qt_plugin_instance + 199640
( 11) 11  CoreFoundation                      0x7ff8190db06a 
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ : 11  CoreFoundation 
                     0x7ff8190db06a 
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
( 12) 12  CoreFoundation                      0x7ff8190db00c 
__CFRunLoopDoSource0 : 12  CoreFoundation                      
0x7ff8190db00c __CFRunLoopDoSource0 + 157
( 13) 13  CoreFoundation                      0x7ff8190dade5 
__CFRunLoopDoSources0 : 13  CoreFoundation                      
0x7ff8190dade5 __CFRunLoopDoSources0 + 217
( 14) 14  CoreFoundation                      0x7ff8190d9a6f __CFRunLoopRun 
: 14  CoreFoundation                      0x7ff8190d9a6f __CFRunLoopRun + 
916
( 15) 15  CoreFoundation                      0x7ff8190d9071 
CFRunLoopRunSpecific : 15  CoreFoundation                      
0x7ff8190d9071 CFRunLoopRunSpecific + 560
( 16) 16  HIToolbox                           0x7ff822b41fcd 
RunCurrentEventLoopInMode : 16  HIToolbox                           
0x7ff822b41fcd RunCurrentEventLoopInMode + 292
( 17) 17  HIToolbox                           0x7ff822b41dde 
ReceiveNextEventCommon : 17  HIToolbox                           
0x7ff822b41dde ReceiveNextEventCommon + 657
( 18) 18  HIToolbox                           0x7ff822b41b38 
_BlockUntilNextEventMatchingListInModeWithFilter : 18  HIToolbox                
           0x7ff822b41b38 _BlockUntilNextEventMatchingListInModeWithFilter 
+ 64
( 19) 19  AppKit                              0x7ff81c16b7a0 _DPSNextEvent 
: 19  AppKit                              0x7ff81c16b7a0 _DPSNextEvent + 858
( 20) 20  AppKit                              0x7ff81c16a64a 
-[NSApplication: 20  AppKit                              0x7ff81c16a64a 
-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] 
+ 1214
( 21) 21  AppKit                              0x7ff81c15ccb8 
-[NSApplication run] : 21  AppKit                              
0x7ff81c15ccb8 -[NSApplication run] + 586
( 22) 22  libqcocoa.dylib                     0x00010dbc3734 
qt_plugin_instance : 22  libqcocoa.dylib                     0x00010dbc3734 
qt_plugin_instance + 194996
( 23) 23  QtCore                              0x00010d7464d7

Bug report: Nomenclature no longer works on LyX 2.4.0 beta 5

[Léo de Souza]

Hi,

I would like to report that the nomenclature function no longer works for me on 
LyX 2.4.0 beta 5.

Environment:

I compiled LyX 2.4.0 beta 5 on Ubuntu 22.04 with Qt6 enabled and my Tex Live 
install is up to date.

Steps to reproduce:

1. Create new document: File > New
2. Insert nomenclature entry: Insert > Nomenclature Entry...
3. Insert nomenclature: Insert > List/Contents/References > Nomenclature
4. View document: Document > View [PDF (pdflatex)]

Expected result (LyX 2.3.6): The output PDF contains a nomenclature.

Actual result (LyX 2.4.0 beta 5): The output PDF does not contain a 
nomenclature.

Additional comment: Saving a file that works in LyX 2.3.6 and opening it from 
LyX 2.4.0 beta 5 also doesn't work.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: #12576: [Bug report] "Insert graphics" does not work anymore [LyX 2.4.0dev]

[Pavel Sanda]

On Tue, Jul 18, 2023 at 10:04:03PM +0200, Christoph Schmitz wrote:
> In the meantime, this problem has been fixed. However, due to a compiler 
> error, I can currently no longer compile LyX on macOS.

Fixed where?
We did not commit the fix yet. (But perhaps you don't use Qt 6.3.1 on platform 
cocoa anymore?)

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

Re: #12576: [Bug report] "Insert graphics" does not work anymore [LyX 2.4.0dev]

[Christoph Schmitz]

In the meantime, this problem has been fixed. However, due to a compiler error, 
I can currently no longer compile LyX on macOS.


> Am 18.07.2023 um 16:25 schrieb LyX Ticket Tracker :
> 
> #12576: [Bug report] "Insert graphics" does not work anymore [LyX 2.4.0dev]
> ---+-
> Reporter:  docc   |   Owner:  lasgouttes
> Type:  defect |  Status:  reopened
> Priority:  high   |   Milestone:  2.4.0
> Component:  general| Version:  2.4.0dev
> Severity:  major  |  Resolution:
> Keywords:  os=macosx  |
> ---+-
> Changes (by sanda):
> 
> * priority:  normal => high
> 
> 
> Comment:
> 
> I consider this to be major issue for 2.4.
> 
> -- 
> Ticket URL: <https://www.lyx.org/trac/ticket/12576#comment:13>
> The LyX Project <https://www.lyx.org/>
> LyX -- The Document Processor

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

Re: #12576: [Bug report] "Insert graphics" does not work anymore [LyX 2.4.0dev]

[Christoph Schmitz]

Hello skostysh,

Sorry, I did not know that.

Best wishes,
Chris


> Am 28.10.2022 um 17:50 schrieb LyX Ticket Tracker :
>
> #12576: [Bug report] "Insert graphics" does not work anymore [LyX 2.4.0dev]
> -+-
> Reporter:  docc |   Owner:  lasgouttes
> Type:  defect   |  Status:  new
> Priority:  normal   |   Milestone:  2.4.0
> Component:  general  | Version:  2.4.0dev
> Severity:  normal   |  Resolution:
> Keywords:   |
> -+-
>
> Comment (by skostysh):
>
> Replying to [comment:2 skostysh]:
>> @docc are you by chance on Ventura?
>
> OP responded by email: "Yes, I am." (@docc although it would be nice,
> email responses are not automatically logged here). Thanks for confirming!
>
> --
> Ticket URL: <https://www.lyx.org/trac/ticket/12576#comment:3>
> The LyX Project <https://www.lyx.org/>
> LyX -- The Document Processor

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

Re: #12576: [Bug report] "Insert graphics" does not work anymore [LyX 2.4.0dev]

[Christoph Schmitz]

Yes, I am.

Von meinem iPhone gesendet

> Am 27.10.2022 um 21:40 schrieb LyX Ticket Tracker :
> 
> #12576: [Bug report] "Insert graphics" does not work anymore [LyX 2.4.0dev]
> -+-
> Reporter:  docc |   Owner:  lasgouttes
> Type:  defect   |  Status:  new
> Priority:  normal   |   Milestone:  2.4.0
> Component:  general  | Version:  2.4.0dev
> Severity:  normal   |  Resolution:
> Keywords:   |
> -+-
> 
> Comment (by skostysh):
> 
> @docc are you by chance on Ventura?
> 
> Here is perhaps a related report:
> https://tex.stackexchange.com/questions/663173/lyx-insert-graphics-dialog-
> closes-when-selecting-an-image
> 
> -- 
> Ticket URL: <https://www.lyx.org/trac/ticket/12576#comment:2>
> The LyX Project <https://www.lyx.org/>
> LyX -- The Document Processor

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

Re: [Bug report] "Insert graphics" does not work anymore

[Pavel Sanda]

On Mon, Oct 10, 2022 at 05:06:20PM +0200, Christoph Schmitz wrote:
> For some time now, "Insert graphics" no longer works in my self-compiled 
> version of LyX 2.4. The window opens and I can search for a file. When I 
> click on "Open", the window disappears, but the graphic file is not inserted. 
> It seems to be a problem with the "file picker". If I enter the Unix file 
> path into the "File:" field manually, it works.
> 
> The problem is still there. In the meantime, I have updated to Qt 6.3.2.
> 
> Version 2.4.0dev (not released yet)
> Built from git commit hash 2c72884f
> Qt Version (run-time): 6.3.2 on platform cocoa
> Qt Version (compile-time): 6.3.2
> Python detected: python3 -tt

Can't reproduce (Qt 5 here).

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

[Bug report] "Insert graphics" does not work anymore

[Christoph Schmitz]

For some time now, "Insert graphics" no longer works in my self-compiled 
version of LyX 2.4. The window opens and I can search for a file. When I click 
on "Open", the window disappears, but the graphic file is not inserted. It 
seems to be a problem with the "file picker". If I enter the Unix file path 
into the "File:" field manually, it works.

The problem is still there. In the meantime, I have updated to Qt 6.3.2.

Version 2.4.0dev (not released yet)
Built from git commit hash 2c72884f
Qt Version (run-time): 6.3.2 on platform cocoa
Qt Version (compile-time): 6.3.2
Python detected: python3 -tt

Best,
Chris

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

Re: Bug Report for LYX.

[Scott Kostyshak]

On Tue, Aug 07, 2018 at 11:36:56AM -0400, Scott Kostyshak wrote:
> On Tue, Aug 07, 2018 at 08:32:39AM +, Valmikanathan S wrote:
> > Hi,
> > 
> >  
> > 
> > Please update the details on how to install with sequence and packages to
> > install for engineering mathematics and mathematical drawing.
> > 
> >  
> > 
> > I am attaching the bug 
> 
> Hi Valmikanathan, can you please send a minimal .lyx file that can
> reproduce the bug that you're seeing? For more information, please see
> here:
> 
> https://wiki.lyx.org/FAQ/MinimalExample
> 
> Thanks for your help in tracking down this bug,

Dear Valmikanathan,

Thanks for your email with further details.

Please always respond to the list. If you respond to me privately, then
I'm the only one that can see your email. If you respond to the list,
then everyone can try to help out.

I took a look at the file you sent me, but it has a lot of ERT. Is it
possible to create a minimal example without the ERT? Please read here
for more information:

  https://wiki.lyx.org/FAQ/MinimalExample

Best,

Scott


signature.asc
Description: PGP signature

Re: Bug Report for LYX.

[Scott Kostyshak]

On Tue, Aug 07, 2018 at 08:32:39AM +, Valmikanathan S wrote:
> Hi,
> 
>  
> 
> Please update the details on how to install with sequence and packages to
> install for engineering mathematics and mathematical drawing.
> 
>  
> 
> I am attaching the bug 

Hi Valmikanathan, can you please send a minimal .lyx file that can
reproduce the bug that you're seeing? For more information, please see
here:

https://wiki.lyx.org/FAQ/MinimalExample

Thanks for your help in tracking down this bug,

Scott


signature.asc
Description: PGP signature

Bug Report for LYX.

[Valmikanathan S]

Hi,

 

Please update the details on how to install with sequence and packages to
install for engineering mathematics and mathematical drawing.

 

I am attaching the bug 

When I try to export to pdf from LYX after
typing the mathematics 12th grade exam papers.

 

 

Please do the needful.

 

Regards

Valmikanathan S

13:51:30.553: Exporting ...
13:51:30.584: (buffer-export odt)
13:51:30.631: pdflatex  "+2_10_Marks.tex"Undo.cpp (566): +++ Creating new 
group 236 for buffer 0x703f6d0
frontends/qt4/GuiApplication.cpp (1576): cmd:  action: 337 [buffer-export]  
arg: 'odt' x: 0 y: 0
support/FileName.cpp (423): Directory D:/Latex is writable
BufferParams.cpp (2438): setBaseClass: article
TextClass.cpp (333): Reading cite engine: [citeengines/basic.citeengine]
Lexer.cpp (257): lyxlex: UNcompressed
Lexer.cpp (336): Comment read: `35 \DeclareLyXCiteEngine{Basic (BibTeX)}'
Lexer.cpp (336): Comment read: `35 DescriptionBegin'
Lexer.cpp (336): Comment read: `35   The basic citation capabilities provided 
by BibTeX.'
Lexer.cpp (336): Comment read: `35   Mainly simple numeric styles primarily 
suitable for science and maths.'
Lexer.cpp (336): Comment read: `35 DescriptionEnd'
Lexer.cpp (336): Comment read: `35 Author: Julien Rioux '
Lexer.cpp (336): Comment read: `35 The framework (biblatex|bibtex)'
Lexer.cpp (336): Comment read: `35 Cite style variants 
(default|authoryear|natbib)'
Lexer.cpp (336): Comment read: `35 We provide only default citations'
Lexer.cpp (336): Comment read: `35 Default style file'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 CITE COMMAND DEFINITIONS for either engine 
type'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 (cf. natbib.citeengine for a decription of 
the syntax)'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 CITE FORMAT'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 Input standard format definitions for the 
bibliography'
TextClass.cpp (333): Reading input file: [layouts/stdciteformats.inc]
Lexer.cpp (257): lyxlex: UNcompressed
Lexer.cpp (336): Comment read: `35 Standard formats for bibliography entries.'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 This defines how LyX displays bibliographic 
information in the GUI'
Lexer.cpp (336): Comment read: `35 as well as in text/xhtml output. The format 
of citation references'
Lexer.cpp (336): Comment read: `35 is defined in the *.citeengines files, which 
might override the'
Lexer.cpp (336): Comment read: `35 default formatting defined here.'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 This file is included by the citation 
engines, so there is no need'
Lexer.cpp (336): Comment read: `35 to include it in individual classes.'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 Author: Richard Heck '
Lexer.cpp (336): Comment read: `35 Jürgen Spitzmüller '
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 Translatable bits (need to be marked by _ 
prefix, if translated to the GUI language,'
Lexer.cpp (336): Comment read: `35 or B_, if translated to the buffer language)'
Lexer.cpp (336): Comment read: `35 Note that preceding and trailing spaces 
matter.'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 The following are handled by BiblioInfo. 
Note that preceding and trailing spaces matter'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 Macros'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 Scheme of the first author in the 
bibliography'
Lexer.cpp (336): Comment read: `35 Scheme of other authors in the bibliography'
Lexer.cpp (336): Comment read: `35 Scheme of the first name in later parts 
(such as book editor)'
Lexer.cpp (336): Comment read: `35 Scheme of other authors in later parts (such 
as book editor)'
Lexer.cpp (336): Comment read: `35 Scheme of authors in citation references'
Lexer.cpp (336): Comment read: `35 pagination'
Lexer.cpp (336): Comment read: `35 ed. or eds.'
Lexer.cpp (336): Comment read: `35 author or editor, as fullnames, following 
the schemes above'
Lexer.cpp (336): Comment read: `35 "vol. 1, no.'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 Entry types. Note that final punctuation 
will be added later, if needed.'
Lexer.cpp (336): Comment read: `35'
TextClass.cpp (346): Finished reading input file: [layouts/stdciteformats.inc]
Lexer.cpp (336): Comment read: `35 The following defines how the commands are 
represented in the GUI'
Lexer.cpp (336): Comment read: `35 (inset button and citation dialog) as well 
as in XHTML, docbook and'
Lexer.cpp (336): Comment read: `35 plain text output.'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 MACROS'
Lexer.cpp (336): Comment read: `35'
Lexer.cpp (336): Comment read: `35 1. Translatable 

Re: Bug report

[Kornel Benko]

Am Samstag, 25. Februar 2017 um 13:57:24, schrieb Jakub Bystron 
<j...@pickro.com>
> Linux Mint 18.1, compiled from the official sources 2.2.2.
> 
>  /home/jb/newfile1.lyx.emergency
> 
> lyx: SIGSEGV signal caught!
> Sorry, you have found a bug in LyX, hope you have not lost any data.
> Please read the bug-reporting instructions in 'Help->Introduction' and send 
> us a bug report, if necessary. Thanks!
> Bye.
> Error: LyX crashed!
> 
> SIGSEGV signal caught!
> Sorry, you have found a bug in LyX, hope you have not lost any data.
> Please read the bug-reporting instructions in 'Help->Introduction' and send 
> us a bug report, if necessary. Thanks!
> Bye.
> (  1) lyx: lyx() [0x87cea4]
> (  2) lyx: lyx() [0x87be3b]
> (  3) lyx: lyx() [0x57440c]
> (  4) /lib/x86_64-linux-gnu/libc.so.6: 
> /lib/x86_64-linux-gnu/libc.so.6(+0x354b0) [0x7f4f367924b0]
> (  5) [0x7f4f24b060e0]: [0x7f4f24b060e0]
> Aborted

Could you please give more info?
1.) How did you compile
2.) What have you done to get the crash
3.) What is the QT version, gcc version

Kornel

signature.asc
Description: This is a digitally signed message part.

Bug report

[Jakub Bystron]

Linux Mint 18.1, compiled from the official sources 2.2.2.

 /home/jb/newfile1.lyx.emergency

lyx: SIGSEGV signal caught!
Sorry, you have found a bug in LyX, hope you have not lost any data.
Please read the bug-reporting instructions in 'Help->Introduction' and send us 
a bug report, if necessary. Thanks!
Bye.
Error: LyX crashed!

SIGSEGV signal caught!
Sorry, you have found a bug in LyX, hope you have not lost any data.
Please read the bug-reporting instructions in 'Help->Introduction' and send us 
a bug report, if necessary. Thanks!
Bye.
(  1) lyx: lyx() [0x87cea4]
(  2) lyx: lyx() [0x87be3b]
(  3) lyx: lyx() [0x57440c]
(  4) /lib/x86_64-linux-gnu/libc.so.6: 
/lib/x86_64-linux-gnu/libc.so.6(+0x354b0) [0x7f4f367924b0]
(  5) [0x7f4f24b060e0]: [0x7f4f24b060e0]
Aborted

Re: Advanced search bug report

[Scott Kostyshak]

On Sun, Jun 21, 2015 at 10:02:52AM +, Moon, Jong-Myun wrote:
 Hello,
 
 
 First of all, thank you guys for the wonderful program.
 
 
 I guess I found a bug regarding the advanced search. After I tried to search 
 for a math expression several times, when I clicked the advanced search 
 button, it pops up an empty window.

Hi Jong-Myun,

Thank you for your feedback. It is important that if you do not get a
response, to try again. We are a small group of volunteers so sometimes
we miss emails, but we would not want to miss something important like a
bug. So please keep trying if you think you have found a bug.

Also, in *any* bug report, please always give details on your operating
system and the version of software that you're using. In this case, what
is your OS and what version of LyX do you use?

 Also, when I first open LyX and recall the advanced search, it pops up a very 
 small window. So I need to enlarge it manually.

I hope I fixed this for 2.2.0 at 6c3a6ea9.

 After enlarging it, there is a small glitch (I think) in the UI.

When I look at your screenshot, the window is empty. This is a big glitch, no?

Thanks for helping us to improve LyX!

Please respond to the list (and not to me personally).

Best,

Scott

Re: Advanced search bug report

[Scott Kostyshak]

On Sun, Jun 21, 2015 at 10:02:52AM +, Moon, Jong-Myun wrote:
> Hello,
> 
> 
> First of all, thank you guys for the wonderful program.
> 
> 
> I guess I found a bug regarding the advanced search. After I tried to search 
> for a math expression several times, when I clicked the advanced search 
> button, it pops up an empty window.

Hi Jong-Myun,

Thank you for your feedback. It is important that if you do not get a
response, to try again. We are a small group of volunteers so sometimes
we miss emails, but we would not want to miss something important like a
bug. So please keep trying if you think you have found a bug.

Also, in *any* bug report, please always give details on your operating
system and the version of software that you're using. In this case, what
is your OS and what version of LyX do you use?

> Also, when I first open LyX and recall the advanced search, it pops up a very 
> small window. So I need to enlarge it manually.

I hope I fixed this for 2.2.0 at 6c3a6ea9.

> After enlarging it, there is a small glitch (I think) in the UI.

When I look at your screenshot, the window is empty. This is a big glitch, no?

Thanks for helping us to improve LyX!

Please respond to the list (and not to me personally).

Best,

Scott

Advanced search bug report

[Moon, Jong-Myun]

Hello,


First of all, thank you guys for the wonderful program.


I guess I found a bug regarding the advanced search. After I tried to search 
for a math expression several times, when I clicked the advanced search button, 
it pops up an empty window.


Also, when I first open LyX and recall the advanced search, it pops up a very 
small window. So I need to enlarge it manually. After enlarging it, there is a 
small glitch (I think) in the UI.


I attach screen shots for the above problems.



Cheers,

JM

Advanced search bug report

[Moon, Jong-Myun]

Hello,


First of all, thank you guys for the wonderful program.


I guess I found a bug regarding the advanced search. After I tried to search 
for a math expression several times, when I clicked the advanced search button, 
it pops up an empty window.


Also, when I first open LyX and recall the advanced search, it pops up a very 
small window. So I need to enlarge it manually. After enlarging it, there is a 
small glitch (I think) in the UI.


I attach screen shots for the above problems.



Cheers,

JM

Re: #9028: Bug report of replace feature

[Richard Heck]

On 03/09/2014 10:44 PM, Tommaso Cucinotta wrote:

On 10/03/14 02:27, LyX Ticket Tracker wrote:

  About update, I have a question: would it reset my preference setting?
  Cause I spent a lot of time to set LyX, like fonts, output form, etc.

The most annoying side effect, if you update, is that the new version of
LyX saves files with an updated LyX file format, that is not recognized by
your older LyX version. So, once you save with an updated LyX, you can't
open the file with your older LyX any more, in case you want to go back.


Though of course you can export to an older format.


Concerning preferences and everything else in you .lyx/, if you configure
with --with-exe-suffix=-whatever (or similar, can't remember the exact option 
name),
then it will use $HOME/.lyx-whatever and your prefs will be safe.


Though this will not transfer your old preferences. If you're worried 
about going back AND want
to use your old preferences, then copy them to $HOME/.lyx-whatever 
before you start.


Richard



T.

Re: #9028: Bug report of replace feature

[Richard Heck]

On 03/09/2014 10:44 PM, Tommaso Cucinotta wrote:

On 10/03/14 02:27, LyX Ticket Tracker wrote:

  About update, I have a question: would it reset my preference setting?
  Cause I spent a lot of time to set LyX, like fonts, output form, etc.

The most annoying side effect, if you update, is that the new version of
LyX saves files with an updated LyX file format, that is not recognized by
your older LyX version. So, once you save with an updated LyX, you can't
open the file with your older LyX any more, in case you want to go back.


Though of course you can export to an older format.


Concerning preferences and everything else in you .lyx/, if you configure
with --with-exe-suffix=-whatever (or similar, can't remember the exact option 
name),
then it will use $HOME/.lyx-whatever and your prefs will be safe.


Though this will not transfer your old preferences. If you're worried 
about going back AND want
to use your old preferences, then copy them to $HOME/.lyx-whatever 
before you start.


Richard



T.

Re: #9028: Bug report of replace feature

[Tommaso Cucinotta]

On 10/03/14 02:27, LyX Ticket Tracker wrote:
  About update, I have a question: would it reset my preference setting?
  Cause I spent a lot of time to set LyX, like fonts, output form, etc.

The most annoying side effect, if you update, is that the new version of
LyX saves files with an updated LyX file format, that is not recognized by
your older LyX version. So, once you save with an updated LyX, you can't
open the file with your older LyX any more, in case you want to go back.

Concerning preferences and everything else in you .lyx/, if you configure
with --with-exe-suffix=-whatever (or similar, can't remember the exact option 
name),
then it will use $HOME/.lyx-whatever and your prefs will be safe.

T.

Re: #9028: Bug report of replace feature

[Tommaso Cucinotta]

On 10/03/14 02:27, LyX Ticket Tracker wrote:
>  About update, I have a question: would it reset my preference setting?
>  Cause I spent a lot of time to set LyX, like fonts, output form, etc.

The most annoying side effect, if you update, is that the new version of
LyX saves files with an updated LyX file format, that is not recognized by
your older LyX version. So, once you save with an updated LyX, you can't
open the file with your older LyX any more, in case you want to go back.

Concerning preferences and everything else in you .lyx/, if you configure
with --with-exe-suffix=-whatever (or similar, can't remember the exact option 
name),
then it will use $HOME/.lyx-whatever and your prefs will be safe.

T.

Re: Bug report of replace feature

[Scott Kostyshak]

On Sat, Mar 8, 2014 at 2:12 AM, Yu-Fei yufe...@gmail.com wrote:
 When use the find/replace feature to replace the latex code in a formula
 of display mode, the LyX will breakdown.

 For emample:

 There is a display math formula:
 {\Phi_{x}}=\operatorname{diag}{\left\{ {e^{{\alpha_{k\right\}
 _{k=1:K}}\hfill

 Now, I want to replace the code \hfill to a, but when I use the
 find/repace feature, LyX will stop working suddenly.

Hi Yu Fei,

Thanks for the report. This is the documentation list. I'm forwarding
your bug report to the developer list.

Best,

Scott

Re: Bug report of replace feature

[Scott Kostyshak]

On Sat, Mar 8, 2014 at 2:12 AM, Yu-Fei <yufe...@gmail.com> wrote:
> When use the "find/replace" feature to replace the latex code in a formula
> of display mode, the LyX will breakdown.
>
> For emample:
>
> There is a display math formula:
> {\Phi_{x}}=\operatorname{diag}{\left\{ {e^{{\alpha_{k\right\}
> _{k=1:K}}\hfill
>
> Now, I want to replace the code "\hfill" to "a", but when I use the
> "find/repace" feature, LyX will stop working suddenly.

Hi Yu Fei,

Thanks for the report. This is the documentation list. I'm forwarding
your bug report to the developer list.

Best,

Scott

Re: Patch for 2.0.7 on OSX [was Re: bug report]

[Jean-Marc Lasgouttes]

16/01/2014 15:29, Stephan Witt:

Affecting more code is not a problem IMO. Does the createView() flash a window 
on the screen?


Yes, but it doesn't flash, it remains open. After all, it's a work around. :(
The proper solution requires the handling of e.g. Preferences in GuiApplication.


Agreed on both counts. This patch is IMO OK for now.

JMarc

Re: Patch for 2.0.7 on OSX [was Re: bug report]

[Richard Heck]

On 01/20/2014 09:01 AM, Jean-Marc Lasgouttes wrote:

16/01/2014 15:29, Stephan Witt:
Affecting more code is not a problem IMO. Does the createView() 
flash a window on the screen?


Yes, but it doesn't flash, it remains open. After all, it's a work 
around. :(
The proper solution requires the handling of e.g. Preferences in 
GuiApplication.


Agreed on both counts. This patch is IMO OK for now.


OK, well, let's get it committed and get 2.0.7 out the door.

rh

Re: Patch for 2.0.7 on OSX [was Re: bug report]

[Stephan Witt]

Am 20.01.2014 um 17:26 schrieb Richard Heck rgh...@lyx.org:

 On 01/20/2014 09:01 AM, Jean-Marc Lasgouttes wrote:
 16/01/2014 15:29, Stephan Witt:
 Affecting more code is not a problem IMO. Does the createView() flash a 
 window on the screen?
 
 Yes, but it doesn't flash, it remains open. After all, it's a work around. 
 :(
 The proper solution requires the handling of e.g. Preferences in 
 GuiApplication.
 
 Agreed on both counts. This patch is IMO OK for now.
 
 OK, well, let's get it committed and get 2.0.7 out the door.

I did it.

Stephan

Re: Patch for 2.0.7 on OSX [was Re: bug report]

[Jean-Marc Lasgouttes]

16/01/2014 15:29, Stephan Witt:

Affecting more code is not a problem IMO. Does the createView() flash a window 
on the screen?


Yes, but it doesn't flash, it remains open. After all, it's a work around. :(
The proper solution requires the handling of e.g. Preferences in GuiApplication.


Agreed on both counts. This patch is IMO OK for now.

JMarc

Re: Patch for 2.0.7 on OSX [was Re: bug report]

[Richard Heck]

On 01/20/2014 09:01 AM, Jean-Marc Lasgouttes wrote:

16/01/2014 15:29, Stephan Witt:
Affecting more code is not a problem IMO. Does the createView() 
flash a window on the screen?


Yes, but it doesn't flash, it remains open. After all, it's a work 
around. :(
The proper solution requires the handling of e.g. Preferences in 
GuiApplication.


Agreed on both counts. This patch is IMO OK for now.


OK, well, let's get it committed and get 2.0.7 out the door.

rh

Re: Patch for 2.0.7 on OSX [was Re: bug report]

[Stephan Witt]

Am 20.01.2014 um 17:26 schrieb Richard Heck :

> On 01/20/2014 09:01 AM, Jean-Marc Lasgouttes wrote:
>> 16/01/2014 15:29, Stephan Witt:
 Affecting more code is not a problem IMO. Does the createView() flash a 
 window on the screen?
>>> 
>>> Yes, but it doesn't flash, it remains open. After all, it's a work around. 
>>> :(
>>> The proper solution requires the handling of e.g. Preferences in 
>>> GuiApplication.
>> 
>> Agreed on both counts. This patch is IMO OK for now.
> 
> OK, well, let's get it committed and get 2.0.7 out the door.

I did it.

Stephan

Re: Patch for 2.0.7 on OSX [was Re: bug report]

[Jean-Marc Lasgouttes]

16/01/2014 07:32, Stephan Witt:

Attached is a patch to work around a bug with crash on view close on Mac OSX.
See also https://bugreports.qt-project.org/browse/QTBUG-25399

Is anyone able to verify or comment it?


I am unfortunately no in a position to test it out. My only comment is 
that the whole handling of dialogs that do not require a view is broken 
and should be moved to GuiApplication. The code in GuiApplication should 
not be guarded by #ifdef, you could just add a comment that this 
normally only trigger with Mac OS. This way the code is always compiled in.


In a precedent version of the patch, you created a dummy view to do the 
dispatch. How come it is not necessary anymore? How is the dispatch done?


JMarc

Re: Patch for 2.0.7 on OSX [was Re: bug report]

[Stephan Witt]

Am 16.01.2014 um 10:49 schrieb Jean-Marc Lasgouttes lasgout...@lyx.org:

 16/01/2014 07:32, Stephan Witt:
 Attached is a patch to work around a bug with crash on view close on Mac OSX.
 See also https://bugreports.qt-project.org/browse/QTBUG-25399
 
 Is anyone able to verify or comment it?
 
 I am unfortunately no in a position to test it out. My only comment is that 
 the whole handling of dialogs that do not require a view is broken and should 
 be moved to GuiApplication. The code in GuiApplication should not be guarded 
 by #ifdef, you could just add a comment that this normally only trigger with 
 Mac OS.

That's not true, IMHO.

The dispatch and getstatus calls are made for application first and the for the 
view.
The platform doesn't matter here. 
It's different for a Mac to have a menu bar without any view.
But you're right if you meant to say it works on any platform.

 This way the code is always compiled in.
 
 In a precedent version of the patch, you created a dummy view to do the 
 dispatch. How come it is not necessary anymore? How is the dispatch done?


Yes, you're right. This is not handled intentionally. This and the #ifdefs was 
made to reduce the size of the impact of the patch.

I'll attach another patch
* without #ifdef
* with dummy view to do the dispatch

This works better, but affects the code more.

Stephan


macMenuBar-6.patch
Description: Binary data

Re: Patch for 2.0.7 on OSX [was Re: bug report]

[Jean-Marc Lasgouttes]

16/01/2014 13:23, Stephan Witt:

The dispatch and getstatus calls are made for application first and the for the 
view.
The platform doesn't matter here.
It's different for a Mac to have a menu bar without any view.
But you're right if you meant to say it works on any platform.


I thought that the GuiApplication part came last (which would make more 
sense IMO).



I'll attach another patch
* without #ifdef
* with dummy view to do the dispatch

This works better, but affects the code more.


Affecting more code is not a problem IMO. Does the createView() flash a 
window on the screen?


JMarc

Re: Patch for 2.0.7 on OSX [was Re: bug report]

[Stephan Witt]

Am 16.01.2014 um 14:37 schrieb Jean-Marc Lasgouttes lasgout...@lyx.org:

 16/01/2014 13:23, Stephan Witt:
 The dispatch and getstatus calls are made for application first and the for 
 the view.
 The platform doesn't matter here.
 It's different for a Mac to have a menu bar without any view.
 But you're right if you meant to say it works on any platform.
 
 I thought that the GuiApplication part came last (which would make more sense 
 IMO).

I had to verify that myself. :) But, it's like that.

The central dispatch calls theApp()-dispatch(action) where the switch 
statement waits
to do it's work. The default: of the GuiApplication::dispatch passes it to the 
current
GuiView::dispatch if there is one.

 I'll attach another patch
 * without #ifdef
 * with dummy view to do the dispatch
 
 This works better, but affects the code more.
 
 Affecting more code is not a problem IMO. Does the createView() flash a 
 window on the screen?

Yes, but it doesn't flash, it remains open. After all, it's a work around. :(
The proper solution requires the handling of e.g. Preferences in GuiApplication.

Stephan

Re: Patch for 2.0.7 on OSX [was Re: bug report]

[Jean-Marc Lasgouttes]

16/01/2014 07:32, Stephan Witt:

Attached is a patch to work around a bug with crash on view close on Mac OSX.
See also https://bugreports.qt-project.org/browse/QTBUG-25399

Is anyone able to verify or comment it?


I am unfortunately no in a position to test it out. My only comment is 
that the whole handling of dialogs that do not require a view is broken 
and should be moved to GuiApplication. The code in GuiApplication should 
not be guarded by #ifdef, you could just add a comment that this 
normally only trigger with Mac OS. This way the code is always compiled in.


In a precedent version of the patch, you created a dummy view to do the 
dispatch. How come it is not necessary anymore? How is the dispatch done?


JMarc

Re: Patch for 2.0.7 on OSX [was Re: bug report]

[Stephan Witt]

Am 16.01.2014 um 10:49 schrieb Jean-Marc Lasgouttes :

> 16/01/2014 07:32, Stephan Witt:
>> Attached is a patch to work around a bug with crash on view close on Mac OSX.
>> See also https://bugreports.qt-project.org/browse/QTBUG-25399
>> 
>> Is anyone able to verify or comment it?
> 
> I am unfortunately no in a position to test it out. My only comment is that 
> the whole handling of dialogs that do not require a view is broken and should 
> be moved to GuiApplication. The code in GuiApplication should not be guarded 
> by #ifdef, you could just add a comment that this normally only trigger with 
> Mac OS.

That's not true, IMHO.

The dispatch and getstatus calls are made for application first and the for the 
view.
The platform doesn't matter here. 
It's different for a Mac to have a menu bar without any view.
But you're right if you meant to say it works on any platform.

> This way the code is always compiled in.
> 
> In a precedent version of the patch, you created a dummy view to do the 
> dispatch. How come it is not necessary anymore? How is the dispatch done?


Yes, you're right. This is not handled intentionally. This and the #ifdefs was 
made to reduce the size of the impact of the patch.

I'll attach another patch
* without #ifdef
* with dummy view to do the dispatch

This works better, but affects the code more.

Stephan


macMenuBar-6.patch
Description: Binary data

Re: Patch for 2.0.7 on OSX [was Re: bug report]

[Jean-Marc Lasgouttes]

16/01/2014 13:23, Stephan Witt:

The dispatch and getstatus calls are made for application first and the for the 
view.
The platform doesn't matter here.
It's different for a Mac to have a menu bar without any view.
But you're right if you meant to say it works on any platform.


I thought that the GuiApplication part came last (which would make more 
sense IMO).



I'll attach another patch
* without #ifdef
* with dummy view to do the dispatch

This works better, but affects the code more.


Affecting more code is not a problem IMO. Does the createView() flash a 
window on the screen?


JMarc

Re: Patch for 2.0.7 on OSX [was Re: bug report]

[Stephan Witt]

Am 16.01.2014 um 14:37 schrieb Jean-Marc Lasgouttes :

> 16/01/2014 13:23, Stephan Witt:
>> The dispatch and getstatus calls are made for application first and the for 
>> the view.
>> The platform doesn't matter here.
>> It's different for a Mac to have a menu bar without any view.
>> But you're right if you meant to say it works on any platform.
> 
> I thought that the GuiApplication part came last (which would make more sense 
> IMO).

I had to verify that myself. :) But, it's like that.

The central dispatch calls theApp()->dispatch(action) where the switch 
statement waits
to do it's work. The default: of the GuiApplication::dispatch passes it to the 
current
GuiView::dispatch if there is one.

>> I'll attach another patch
>> * without #ifdef
>> * with dummy view to do the dispatch
>> 
>> This works better, but affects the code more.
> 
> Affecting more code is not a problem IMO. Does the createView() flash a 
> window on the screen?

Yes, but it doesn't flash, it remains open. After all, it's a work around. :(
The proper solution requires the handling of e.g. Preferences in GuiApplication.

Stephan

2.0.7 on OSX [was Re: bug report]

[Richard Heck]

Where do we stand now with 2.0.7 on Mac?

Richard


On 01/07/2014 03:30 AM, Stephan Witt wrote:

Am 06.01.2014 um 16:58 schrieb Richard Heck rgh...@lyx.org:


On 01/06/2014 02:37 AM, Stephan Witt wrote:

Am 05.01.2014 um 22:28 schrieb Jean-Marc Lasgouttes lasgout...@lyx.org:


Le 05/01/2014 21:35, Stephan Witt a écrit :

This looks interesting - from the Qt docs:

If you want all windows in a Mac application to share one menu bar, you must 
create a menu bar that does not have a parent.
Create a parent-less menu bar this way:
  QMenuBar *menuBar = new QMenuBar(0);
Note: Do not call QMainWindow::menuBar() to create the shared menu bar, because that 
menu bar will have theQMainWindow as its parent. That menu bar would only be 
displayed for the parent QMainWindow.

This is the relevant code from LyX:

GuiView.cpp, lines 434 and 435:

// Fill up the menu bar.
guiApp-menus().fillMenuBar(menuBar(), this, true);

So, it's done exactly the wrong way.

This is indeed quite interesting, but might be for master only for now. OTOH, 
having Reconfigure inserted only once might be good for 2.0.7. I cannot test it 
myself, unfortunately. Maybe the static array could have a bool member 
indicating whether the said entry has already been handled and in this case one 
would skip it.

I tried this already and it didn't help. It crashes nevertheless.
The QMenuBar has to be without view parent or the move to the Application menu 
shouldn't happen, IMHO.

The attached patch (for trunk) improves the situation. There are only 2 global 
QMenuBar instances on Mac then.

But there are related problems: see bug 6902 
(http://www.lyx.org/trac/ticket/6902)
IMHO, LyX isn't aware of the situation when having no view open. Is this a 
possible scenario on Linux too?

With this patch there is no crash and the Reconfigure menu is an Application 
menu item.
But the dialog actions for About and Preferences are usable only while having 
any view open.
Perhaps the LFUN code has to be moved to the GuiApplication class somehow too.

This all looks like stuff for master and too adventurous for 2.0.x indeed.

I'll try to find a less intrusive solution for branch.

OK. I will wait.

I cannot find any other solution instead of using the static global QMenuBar 
instance on Mac.

The attached patch does:
* enable the About and Preferences dialog application wide on Mac
* use static global QMenuBar instead of view related instance on Mac
* do the Mac specific menu bar init only the first time

All changes are inside #ifdef Q_WS_MACX blocks.

This works for me and nothing else.

One drawback I can see: the About and Preferences dialog don't show up if there 
is no view.

Stephan

Re: 2.0.7 on OSX [was Re: bug report]

[Stephan Witt]

Am 15.01.2014 um 16:04 schrieb Richard Heck rgh...@lyx.org:

 Where do we stand now with 2.0.7 on Mac?

I'd appreciate some feedback for by patch. Without this patch LyX (Cocoa-build)
crashes while closing the 2nd GuiView instance.

LyX 2.0.6 was Cocoa based and I don't want to change that.

Stephan
  
 On 01/07/2014 03:30 AM, Stephan Witt wrote:
 Am 06.01.2014 um 16:58 schrieb Richard Heck rgh...@lyx.org:
 
 On 01/06/2014 02:37 AM, Stephan Witt wrote:
 Am 05.01.2014 um 22:28 schrieb Jean-Marc Lasgouttes lasgout...@lyx.org:
 
 Le 05/01/2014 21:35, Stephan Witt a écrit :
 This looks interesting - from the Qt docs:
 
 If you want all windows in a Mac application to share one menu bar, you 
 must create a menu bar that does not have a parent.
 Create a parent-less menu bar this way:
  QMenuBar *menuBar = new QMenuBar(0);
 Note: Do not call QMainWindow::menuBar() to create the shared menu bar, 
 because that menu bar will have theQMainWindow as its parent. That menu 
 bar would only be displayed for the parent QMainWindow.
 
 This is the relevant code from LyX:
 
 GuiView.cpp, lines 434 and 435:
 
  // Fill up the menu bar.
  guiApp-menus().fillMenuBar(menuBar(), this, true);
 
 So, it's done exactly the wrong way.
 This is indeed quite interesting, but might be for master only for now. 
 OTOH, having Reconfigure inserted only once might be good for 2.0.7. I 
 cannot test it myself, unfortunately. Maybe the static array could have a 
 bool member indicating whether the said entry has already been handled 
 and in this case one would skip it.
 I tried this already and it didn't help. It crashes nevertheless.
 The QMenuBar has to be without view parent or the move to the Application 
 menu shouldn't happen, IMHO.
 
 The attached patch (for trunk) improves the situation. There are only 2 
 global QMenuBar instances on Mac then.
 
 But there are related problems: see bug 6902 
 (http://www.lyx.org/trac/ticket/6902)
 IMHO, LyX isn't aware of the situation when having no view open. Is this a 
 possible scenario on Linux too?
 
 With this patch there is no crash and the Reconfigure menu is an 
 Application menu item.
 But the dialog actions for About and Preferences are usable only while 
 having any view open.
 Perhaps the LFUN code has to be moved to the GuiApplication class somehow 
 too.
 
 This all looks like stuff for master and too adventurous for 2.0.x indeed.
 
 I'll try to find a less intrusive solution for branch.
 OK. I will wait.
 I cannot find any other solution instead of using the static global QMenuBar 
 instance on Mac.
 
 The attached patch does:
 * enable the About and Preferences dialog application wide on Mac
 * use static global QMenuBar instead of view related instance on Mac
 * do the Mac specific menu bar init only the first time
 
 All changes are inside #ifdef Q_WS_MACX blocks.
 
 This works for me and nothing else.
 
 One drawback I can see: the About and Preferences dialog don't show up if 
 there is no view.
 
 Stephan
 
 

Re: 2.0.7 on OSX [was Re: bug report]

[Richard Heck]

On 01/15/2014 10:14 AM, Stephan Witt wrote:

Am 15.01.2014 um 16:04 schrieb Richard Heck rgh...@lyx.org:


Where do we stand now with 2.0.7 on Mac?

I'd appreciate some feedback for by patch. Without this patch LyX (Cocoa-build)
crashes while closing the 2nd GuiView instance.

LyX 2.0.6 was Cocoa based and I don't want to change that.


I'm too uninformed. But can you post the patch again, with an 
appropriate subject line?


rh


Stephan
   

On 01/07/2014 03:30 AM, Stephan Witt wrote:

Am 06.01.2014 um 16:58 schrieb Richard Heck rgh...@lyx.org:


On 01/06/2014 02:37 AM, Stephan Witt wrote:

Am 05.01.2014 um 22:28 schrieb Jean-Marc Lasgouttes lasgout...@lyx.org:


Le 05/01/2014 21:35, Stephan Witt a écrit :

This looks interesting - from the Qt docs:

If you want all windows in a Mac application to share one menu bar, you must 
create a menu bar that does not have a parent.
Create a parent-less menu bar this way:
  QMenuBar *menuBar = new QMenuBar(0);
Note: Do not call QMainWindow::menuBar() to create the shared menu bar, because that 
menu bar will have theQMainWindow as its parent. That menu bar would only be 
displayed for the parent QMainWindow.

This is the relevant code from LyX:

GuiView.cpp, lines 434 and 435:

// Fill up the menu bar.
guiApp-menus().fillMenuBar(menuBar(), this, true);

So, it's done exactly the wrong way.

This is indeed quite interesting, but might be for master only for now. OTOH, 
having Reconfigure inserted only once might be good for 2.0.7. I cannot test it 
myself, unfortunately. Maybe the static array could have a bool member 
indicating whether the said entry has already been handled and in this case one 
would skip it.

I tried this already and it didn't help. It crashes nevertheless.
The QMenuBar has to be without view parent or the move to the Application menu 
shouldn't happen, IMHO.

The attached patch (for trunk) improves the situation. There are only 2 global 
QMenuBar instances on Mac then.

But there are related problems: see bug 6902 
(http://www.lyx.org/trac/ticket/6902)
IMHO, LyX isn't aware of the situation when having no view open. Is this a 
possible scenario on Linux too?

With this patch there is no crash and the Reconfigure menu is an Application 
menu item.
But the dialog actions for About and Preferences are usable only while having 
any view open.
Perhaps the LFUN code has to be moved to the GuiApplication class somehow too.

This all looks like stuff for master and too adventurous for 2.0.x indeed.

I'll try to find a less intrusive solution for branch.

OK. I will wait.

I cannot find any other solution instead of using the static global QMenuBar 
instance on Mac.

The attached patch does:
* enable the About and Preferences dialog application wide on Mac
* use static global QMenuBar instead of view related instance on Mac
* do the Mac specific menu bar init only the first time

All changes are inside #ifdef Q_WS_MACX blocks.

This works for me and nothing else.

One drawback I can see: the About and Preferences dialog don't show up if there 
is no view.

Stephan

Patch for 2.0.7 on OSX [was Re: bug report]

[Stephan Witt]

Attached is a patch to work around a bug with crash on view close on Mac OSX.
See also https://bugreports.qt-project.org/browse/QTBUG-25399

Is anyone able to verify or comment it?

Stephan

Am 15.01.2014 um 18:22 schrieb Richard Heck rgh...@lyx.org:

 On 01/15/2014 10:14 AM, Stephan Witt wrote:
 Am 15.01.2014 um 16:04 schrieb Richard Heck rgh...@lyx.org:
 
 Where do we stand now with 2.0.7 on Mac?
 I'd appreciate some feedback for by patch. Without this patch LyX 
 (Cocoa-build)
 crashes while closing the 2nd GuiView instance.
 
 LyX 2.0.6 was Cocoa based and I don't want to change that.
 
 I'm too uninformed. But can you post the patch again, with an appropriate 
 subject line?
 
 rh
 
 Stephan
   
 On 01/07/2014 03:30 AM, Stephan Witt wrote:
 Am 06.01.2014 um 16:58 schrieb Richard Heck rgh...@lyx.org:
 
 On 01/06/2014 02:37 AM, Stephan Witt wrote:
 Am 05.01.2014 um 22:28 schrieb Jean-Marc Lasgouttes lasgout...@lyx.org:
 
 Le 05/01/2014 21:35, Stephan Witt a écrit :
 This looks interesting - from the Qt docs:
 
 If you want all windows in a Mac application to share one menu bar, 
 you must create a menu bar that does not have a parent.
 Create a parent-less menu bar this way:
  QMenuBar *menuBar = new QMenuBar(0);
 Note: Do not call QMainWindow::menuBar() to create the shared menu 
 bar, because that menu bar will have theQMainWindow as its parent. 
 That menu bar would only be displayed for the parent QMainWindow.
 
 This is the relevant code from LyX:
 
 GuiView.cpp, lines 434 and 435:
 
// Fill up the menu bar.
guiApp-menus().fillMenuBar(menuBar(), this, true);
 
 So, it's done exactly the wrong way.
 This is indeed quite interesting, but might be for master only for now. 
 OTOH, having Reconfigure inserted only once might be good for 2.0.7. I 
 cannot test it myself, unfortunately. Maybe the static array could have 
 a bool member indicating whether the said entry has already been 
 handled and in this case one would skip it.
 I tried this already and it didn't help. It crashes nevertheless.
 The QMenuBar has to be without view parent or the move to the 
 Application menu shouldn't happen, IMHO.
 
 The attached patch (for trunk) improves the situation. There are only 2 
 global QMenuBar instances on Mac then.
 
 But there are related problems: see bug 6902 
 (http://www.lyx.org/trac/ticket/6902)
 IMHO, LyX isn't aware of the situation when having no view open. Is this 
 a possible scenario on Linux too?
 
 With this patch there is no crash and the Reconfigure menu is an 
 Application menu item.
 But the dialog actions for About and Preferences are usable only while 
 having any view open.
 Perhaps the LFUN code has to be moved to the GuiApplication class 
 somehow too.
 
 This all looks like stuff for master and too adventurous for 2.0.x 
 indeed.
 
 I'll try to find a less intrusive solution for branch.
 OK. I will wait.
 I cannot find any other solution instead of using the static global 
 QMenuBar instance on Mac.
 
 The attached patch does:
 * enable the About and Preferences dialog application wide on Mac
 * use static global QMenuBar instead of view related instance on Mac
 * do the Mac specific menu bar init only the first time
 
 All changes are inside #ifdef Q_WS_MACX blocks.
 
 This works for me and nothing else.
 
 One drawback I can see: the About and Preferences dialog don't show up if 
 there is no view.


macMenuBar-3.patch
Description: Binary data

2.0.7 on OSX [was Re: bug report]

[Richard Heck]

Where do we stand now with 2.0.7 on Mac?

Richard


On 01/07/2014 03:30 AM, Stephan Witt wrote:

Am 06.01.2014 um 16:58 schrieb Richard Heck :


On 01/06/2014 02:37 AM, Stephan Witt wrote:

Am 05.01.2014 um 22:28 schrieb Jean-Marc Lasgouttes :


Le 05/01/2014 21:35, Stephan Witt a écrit :

This looks interesting - from the Qt docs:

"If you want all windows in a Mac application to share one menu bar, you must 
create a menu bar that does not have a parent.
Create a parent-less menu bar this way:
  QMenuBar *menuBar = new QMenuBar(0);
Note: Do not call QMainWindow::menuBar() to create the shared menu bar, because that 
menu bar will have theQMainWindow as its parent. That menu bar would only be 
displayed for the parent QMainWindow."

This is the relevant code from LyX:

GuiView.cpp, lines 434 and 435:

// Fill up the menu bar.
guiApp->menus().fillMenuBar(menuBar(), this, true);

So, it's done exactly the wrong way.

This is indeed quite interesting, but might be for master only for now. OTOH, 
having Reconfigure inserted only once might be good for 2.0.7. I cannot test it 
myself, unfortunately. Maybe the static array could have a bool member 
indicating whether the said entry has already been handled and in this case one 
would skip it.

I tried this already and it didn't help. It crashes nevertheless.
The QMenuBar has to be without view parent or the move to the Application menu 
shouldn't happen, IMHO.

The attached patch (for trunk) improves the situation. There are only 2 global 
QMenuBar instances on Mac then.

But there are related problems: see bug 6902 
(http://www.lyx.org/trac/ticket/6902)
IMHO, LyX isn't aware of the situation when having no view open. Is this a 
possible scenario on Linux too?

With this patch there is no crash and the Reconfigure menu is an Application 
menu item.
But the dialog actions for About and Preferences are usable only while having 
any view open.
Perhaps the LFUN code has to be moved to the GuiApplication class somehow too.

This all looks like stuff for master and too adventurous for 2.0.x indeed.

I'll try to find a less intrusive solution for branch.

OK. I will wait.

I cannot find any other solution instead of using the static global QMenuBar 
instance on Mac.

The attached patch does:
* enable the About and Preferences dialog application wide on Mac
* use static global QMenuBar instead of view related instance on Mac
* do the Mac specific menu bar init only the first time

All changes are inside #ifdef Q_WS_MACX blocks.

This works for me and nothing else.

One drawback I can see: the About and Preferences dialog don't show up if there 
is no view.

Stephan

Re: 2.0.7 on OSX [was Re: bug report]

[Stephan Witt]

Am 15.01.2014 um 16:04 schrieb Richard Heck :

> Where do we stand now with 2.0.7 on Mac?

I'd appreciate some feedback for by patch. Without this patch LyX (Cocoa-build)
crashes while closing the 2nd GuiView instance.

LyX 2.0.6 was Cocoa based and I don't want to change that.

Stephan
  
> On 01/07/2014 03:30 AM, Stephan Witt wrote:
>> Am 06.01.2014 um 16:58 schrieb Richard Heck :
>> 
>>> On 01/06/2014 02:37 AM, Stephan Witt wrote:
 Am 05.01.2014 um 22:28 schrieb Jean-Marc Lasgouttes :
 
> Le 05/01/2014 21:35, Stephan Witt a écrit :
>> This looks interesting - from the Qt docs:
>> 
>> "If you want all windows in a Mac application to share one menu bar, you 
>> must create a menu bar that does not have a parent.
>> Create a parent-less menu bar this way:
>>  QMenuBar *menuBar = new QMenuBar(0);
>> Note: Do not call QMainWindow::menuBar() to create the shared menu bar, 
>> because that menu bar will have theQMainWindow as its parent. That menu 
>> bar would only be displayed for the parent QMainWindow."
>> 
>> This is the relevant code from LyX:
>> 
>> GuiView.cpp, lines 434 and 435:
>> 
>>  // Fill up the menu bar.
>>  guiApp->menus().fillMenuBar(menuBar(), this, true);
>> 
>> So, it's done exactly the wrong way.
> This is indeed quite interesting, but might be for master only for now. 
> OTOH, having Reconfigure inserted only once might be good for 2.0.7. I 
> cannot test it myself, unfortunately. Maybe the static array could have a 
> bool member indicating whether the said entry has already been handled 
> and in this case one would skip it.
 I tried this already and it didn't help. It crashes nevertheless.
 The QMenuBar has to be without view parent or the move to the Application 
 menu shouldn't happen, IMHO.
 
 The attached patch (for trunk) improves the situation. There are only 2 
 global QMenuBar instances on Mac then.
 
 But there are related problems: see bug 6902 
 (http://www.lyx.org/trac/ticket/6902)
 IMHO, LyX isn't aware of the situation when having no view open. Is this a 
 possible scenario on Linux too?
 
 With this patch there is no crash and the Reconfigure menu is an 
 Application menu item.
 But the dialog actions for About and Preferences are usable only while 
 having any view open.
 Perhaps the LFUN code has to be moved to the GuiApplication class somehow 
 too.
 
 This all looks like stuff for master and too adventurous for 2.0.x indeed.
 
 I'll try to find a less intrusive solution for branch.
>>> OK. I will wait.
>> I cannot find any other solution instead of using the static global QMenuBar 
>> instance on Mac.
>> 
>> The attached patch does:
>> * enable the About and Preferences dialog application wide on Mac
>> * use static global QMenuBar instead of view related instance on Mac
>> * do the Mac specific menu bar init only the first time
>> 
>> All changes are inside #ifdef Q_WS_MACX blocks.
>> 
>> This works for me and nothing else.
>> 
>> One drawback I can see: the About and Preferences dialog don't show up if 
>> there is no view.
>> 
>> Stephan
>> 
> 

Re: 2.0.7 on OSX [was Re: bug report]

[Richard Heck]

On 01/15/2014 10:14 AM, Stephan Witt wrote:

Am 15.01.2014 um 16:04 schrieb Richard Heck :


Where do we stand now with 2.0.7 on Mac?

I'd appreciate some feedback for by patch. Without this patch LyX (Cocoa-build)
crashes while closing the 2nd GuiView instance.

LyX 2.0.6 was Cocoa based and I don't want to change that.


I'm too uninformed. But can you post the patch again, with an 
appropriate subject line?


rh


Stephan
   

On 01/07/2014 03:30 AM, Stephan Witt wrote:

Am 06.01.2014 um 16:58 schrieb Richard Heck :


On 01/06/2014 02:37 AM, Stephan Witt wrote:

Am 05.01.2014 um 22:28 schrieb Jean-Marc Lasgouttes :


Le 05/01/2014 21:35, Stephan Witt a écrit :

This looks interesting - from the Qt docs:

"If you want all windows in a Mac application to share one menu bar, you must 
create a menu bar that does not have a parent.
Create a parent-less menu bar this way:
  QMenuBar *menuBar = new QMenuBar(0);
Note: Do not call QMainWindow::menuBar() to create the shared menu bar, because that 
menu bar will have theQMainWindow as its parent. That menu bar would only be 
displayed for the parent QMainWindow."

This is the relevant code from LyX:

GuiView.cpp, lines 434 and 435:

// Fill up the menu bar.
guiApp->menus().fillMenuBar(menuBar(), this, true);

So, it's done exactly the wrong way.

This is indeed quite interesting, but might be for master only for now. OTOH, 
having Reconfigure inserted only once might be good for 2.0.7. I cannot test it 
myself, unfortunately. Maybe the static array could have a bool member 
indicating whether the said entry has already been handled and in this case one 
would skip it.

I tried this already and it didn't help. It crashes nevertheless.
The QMenuBar has to be without view parent or the move to the Application menu 
shouldn't happen, IMHO.

The attached patch (for trunk) improves the situation. There are only 2 global 
QMenuBar instances on Mac then.

But there are related problems: see bug 6902 
(http://www.lyx.org/trac/ticket/6902)
IMHO, LyX isn't aware of the situation when having no view open. Is this a 
possible scenario on Linux too?

With this patch there is no crash and the Reconfigure menu is an Application 
menu item.
But the dialog actions for About and Preferences are usable only while having 
any view open.
Perhaps the LFUN code has to be moved to the GuiApplication class somehow too.

This all looks like stuff for master and too adventurous for 2.0.x indeed.

I'll try to find a less intrusive solution for branch.

OK. I will wait.

I cannot find any other solution instead of using the static global QMenuBar 
instance on Mac.

The attached patch does:
* enable the About and Preferences dialog application wide on Mac
* use static global QMenuBar instead of view related instance on Mac
* do the Mac specific menu bar init only the first time

All changes are inside #ifdef Q_WS_MACX blocks.

This works for me and nothing else.

One drawback I can see: the About and Preferences dialog don't show up if there 
is no view.

Stephan

Patch for 2.0.7 on OSX [was Re: bug report]

[Stephan Witt]

Attached is a patch to work around a bug with crash on view close on Mac OSX.
See also https://bugreports.qt-project.org/browse/QTBUG-25399

Is anyone able to verify or comment it?

Stephan

Am 15.01.2014 um 18:22 schrieb Richard Heck :

> On 01/15/2014 10:14 AM, Stephan Witt wrote:
>> Am 15.01.2014 um 16:04 schrieb Richard Heck :
>> 
>>> Where do we stand now with 2.0.7 on Mac?
>> I'd appreciate some feedback for by patch. Without this patch LyX 
>> (Cocoa-build)
>> crashes while closing the 2nd GuiView instance.
>> 
>> LyX 2.0.6 was Cocoa based and I don't want to change that.
> 
> I'm too uninformed. But can you post the patch again, with an appropriate 
> subject line?
> 
> rh
>> 
>> Stephan
>>   
>>> On 01/07/2014 03:30 AM, Stephan Witt wrote:
 Am 06.01.2014 um 16:58 schrieb Richard Heck :
 
> On 01/06/2014 02:37 AM, Stephan Witt wrote:
>> Am 05.01.2014 um 22:28 schrieb Jean-Marc Lasgouttes :
>> 
>>> Le 05/01/2014 21:35, Stephan Witt a écrit :
 This looks interesting - from the Qt docs:
 
 "If you want all windows in a Mac application to share one menu bar, 
 you must create a menu bar that does not have a parent.
 Create a parent-less menu bar this way:
  QMenuBar *menuBar = new QMenuBar(0);
 Note: Do not call QMainWindow::menuBar() to create the shared menu 
 bar, because that menu bar will have theQMainWindow as its parent. 
 That menu bar would only be displayed for the parent QMainWindow."
 
 This is the relevant code from LyX:
 
 GuiView.cpp, lines 434 and 435:
 
// Fill up the menu bar.
guiApp->menus().fillMenuBar(menuBar(), this, true);
 
 So, it's done exactly the wrong way.
>>> This is indeed quite interesting, but might be for master only for now. 
>>> OTOH, having Reconfigure inserted only once might be good for 2.0.7. I 
>>> cannot test it myself, unfortunately. Maybe the static array could have 
>>> a bool member indicating whether the said entry has already been 
>>> handled and in this case one would skip it.
>> I tried this already and it didn't help. It crashes nevertheless.
>> The QMenuBar has to be without view parent or the move to the 
>> Application menu shouldn't happen, IMHO.
>> 
>> The attached patch (for trunk) improves the situation. There are only 2 
>> global QMenuBar instances on Mac then.
>> 
>> But there are related problems: see bug 6902 
>> (http://www.lyx.org/trac/ticket/6902)
>> IMHO, LyX isn't aware of the situation when having no view open. Is this 
>> a possible scenario on Linux too?
>> 
>> With this patch there is no crash and the Reconfigure menu is an 
>> Application menu item.
>> But the dialog actions for About and Preferences are usable only while 
>> having any view open.
>> Perhaps the LFUN code has to be moved to the GuiApplication class 
>> somehow too.
>> 
>> This all looks like stuff for master and too adventurous for 2.0.x 
>> indeed.
>> 
>> I'll try to find a less intrusive solution for branch.
> OK. I will wait.
 I cannot find any other solution instead of using the static global 
 QMenuBar instance on Mac.
 
 The attached patch does:
 * enable the About and Preferences dialog application wide on Mac
 * use static global QMenuBar instead of view related instance on Mac
 * do the Mac specific menu bar init only the first time
 
 All changes are inside #ifdef Q_WS_MACX blocks.
 
 This works for me and nothing else.
 
 One drawback I can see: the About and Preferences dialog don't show up if 
 there is no view.


macMenuBar-3.patch
Description: Binary data

Re: bug report

[Stephan Witt]

Am 07.01.2014 um 09:30 schrieb Stephan Witt st.w...@gmx.net:

 Am 06.01.2014 um 16:58 schrieb Richard Heck rgh...@lyx.org:
 
 On 01/06/2014 02:37 AM, Stephan Witt wrote:
 Am 05.01.2014 um 22:28 schrieb Jean-Marc Lasgouttes lasgout...@lyx.org:
 
 Le 05/01/2014 21:35, Stephan Witt a écrit :
 This looks interesting - from the Qt docs:
 
 If you want all windows in a Mac application to share one menu bar, you 
 must create a menu bar that does not have a parent.
 Create a parent-less menu bar this way:
 QMenuBar *menuBar = new QMenuBar(0);
 Note: Do not call QMainWindow::menuBar() to create the shared menu bar, 
 because that menu bar will have theQMainWindow as its parent. That menu 
 bar would only be displayed for the parent QMainWindow.
 
 This is the relevant code from LyX:
 
 GuiView.cpp, lines 434 and 435:
 
   // Fill up the menu bar.
   guiApp-menus().fillMenuBar(menuBar(), this, true);
 
 So, it's done exactly the wrong way.
 This is indeed quite interesting, but might be for master only for now. 
 OTOH, having Reconfigure inserted only once might be good for 2.0.7. I 
 cannot test it myself, unfortunately. Maybe the static array could have a 
 bool member indicating whether the said entry has already been handled and 
 in this case one would skip it.
 
 I tried this already and it didn't help. It crashes nevertheless.
 The QMenuBar has to be without view parent or the move to the Application 
 menu shouldn't happen, IMHO.
 
 The attached patch (for trunk) improves the situation. There are only 2 
 global QMenuBar instances on Mac then.
 
 But there are related problems: see bug 6902 
 (http://www.lyx.org/trac/ticket/6902)
 IMHO, LyX isn't aware of the situation when having no view open. Is this a 
 possible scenario on Linux too?
 
 With this patch there is no crash and the Reconfigure menu is an 
 Application menu item.
 But the dialog actions for About and Preferences are usable only while 
 having any view open.
 Perhaps the LFUN code has to be moved to the GuiApplication class somehow 
 too.
 
 This all looks like stuff for master and too adventurous for 2.0.x indeed.
 
 I'll try to find a less intrusive solution for branch.
 
 OK. I will wait.
 
 I cannot find any other solution instead of using the static global QMenuBar 
 instance on Mac.
 
 The attached patch does:
 * enable the About and Preferences dialog application wide on Mac
 * use static global QMenuBar instead of view related instance on Mac
 * do the Mac specific menu bar init only the first time
 
 All changes are inside #ifdef Q_WS_MACX blocks.
 
 This works for me and nothing else.
 
 One drawback I can see: the About and Preferences dialog don't show up if 
 there is no view.

This patch is for trunk and fixes the About and Preferences dialog drawback too.
Thus, it fixes the crash and bug 6902 (http://www.lyx.org/trac/ticket/6902).

I want to apply it if no one objects.

Stephan



macMenuBar-5.patch
Description: Binary data

Re: bug report

[Stephan Witt]

Am 07.01.2014 um 09:30 schrieb Stephan Witt :

> Am 06.01.2014 um 16:58 schrieb Richard Heck :
> 
>> On 01/06/2014 02:37 AM, Stephan Witt wrote:
>>> Am 05.01.2014 um 22:28 schrieb Jean-Marc Lasgouttes :
>>> 
 Le 05/01/2014 21:35, Stephan Witt a écrit :
> This looks interesting - from the Qt docs:
> 
> "If you want all windows in a Mac application to share one menu bar, you 
> must create a menu bar that does not have a parent.
> Create a parent-less menu bar this way:
> QMenuBar *menuBar = new QMenuBar(0);
> Note: Do not call QMainWindow::menuBar() to create the shared menu bar, 
> because that menu bar will have theQMainWindow as its parent. That menu 
> bar would only be displayed for the parent QMainWindow."
> 
> This is the relevant code from LyX:
> 
> GuiView.cpp, lines 434 and 435:
> 
>   // Fill up the menu bar.
>   guiApp->menus().fillMenuBar(menuBar(), this, true);
> 
> So, it's done exactly the wrong way.
 This is indeed quite interesting, but might be for master only for now. 
 OTOH, having Reconfigure inserted only once might be good for 2.0.7. I 
 cannot test it myself, unfortunately. Maybe the static array could have a 
 bool member indicating whether the said entry has already been handled and 
 in this case one would skip it.
>>> 
>>> I tried this already and it didn't help. It crashes nevertheless.
>>> The QMenuBar has to be without view parent or the move to the Application 
>>> menu shouldn't happen, IMHO.
>>> 
>>> The attached patch (for trunk) improves the situation. There are only 2 
>>> global QMenuBar instances on Mac then.
>>> 
>>> But there are related problems: see bug 6902 
>>> (http://www.lyx.org/trac/ticket/6902)
>>> IMHO, LyX isn't aware of the situation when having no view open. Is this a 
>>> possible scenario on Linux too?
>>> 
>>> With this patch there is no crash and the Reconfigure menu is an 
>>> Application menu item.
>>> But the dialog actions for About and Preferences are usable only while 
>>> having any view open.
>>> Perhaps the LFUN code has to be moved to the GuiApplication class somehow 
>>> too.
>>> 
>>> This all looks like stuff for master and too adventurous for 2.0.x indeed.
>>> 
>>> I'll try to find a less intrusive solution for branch.
>> 
>> OK. I will wait.
> 
> I cannot find any other solution instead of using the static global QMenuBar 
> instance on Mac.
> 
> The attached patch does:
> * enable the About and Preferences dialog application wide on Mac
> * use static global QMenuBar instead of view related instance on Mac
> * do the Mac specific menu bar init only the first time
> 
> All changes are inside #ifdef Q_WS_MACX blocks.
> 
> This works for me and nothing else.
> 
> One drawback I can see: the About and Preferences dialog don't show up if 
> there is no view.

This patch is for trunk and fixes the About and Preferences dialog drawback too.
Thus, it fixes the crash and bug 6902 (http://www.lyx.org/trac/ticket/6902).

I want to apply it if no one objects.

Stephan



macMenuBar-5.patch
Description: Binary data

Re: bug report

[Stephan Witt]

Am 06.01.2014 um 16:58 schrieb Richard Heck rgh...@lyx.org:

 On 01/06/2014 02:37 AM, Stephan Witt wrote:
 Am 05.01.2014 um 22:28 schrieb Jean-Marc Lasgouttes lasgout...@lyx.org:
 
 Le 05/01/2014 21:35, Stephan Witt a écrit :
 This looks interesting - from the Qt docs:
 
 If you want all windows in a Mac application to share one menu bar, you 
 must create a menu bar that does not have a parent.
 Create a parent-less menu bar this way:
  QMenuBar *menuBar = new QMenuBar(0);
 Note: Do not call QMainWindow::menuBar() to create the shared menu bar, 
 because that menu bar will have theQMainWindow as its parent. That menu 
 bar would only be displayed for the parent QMainWindow.
 
 This is the relevant code from LyX:
 
 GuiView.cpp, lines 434 and 435:
 
// Fill up the menu bar.
guiApp-menus().fillMenuBar(menuBar(), this, true);
 
 So, it's done exactly the wrong way.
 This is indeed quite interesting, but might be for master only for now. 
 OTOH, having Reconfigure inserted only once might be good for 2.0.7. I 
 cannot test it myself, unfortunately. Maybe the static array could have a 
 bool member indicating whether the said entry has already been handled and 
 in this case one would skip it.
 
 I tried this already and it didn't help. It crashes nevertheless.
 The QMenuBar has to be without view parent or the move to the Application 
 menu shouldn't happen, IMHO.
 
 The attached patch (for trunk) improves the situation. There are only 2 
 global QMenuBar instances on Mac then.
 
 But there are related problems: see bug 6902 
 (http://www.lyx.org/trac/ticket/6902)
 IMHO, LyX isn't aware of the situation when having no view open. Is this a 
 possible scenario on Linux too?
 
 With this patch there is no crash and the Reconfigure menu is an Application 
 menu item.
 But the dialog actions for About and Preferences are usable only while 
 having any view open.
 Perhaps the LFUN code has to be moved to the GuiApplication class somehow 
 too.
 
 This all looks like stuff for master and too adventurous for 2.0.x indeed.
 
 I'll try to find a less intrusive solution for branch.
 
 OK. I will wait.

I cannot find any other solution instead of using the static global QMenuBar 
instance on Mac.

The attached patch does:
* enable the About and Preferences dialog application wide on Mac
* use static global QMenuBar instead of view related instance on Mac
* do the Mac specific menu bar init only the first time

All changes are inside #ifdef Q_WS_MACX blocks.

This works for me and nothing else.

One drawback I can see: the About and Preferences dialog don't show up if there 
is no view.

Stephan



macMenuBar-3.patch
Description: Binary data

Re: bug report

[Stephan Witt]

Am 06.01.2014 um 16:58 schrieb Richard Heck :

> On 01/06/2014 02:37 AM, Stephan Witt wrote:
>> Am 05.01.2014 um 22:28 schrieb Jean-Marc Lasgouttes :
>> 
>>> Le 05/01/2014 21:35, Stephan Witt a écrit :
 This looks interesting - from the Qt docs:
 
 "If you want all windows in a Mac application to share one menu bar, you 
 must create a menu bar that does not have a parent.
 Create a parent-less menu bar this way:
  QMenuBar *menuBar = new QMenuBar(0);
 Note: Do not call QMainWindow::menuBar() to create the shared menu bar, 
 because that menu bar will have theQMainWindow as its parent. That menu 
 bar would only be displayed for the parent QMainWindow."
 
 This is the relevant code from LyX:
 
 GuiView.cpp, lines 434 and 435:
 
// Fill up the menu bar.
guiApp->menus().fillMenuBar(menuBar(), this, true);
 
 So, it's done exactly the wrong way.
>>> This is indeed quite interesting, but might be for master only for now. 
>>> OTOH, having Reconfigure inserted only once might be good for 2.0.7. I 
>>> cannot test it myself, unfortunately. Maybe the static array could have a 
>>> bool member indicating whether the said entry has already been handled and 
>>> in this case one would skip it.
>> 
>> I tried this already and it didn't help. It crashes nevertheless.
>> The QMenuBar has to be without view parent or the move to the Application 
>> menu shouldn't happen, IMHO.
>> 
>> The attached patch (for trunk) improves the situation. There are only 2 
>> global QMenuBar instances on Mac then.
>> 
>> But there are related problems: see bug 6902 
>> (http://www.lyx.org/trac/ticket/6902)
>> IMHO, LyX isn't aware of the situation when having no view open. Is this a 
>> possible scenario on Linux too?
>> 
>> With this patch there is no crash and the Reconfigure menu is an Application 
>> menu item.
>> But the dialog actions for About and Preferences are usable only while 
>> having any view open.
>> Perhaps the LFUN code has to be moved to the GuiApplication class somehow 
>> too.
>> 
>> This all looks like stuff for master and too adventurous for 2.0.x indeed.
>> 
>> I'll try to find a less intrusive solution for branch.
> 
> OK. I will wait.

I cannot find any other solution instead of using the static global QMenuBar 
instance on Mac.

The attached patch does:
* enable the About and Preferences dialog application wide on Mac
* use static global QMenuBar instead of view related instance on Mac
* do the Mac specific menu bar init only the first time

All changes are inside #ifdef Q_WS_MACX blocks.

This works for me and nothing else.

One drawback I can see: the About and Preferences dialog don't show up if there 
is no view.

Stephan



macMenuBar-3.patch
Description: Binary data

Re: bug report

[Richard Heck]

On 01/06/2014 02:37 AM, Stephan Witt wrote:

Am 05.01.2014 um 22:28 schrieb Jean-Marc Lasgouttes lasgout...@lyx.org:


Le 05/01/2014 21:35, Stephan Witt a écrit :

This looks interesting - from the Qt docs:

If you want all windows in a Mac application to share one menu bar, you must 
create a menu bar that does not have a parent.
Create a parent-less menu bar this way:
  QMenuBar *menuBar = new QMenuBar(0);
Note: Do not call QMainWindow::menuBar() to create the shared menu bar, because that 
menu bar will have theQMainWindow as its parent. That menu bar would only be 
displayed for the parent QMainWindow.

This is the relevant code from LyX:

GuiView.cpp, lines 434 and 435:

// Fill up the menu bar.
guiApp-menus().fillMenuBar(menuBar(), this, true);

So, it's done exactly the wrong way.

This is indeed quite interesting, but might be for master only for now. OTOH, 
having Reconfigure inserted only once might be good for 2.0.7. I cannot test it 
myself, unfortunately. Maybe the static array could have a bool member 
indicating whether the said entry has already been handled and in this case one 
would skip it.


I tried this already and it didn't help. It crashes nevertheless.
The QMenuBar has to be without view parent or the move to the Application menu 
shouldn't happen, IMHO.

The attached patch (for trunk) improves the situation. There are only 2 global 
QMenuBar instances on Mac then.

But there are related problems: see bug 6902 
(http://www.lyx.org/trac/ticket/6902)
IMHO, LyX isn't aware of the situation when having no view open. Is this a 
possible scenario on Linux too?

With this patch there is no crash and the Reconfigure menu is an Application 
menu item.
But the dialog actions for About and Preferences are usable only while having 
any view open.
Perhaps the LFUN code has to be moved to the GuiApplication class somehow too.

This all looks like stuff for master and too adventurous for 2.0.x indeed.

I'll try to find a less intrusive solution for branch.


OK. I will wait.

rh

Re: bug report

[Richard Heck]

On 01/06/2014 02:37 AM, Stephan Witt wrote:

Am 05.01.2014 um 22:28 schrieb Jean-Marc Lasgouttes :


Le 05/01/2014 21:35, Stephan Witt a écrit :

This looks interesting - from the Qt docs:

"If you want all windows in a Mac application to share one menu bar, you must 
create a menu bar that does not have a parent.
Create a parent-less menu bar this way:
  QMenuBar *menuBar = new QMenuBar(0);
Note: Do not call QMainWindow::menuBar() to create the shared menu bar, because that 
menu bar will have theQMainWindow as its parent. That menu bar would only be 
displayed for the parent QMainWindow."

This is the relevant code from LyX:

GuiView.cpp, lines 434 and 435:

// Fill up the menu bar.
guiApp->menus().fillMenuBar(menuBar(), this, true);

So, it's done exactly the wrong way.

This is indeed quite interesting, but might be for master only for now. OTOH, 
having Reconfigure inserted only once might be good for 2.0.7. I cannot test it 
myself, unfortunately. Maybe the static array could have a bool member 
indicating whether the said entry has already been handled and in this case one 
would skip it.


I tried this already and it didn't help. It crashes nevertheless.
The QMenuBar has to be without view parent or the move to the Application menu 
shouldn't happen, IMHO.

The attached patch (for trunk) improves the situation. There are only 2 global 
QMenuBar instances on Mac then.

But there are related problems: see bug 6902 
(http://www.lyx.org/trac/ticket/6902)
IMHO, LyX isn't aware of the situation when having no view open. Is this a 
possible scenario on Linux too?

With this patch there is no crash and the Reconfigure menu is an Application 
menu item.
But the dialog actions for About and Preferences are usable only while having 
any view open.
Perhaps the LFUN code has to be moved to the GuiApplication class somehow too.

This all looks like stuff for master and too adventurous for 2.0.x indeed.

I'll try to find a less intrusive solution for branch.


OK. I will wait.

rh

Re: bug report

[Stephan Witt]

Am 05.01.2014 um 00:18 schrieb Scott Kostyshak skost...@lyx.org:

 On Thu, Jan 2, 2014 at 10:49 AM, Stephan Witt st.w...@gmx.net wrote:
 
 There are no messages. LyX 2.0.7 is affected too on my system.
 It looks like the problem is a run-time effect and QFontMetrics::maxWidth()
 is the culprit. The attached patch helps. But I don't know if there is 
 another
 solution.
 
 Why doesn't a Git bisect help here? Was the problem triggered by an
 update of the Qt libraries?

Short answer: yes, it's triggered by an update of the Qt libraries.
The result of QFontMetrics::maxWidth() is simply 0 for the given font.

It's a multi-dimensional problem. There are
* multiple OS-versions (Mac OS 10.4 .. 10.9)
* multiple CPU-archs (i386, ppc, x86_64)
* multiple Qt-versions (4.6.x, 4.8.x, 5.x)
* multiple Qt-variants (Mac API for Carbon and Cocoa)
* multiple tool versions (automake 1.11 .. 1.14 etc.)
* multiple LyX versions (lyx-2.0.x, lyx-2.1.x)

Not all combinations work, some Qt-version is not compilable on some
OS-version or some CPU-architecture. But the biggest hurdle is the 
tool chain evolution over time. For a git bisect you need a fast machine.
The fastest machine I have uses automake 1.14 and so I cannot compile most
of the history of lyx.

In fact I'm able to compile on this machine the latest LyX versions only.
One complete build of LyX on the elder machine I have - the only device to
do a git bisect on - lasts about 10 minutes.

There are other font problems with Qt I'm unable to solve, e.g.
http://www.lyx.org/trac/ticket/7954

BTW, of course Qt has more than one font rendering engine…

It's an a little bit frustrating experience, indeed.

Stephan

Re: bug report

[Scott Kostyshak]

On Sun, Jan 5, 2014 at 6:42 AM, Stephan Witt st.w...@gmx.net wrote:
 Am 05.01.2014 um 00:18 schrieb Scott Kostyshak skost...@lyx.org:

 On Thu, Jan 2, 2014 at 10:49 AM, Stephan Witt st.w...@gmx.net wrote:

 There are no messages. LyX 2.0.7 is affected too on my system.
 It looks like the problem is a run-time effect and QFontMetrics::maxWidth()
 is the culprit. The attached patch helps. But I don't know if there is 
 another
 solution.

 Why doesn't a Git bisect help here? Was the problem triggered by an
 update of the Qt libraries?

 Short answer: yes, it's triggered by an update of the Qt libraries.
 The result of QFontMetrics::maxWidth() is simply 0 for the given font.

 It's a multi-dimensional problem. There are
 * multiple OS-versions (Mac OS 10.4 .. 10.9)
 * multiple CPU-archs (i386, ppc, x86_64)
 * multiple Qt-versions (4.6.x, 4.8.x, 5.x)
 * multiple Qt-variants (Mac API for Carbon and Cocoa)
 * multiple tool versions (automake 1.11 .. 1.14 etc.)
 * multiple LyX versions (lyx-2.0.x, lyx-2.1.x)

 Not all combinations work, some Qt-version is not compilable on some
 OS-version or some CPU-architecture. But the biggest hurdle is the
 tool chain evolution over time. For a git bisect you need a fast machine.
 The fastest machine I have uses automake 1.14 and so I cannot compile most
 of the history of lyx.

I've had this problem also.
git cherry-pick c31bf2d2
Usually fixes it cleanly for me.

 In fact I'm able to compile on this machine the latest LyX versions only.
 One complete build of LyX on the elder machine I have - the only device to
 do a git bisect on - lasts about 10 minutes.

 There are other font problems with Qt I'm unable to solve, e.g.
 http://www.lyx.org/trac/ticket/7954

Ah, the infamous omega bug!

 BTW, of course Qt has more than one font rendering engine…

 It's an a little bit frustrating experience, indeed.

I imagine so, especially since you're one of the few developers
focusing on Mac-specific issues.

Thanks for the explanation Stephan,

Scott

Re: bug report

[Richard Heck]

On 01/04/2014 04:32 PM, Stephan Witt wrote:

Am 04.01.2014 um 17:35 schrieb Richard Heck rgh...@lyx.org:


On 01/04/2014 07:14 AM, Jürgen Spitzmüller wrote:

Stephan Witt wrote:

Did you possibly try the patch on Linux?

Yes. I cannot see a problem with the patch.

Agreed. Go ahead and apply, and send me the corrected binary when it is ready. 
I'll rebuild the source packages.

Ok, I applied it.

But sorry, now I have another unrelated problem, unfortunately.
It's a really old one: when repeatedly open and close the main window
LyX crashes in Qt-menu-code. There are references to this problem here:

* http://www.lyx.org/trac/ticket/7959
* https://bugreports.qt-project.org/browse/QTBUG-25399

The attached patch addresses this issue. The culprit seems to be
the movement of the Reconfigure menu item to the Application menu.

Without it I cannot reproduce the bug anymore. But the Reconfigure
menu item is left at Tools now. This may confuse experienced LyX
on Mac users.


Well, that's better than crashing, for sure. I can put a note in the 
announcement, if that helps.


Richard

Re: bug report

[Jean-Marc Lasgouttes]

Le 04/01/2014 22:32, Stephan Witt a écrit :

But sorry, now I have another unrelated problem, unfortunately.
It's a really old one: when repeatedly open and close the main window
LyX crashes in Qt-menu-code. There are references to this problem here:

* http://www.lyx.org/trac/ticket/7959
* https://bugreports.qt-project.org/browse/QTBUG-25399

The attached patch addresses this issue. The culprit seems to be
the movement of the Reconfigure menu item to the Application menu.

Without it I cannot reproduce the bug anymore. But the Reconfigure
menu item is left at Tools now. This may confuse experienced LyX
on Mac users.


Would it be possible to have a static bool variable indicating whether 
Reconfigure has already been inserted ? In this case one would just skip it.


JMarc

Re: bug report

[Stephan Witt]

Am 05.01.2014 um 20:36 schrieb Jean-Marc Lasgouttes lasgout...@lyx.org:

 Le 04/01/2014 22:32, Stephan Witt a écrit :
 But sorry, now I have another unrelated problem, unfortunately.
 It's a really old one: when repeatedly open and close the main window
 LyX crashes in Qt-menu-code. There are references to this problem here:
 
 * http://www.lyx.org/trac/ticket/7959
 * https://bugreports.qt-project.org/browse/QTBUG-25399
 
 The attached patch addresses this issue. The culprit seems to be
 the movement of the Reconfigure menu item to the Application menu.
 
 Without it I cannot reproduce the bug anymore. But the Reconfigure
 menu item is left at Tools now. This may confuse experienced LyX
 on Mac users.
 
 Would it be possible to have a static bool variable indicating whether 
 Reconfigure has already been inserted ? In this case one would just skip it.

This looks interesting - from the Qt docs:

If you want all windows in a Mac application to share one menu bar, you must 
create a menu bar that does not have a parent.
Create a parent-less menu bar this way:
 QMenuBar *menuBar = new QMenuBar(0);
Note: Do not call QMainWindow::menuBar() to create the shared menu bar, because 
that menu bar will have theQMainWindow as its parent. That menu bar would only 
be displayed for the parent QMainWindow.

This is the relevant code from LyX:

GuiView.cpp, lines 434 and 435:

// Fill up the menu bar.
guiApp-menus().fillMenuBar(menuBar(), this, true);

So, it's done exactly the wrong way.

Stephan

Re: bug report

[Jean-Marc Lasgouttes]

Le 05/01/2014 21:35, Stephan Witt a écrit :

This looks interesting - from the Qt docs:

If you want all windows in a Mac application to share one menu bar, you must 
create a menu bar that does not have a parent.
Create a parent-less menu bar this way:
  QMenuBar *menuBar = new QMenuBar(0);
Note: Do not call QMainWindow::menuBar() to create the shared menu bar, because that 
menu bar will have theQMainWindow as its parent. That menu bar would only be 
displayed for the parent QMainWindow.

This is the relevant code from LyX:

GuiView.cpp, lines 434 and 435:

// Fill up the menu bar.
guiApp-menus().fillMenuBar(menuBar(), this, true);

So, it's done exactly the wrong way.


This is indeed quite interesting, but might be for master only for now. 
OTOH, having Reconfigure inserted only once might be good for 2.0.7. I 
cannot test it myself, unfortunately. Maybe the static array could have 
a bool member indicating whether the said entry has already been handled 
and in this case one would skip it.


JMarc

Re: bug report

[Stephan Witt]

Am 05.01.2014 um 22:28 schrieb Jean-Marc Lasgouttes lasgout...@lyx.org:

 Le 05/01/2014 21:35, Stephan Witt a écrit :
 This looks interesting - from the Qt docs:
 
 If you want all windows in a Mac application to share one menu bar, you 
 must create a menu bar that does not have a parent.
 Create a parent-less menu bar this way:
  QMenuBar *menuBar = new QMenuBar(0);
 Note: Do not call QMainWindow::menuBar() to create the shared menu bar, 
 because that menu bar will have theQMainWindow as its parent. That menu bar 
 would only be displayed for the parent QMainWindow.
 
 This is the relevant code from LyX:
 
 GuiView.cpp, lines 434 and 435:
 
  // Fill up the menu bar.
  guiApp-menus().fillMenuBar(menuBar(), this, true);
 
 So, it's done exactly the wrong way.
 
 This is indeed quite interesting, but might be for master only for now. OTOH, 
 having Reconfigure inserted only once might be good for 2.0.7. I cannot test 
 it myself, unfortunately. Maybe the static array could have a bool member 
 indicating whether the said entry has already been handled and in this case 
 one would skip it.


I tried this already and it didn't help. It crashes nevertheless. 
The QMenuBar has to be without view parent or the move to the Application menu 
shouldn't happen, IMHO.

The attached patch (for trunk) improves the situation. There are only 2 global 
QMenuBar instances on Mac then.

But there are related problems: see bug 6902 
(http://www.lyx.org/trac/ticket/6902)
IMHO, LyX isn't aware of the situation when having no view open. Is this a 
possible scenario on Linux too?

With this patch there is no crash and the Reconfigure menu is an Application 
menu item.
But the dialog actions for About and Preferences are usable only while having 
any view open.
Perhaps the LFUN code has to be moved to the GuiApplication class somehow too.

This all looks like stuff for master and too adventurous for 2.0.x indeed.

I'll try to find a less intrusive solution for branch.
 
Stephan



macMenuBar-1.patch
Description: Binary data

Re: bug report

[Stephan Witt]

Am 05.01.2014 um 00:18 schrieb Scott Kostyshak :

> On Thu, Jan 2, 2014 at 10:49 AM, Stephan Witt  wrote:
> 
>> There are no messages. LyX 2.0.7 is affected too on my system.
>> It looks like the problem is a run-time effect and QFontMetrics::maxWidth()
>> is the culprit. The attached patch helps. But I don't know if there is 
>> another
>> solution.
> 
> Why doesn't a Git bisect help here? Was the problem triggered by an
> update of the Qt libraries?

Short answer: yes, it's triggered by an update of the Qt libraries.
The result of QFontMetrics::maxWidth() is simply 0 for the given font.

It's a multi-dimensional problem. There are
* multiple OS-versions (Mac OS 10.4 .. 10.9)
* multiple CPU-archs (i386, ppc, x86_64)
* multiple Qt-versions (4.6.x, 4.8.x, 5.x)
* multiple Qt-variants (Mac API for Carbon and Cocoa)
* multiple tool versions (automake 1.11 .. 1.14 etc.)
* multiple LyX versions (lyx-2.0.x, lyx-2.1.x)

Not all combinations work, some Qt-version is not compilable on some
OS-version or some CPU-architecture. But the biggest hurdle is the 
tool chain evolution over time. For a git bisect you need a fast machine.
The fastest machine I have uses automake 1.14 and so I cannot compile most
of the "history of lyx".

In fact I'm able to compile on this machine the latest LyX versions only.
One complete build of LyX on the elder machine I have - the only device to
do a git bisect on - lasts about 10 minutes.

There are other font problems with Qt I'm unable to solve, e.g.
http://www.lyx.org/trac/ticket/7954

BTW, of course Qt has more than one font rendering engine…

It's an a little bit frustrating experience, indeed.

Stephan

Re: bug report

[Scott Kostyshak]

On Sun, Jan 5, 2014 at 6:42 AM, Stephan Witt  wrote:
> Am 05.01.2014 um 00:18 schrieb Scott Kostyshak :
>
>> On Thu, Jan 2, 2014 at 10:49 AM, Stephan Witt  wrote:
>>
>>> There are no messages. LyX 2.0.7 is affected too on my system.
>>> It looks like the problem is a run-time effect and QFontMetrics::maxWidth()
>>> is the culprit. The attached patch helps. But I don't know if there is 
>>> another
>>> solution.
>>
>> Why doesn't a Git bisect help here? Was the problem triggered by an
>> update of the Qt libraries?
>
> Short answer: yes, it's triggered by an update of the Qt libraries.
> The result of QFontMetrics::maxWidth() is simply 0 for the given font.
>
> It's a multi-dimensional problem. There are
> * multiple OS-versions (Mac OS 10.4 .. 10.9)
> * multiple CPU-archs (i386, ppc, x86_64)
> * multiple Qt-versions (4.6.x, 4.8.x, 5.x)
> * multiple Qt-variants (Mac API for Carbon and Cocoa)
> * multiple tool versions (automake 1.11 .. 1.14 etc.)
> * multiple LyX versions (lyx-2.0.x, lyx-2.1.x)
>
> Not all combinations work, some Qt-version is not compilable on some
> OS-version or some CPU-architecture. But the biggest hurdle is the
> tool chain evolution over time. For a git bisect you need a fast machine.
> The fastest machine I have uses automake 1.14 and so I cannot compile most
> of the "history of lyx".

I've had this problem also.
git cherry-pick c31bf2d2
Usually fixes it cleanly for me.

> In fact I'm able to compile on this machine the latest LyX versions only.
> One complete build of LyX on the elder machine I have - the only device to
> do a git bisect on - lasts about 10 minutes.
>
> There are other font problems with Qt I'm unable to solve, e.g.
> http://www.lyx.org/trac/ticket/7954

Ah, the infamous omega bug!

> BTW, of course Qt has more than one font rendering engine…
>
> It's an a little bit frustrating experience, indeed.

I imagine so, especially since you're one of the few developers
focusing on Mac-specific issues.

Thanks for the explanation Stephan,

Scott

Re: bug report

[Richard Heck]

On 01/04/2014 04:32 PM, Stephan Witt wrote:

Am 04.01.2014 um 17:35 schrieb Richard Heck :


On 01/04/2014 07:14 AM, Jürgen Spitzmüller wrote:

Stephan Witt wrote:

Did you possibly try the patch on Linux?

Yes. I cannot see a problem with the patch.

Agreed. Go ahead and apply, and send me the corrected binary when it is ready. 
I'll rebuild the source packages.

Ok, I applied it.

But sorry, now I have another unrelated problem, unfortunately.
It's a really old one: when repeatedly open and close the main window
LyX crashes in Qt-menu-code. There are references to this problem here:

* http://www.lyx.org/trac/ticket/7959
* https://bugreports.qt-project.org/browse/QTBUG-25399

The attached patch addresses this issue. The culprit seems to be
the movement of the Reconfigure menu item to the Application menu.

Without it I cannot reproduce the bug anymore. But the Reconfigure
menu item is left at Tools now. This may confuse experienced LyX
on Mac users.


Well, that's better than crashing, for sure. I can put a note in the 
announcement, if that helps.


Richard

Re: bug report

[Jean-Marc Lasgouttes]

Le 04/01/2014 22:32, Stephan Witt a écrit :

But sorry, now I have another unrelated problem, unfortunately.
It's a really old one: when repeatedly open and close the main window
LyX crashes in Qt-menu-code. There are references to this problem here:

* http://www.lyx.org/trac/ticket/7959
* https://bugreports.qt-project.org/browse/QTBUG-25399

The attached patch addresses this issue. The culprit seems to be
the movement of the Reconfigure menu item to the Application menu.

Without it I cannot reproduce the bug anymore. But the Reconfigure
menu item is left at Tools now. This may confuse experienced LyX
on Mac users.


Would it be possible to have a static bool variable indicating whether 
Reconfigure has already been inserted ? In this case one would just skip it.


JMarc

Re: bug report

[Stephan Witt]

Am 05.01.2014 um 20:36 schrieb Jean-Marc Lasgouttes :

> Le 04/01/2014 22:32, Stephan Witt a écrit :
>> But sorry, now I have another unrelated problem, unfortunately.
>> It's a really old one: when repeatedly open and close the main window
>> LyX crashes in Qt-menu-code. There are references to this problem here:
>> 
>> * http://www.lyx.org/trac/ticket/7959
>> * https://bugreports.qt-project.org/browse/QTBUG-25399
>> 
>> The attached patch addresses this issue. The culprit seems to be
>> the movement of the Reconfigure menu item to the Application menu.
>> 
>> Without it I cannot reproduce the bug anymore. But the Reconfigure
>> menu item is left at Tools now. This may confuse experienced LyX
>> on Mac users.
> 
> Would it be possible to have a static bool variable indicating whether 
> Reconfigure has already been inserted ? In this case one would just skip it.

This looks interesting - from the Qt docs:

"If you want all windows in a Mac application to share one menu bar, you must 
create a menu bar that does not have a parent.
Create a parent-less menu bar this way:
 QMenuBar *menuBar = new QMenuBar(0);
Note: Do not call QMainWindow::menuBar() to create the shared menu bar, because 
that menu bar will have theQMainWindow as its parent. That menu bar would only 
be displayed for the parent QMainWindow."

This is the relevant code from LyX:

GuiView.cpp, lines 434 and 435:

// Fill up the menu bar.
guiApp->menus().fillMenuBar(menuBar(), this, true);

So, it's done exactly the wrong way.

Stephan

Re: bug report

[Jean-Marc Lasgouttes]

Le 05/01/2014 21:35, Stephan Witt a écrit :

This looks interesting - from the Qt docs:

"If you want all windows in a Mac application to share one menu bar, you must 
create a menu bar that does not have a parent.
Create a parent-less menu bar this way:
  QMenuBar *menuBar = new QMenuBar(0);
Note: Do not call QMainWindow::menuBar() to create the shared menu bar, because that 
menu bar will have theQMainWindow as its parent. That menu bar would only be 
displayed for the parent QMainWindow."

This is the relevant code from LyX:

GuiView.cpp, lines 434 and 435:

// Fill up the menu bar.
guiApp->menus().fillMenuBar(menuBar(), this, true);

So, it's done exactly the wrong way.


This is indeed quite interesting, but might be for master only for now. 
OTOH, having Reconfigure inserted only once might be good for 2.0.7. I 
cannot test it myself, unfortunately. Maybe the static array could have 
a bool member indicating whether the said entry has already been handled 
and in this case one would skip it.


JMarc

Re: bug report

[Stephan Witt]

Am 05.01.2014 um 22:28 schrieb Jean-Marc Lasgouttes :

> Le 05/01/2014 21:35, Stephan Witt a écrit :
>> This looks interesting - from the Qt docs:
>> 
>> "If you want all windows in a Mac application to share one menu bar, you 
>> must create a menu bar that does not have a parent.
>> Create a parent-less menu bar this way:
>>  QMenuBar *menuBar = new QMenuBar(0);
>> Note: Do not call QMainWindow::menuBar() to create the shared menu bar, 
>> because that menu bar will have theQMainWindow as its parent. That menu bar 
>> would only be displayed for the parent QMainWindow."
>> 
>> This is the relevant code from LyX:
>> 
>> GuiView.cpp, lines 434 and 435:
>> 
>>  // Fill up the menu bar.
>>  guiApp->menus().fillMenuBar(menuBar(), this, true);
>> 
>> So, it's done exactly the wrong way.
> 
> This is indeed quite interesting, but might be for master only for now. OTOH, 
> having Reconfigure inserted only once might be good for 2.0.7. I cannot test 
> it myself, unfortunately. Maybe the static array could have a bool member 
> indicating whether the said entry has already been handled and in this case 
> one would skip it.


I tried this already and it didn't help. It crashes nevertheless. 
The QMenuBar has to be without view parent or the move to the Application menu 
shouldn't happen, IMHO.

The attached patch (for trunk) improves the situation. There are only 2 global 
QMenuBar instances on Mac then.

But there are related problems: see bug 6902 
(http://www.lyx.org/trac/ticket/6902)
IMHO, LyX isn't aware of the situation when having no view open. Is this a 
possible scenario on Linux too?

With this patch there is no crash and the Reconfigure menu is an Application 
menu item.
But the dialog actions for About and Preferences are usable only while having 
any view open.
Perhaps the LFUN code has to be moved to the GuiApplication class somehow too.

This all looks like stuff for master and too adventurous for 2.0.x indeed.

I'll try to find a less intrusive solution for branch.
 
Stephan



macMenuBar-1.patch
Description: Binary data

Re: bug report

[Stephan Witt]

Am 03.01.2014 um 17:14 schrieb Jürgen Spitzmüller sp...@lyx.org:

 Richard Heck wrote:
 I guess we'd better hold 2.0.7 until this is fixed
 
 Stephan's workaround seems to be just fine for that purpose. At least it 
 looks 
 innocent enough.

I didn't find another solution until now. QFontMetricsF is not helpful, too.
Did you possibly try the patch on Linux? 

The worst thing I can foresee is a resulting grid with quadrate dimensions 
instead of rectangular ones.

I'd like to apply it with an additional FIXME. Ok?

Stephan

Re: bug report

[Jürgen Spitzmüller]

Stephan Witt wrote:
 Did you possibly try the patch on Linux? 

Yes. I cannot see a problem with the patch.

Regards,
Jürgen

Re: bug report

[Richard Heck]

On 01/04/2014 07:14 AM, Jürgen Spitzmüller wrote:

Stephan Witt wrote:

Did you possibly try the patch on Linux?

Yes. I cannot see a problem with the patch.


Agreed. Go ahead and apply, and send me the corrected binary when it is 
ready. I'll rebuild the source packages.


rh

Re: bug report

[Stephan Witt]

Am 04.01.2014 um 17:35 schrieb Richard Heck rgh...@lyx.org:

 On 01/04/2014 07:14 AM, Jürgen Spitzmüller wrote:
 Stephan Witt wrote:
 Did you possibly try the patch on Linux?
 Yes. I cannot see a problem with the patch.
 
 Agreed. Go ahead and apply, and send me the corrected binary when it is 
 ready. I'll rebuild the source packages.

Ok, I applied it. 

But sorry, now I have another unrelated problem, unfortunately.
It's a really old one: when repeatedly open and close the main window
LyX crashes in Qt-menu-code. There are references to this problem here:

* http://www.lyx.org/trac/ticket/7959
* https://bugreports.qt-project.org/browse/QTBUG-25399

The attached patch addresses this issue. The culprit seems to be
the movement of the Reconfigure menu item to the Application menu.

Without it I cannot reproduce the bug anymore. But the Reconfigure
menu item is left at Tools now. This may confuse experienced LyX 
on Mac users.

Stephan


mac_special_menu.patch
Description: Binary data

Re: bug report

[Scott Kostyshak]

On Thu, Jan 2, 2014 at 10:49 AM, Stephan Witt st.w...@gmx.net wrote:

 There are no messages. LyX 2.0.7 is affected too on my system.
 It looks like the problem is a run-time effect and QFontMetrics::maxWidth()
 is the culprit. The attached patch helps. But I don't know if there is another
 solution.

Why doesn't a Git bisect help here? Was the problem triggered by an
update of the Qt libraries?

Scott

Re: bug report

[Stephan Witt]

Am 03.01.2014 um 17:14 schrieb Jürgen Spitzmüller :

> Richard Heck wrote:
>> I guess we'd better hold 2.0.7 until this is fixed
> 
> Stephan's workaround seems to be just fine for that purpose. At least it 
> looks 
> innocent enough.

I didn't find another solution until now. QFontMetricsF is not helpful, too.
Did you possibly try the patch on Linux? 

The worst thing I can foresee is a resulting grid with quadrate dimensions 
instead of rectangular ones.

I'd like to apply it with an additional FIXME. Ok?

Stephan

Re: bug report

[Jürgen Spitzmüller]

Stephan Witt wrote:
> Did you possibly try the patch on Linux? 

Yes. I cannot see a problem with the patch.

Regards,
Jürgen