Citation with multiple keys is always labeled as broken

[Patrick De Visschere]

Since commit 4ddc9e… (master, 14 march 2020) citations with multiple keys are 
always labeled as broken, because the key list is handled as a single key.
Included is a possible fix.

Patrick



citationspatch.diff
Description: Binary data


smime.p7s
Description: S/MIME cryptographic signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Blanket permission

[Patrick De Visschere]

Kornel,

I hereby grant permission to use my work for LyX under the license GPL version 
2 or later.

Patrick De Visschere



smime.p7s
Description: S/MIME cryptographic signature
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LinkBack support (on MacOS)

[Patrick De Visschere]

> On 12 Sep 2019, at 18:23, Stephan Witt  wrote:
> 
> Am 08.09.2019 um 10:57 schrieb Stephan Witt :
>> 
>> Am 25.09.2018 um 17:21 schrieb Stephan Witt :
>>> 
>>> Am 25.09.2018 um 17:10 schrieb Jürgen Spitzmüller :
 
 Am Freitag, den 21.09.2018, 15:55 +0200 schrieb pdv:
> I came across a deprecated call in the LinkBack code, and discovered 
> that LinkBack acctually doesn't work (anymore).
> Apparently nobody uses this?
 
 Apparently. I only found this 8 year old bug related to LinkBack:
 https://www.lyx.org/trac/ticket/6961
 
 
> When the pasteboard contains linkback-data lyx saves the pdf-data + 
> linkback-data in a file with the .linkback extension and adds the
> size 
> of the pdf-data as a uint32.
> 
> When reading/rewriting back the size it's converted with 
> NSSwapBigLongToHost() and NSSwapHostLongToBig() calls.
> 
> I suppose that the "Long" refers to 8 bytes.
> 
> Replacing the calls by the similar "Int" calls solves the problem.
> 
> LinkBack then works with LateXiT and with Omnigraffle.
> 
> Enclosed is a patch for this and for replacing the deprecated call.
 
 Alas, I know nothing of this. Stephan?
>>> 
>>> I’ll see if I can find the time.
>> 
>> I’ve applied the patch and have no problem. I didn’t do the real test with 
>> linkback-data.
>> I don’t have Omnigraffle an my system.
>> 
>> The change from NSSwapBigLongToHost to NSSwapBigIntToHost is 100% correct.
>> I’ll commit to master. Thank you Patrick for fixing this bug.
> 
> I’ve commit it to master.
> 
> Patrick, can we close the ticket in LyX’s bug tracker?
> 
> Riki, I think we should back port the change to stable. Ok?
> 
> Stephan


I’ve checked linkback support with latexit and it works now, so you can close 
it.

Patrick



smime.p7s
Description: S/MIME cryptographic signature

Re: linking error due to missing boost::assertion_failed_msg()

[Patrick De Visschere]

> On 9 Sep 2019, at 00:41, Stephan Witt  wrote:
> 
> Am 08.09.2019 um 22:44 schrieb Patrick De Visschere :
>> 
>> 
>> 
>>> On 8 Sep 2019, at 21:03, Stephan Witt  wrote:
>>> 
>>> Am 08.09.2019 um 20:47 schrieb pdv :
>>>> 
>>>> On 08/09/2019 17:47, Kornel Benko wrote:
>>>>> Am Sonntag, 8. September 2019, 14:14:15 CEST schrieb Patrick De Visschere:
>>>>>> In the source files (ConverterCache.cpp, Application.cpp, FileName.cpp 
>>>>>> and GuiClipboard.cpp) I don’t see macro’s which could optionally include 
>>>>>> the relevant code which is probably in the boost::crc module. I suppose 
>>>>>> boost::crc uses boost::array where the BOOST_ASSERT_MSG macro is 
>>>>>> activated, triggering the error.
>>>>>> 
>>>>>> LyX includes a 3thparty boost-version (1.68), but I don’t find any 
>>>>>> references to it in my XCode project and I think I’m actually using my 
>>>>>> macports boost (which is 1.71).
>>>>>> This might explain it: I’ve upgraded my macports boost and this breaks 
>>>>>> my lyx-build.
>>>>>> 
>>>>>> 
>>>>> There isn't any, if you don't use GCC. See CMakeLists.txt:162
>>>>>   Kornel
>>>> 
>>>> XCode uses clang and I believe that indeed the internal (3thparty) boost 
>>>> is used. But this contains only the regex (and signals) source code, 
>>>> besides (all) the headers. The code involved #includes  and 
>>>> I suppose this code is found in the system (macports) boost.
>>> 
>>> I have it in lyx/3rdparty/boost/boost/crc.hpp …
>>> 
>>> Stephan
>> 
>> Me too. But XCode picks up the one in macports.
>> 
>> And  there is no source code (crc.cpp) or no lib to link with.
> 
> I’m using a build script for cmake Xcode project generation. It contains:
> 
> XCODE_SDK_PATH=${SDKROOT:-$(xcrun --show-sdk-path)}
> echo Using SDK ${XCODE_SDK_PATH}
> cmake … \
> -DCMAKE_SYSTEM_PREFIX_PATH="/usr;${XCODE_SDK_PATH}/usr“
> … 
> 
> Does it do the trick for you?
> 
> Stephan

No :(

I’ve noticed that the XCode compile command contains the "-I/opt/local/include" 
directive; because the “Header Search Paths” is set that way in the project; 
This is inserted by cmake because I use macports aspell and magic.

Patrick




smime.p7s
Description: S/MIME cryptographic signature

Re: linking error due to missing boost::assertion_failed_msg()

[Patrick De Visschere]

> On 8 Sep 2019, at 21:03, Stephan Witt  wrote:
> 
> Am 08.09.2019 um 20:47 schrieb pdv :
>> 
>> On 08/09/2019 17:47, Kornel Benko wrote:
>>> Am Sonntag, 8. September 2019, 14:14:15 CEST schrieb Patrick De Visschere:
>>>> In the source files (ConverterCache.cpp, Application.cpp, FileName.cpp and 
>>>> GuiClipboard.cpp) I don’t see macro’s which could optionally include the 
>>>> relevant code which is probably in the boost::crc module. I suppose 
>>>> boost::crc uses boost::array where the BOOST_ASSERT_MSG macro is 
>>>> activated, triggering the error.
>>>> 
>>>> LyX includes a 3thparty boost-version (1.68), but I don’t find any 
>>>> references to it in my XCode project and I think I’m actually using my 
>>>> macports boost (which is 1.71).
>>>> This might explain it: I’ve upgraded my macports boost and this breaks my 
>>>> lyx-build.
>>>> 
>>>> 
>>> There isn't any, if you don't use GCC. See CMakeLists.txt:162
>>> Kornel
>> 
>> XCode uses clang and I believe that indeed the internal (3thparty) boost is 
>> used. But this contains only the regex (and signals) source code, besides 
>> (all) the headers. The code involved #includes  and I suppose 
>> this code is found in the system (macports) boost.
> 
> I have it in lyx/3rdparty/boost/boost/crc.hpp …
> 
> Stephan

Me too. But XCode picks up the one in macports.

And  there is no source code (crc.cpp) or no lib to link with.

Patrick



smime.p7s
Description: S/MIME cryptographic signature

Re: linking error due to missing boost::assertion_failed_msg()

[Patrick De Visschere]

Yes, I have a few different settings (but I didn’t change them recently as far 
as I know) and I’m using (gui) CMake 3.15.1
and XCode = Version 10.3 (10G8)

LYX_CPACK = ON : Use the CPack management (Implies LYX_INSTALL option)
LYX_LOCALVERSIONING = OFF : Add version info to created package name (only used 
if LYX_CPACK option set)
LYX_INSTALL = ON : Build install projects/rules (implies a bunch of other 
options)
LYX_NLS = ON : Enable Native Language Support (NLS)
LYX_REQUIRE_SPELLCHECK = OFF : Abort if no spellchecker available
LYX_ASPELL = ON : Require aspell
LYX_ENCHANT = OFF : Require Enchant
LYX_HUNSPELL = ON : Require Hunspell
LYX_RELEASE = OFF : Build release version, build debug when disabled
LYX_DEBUG = OFF : Enforce debug build
LYX_NO_OPTIMIZE = ON : Don't use any optimization/debug flags
LYX_PACKAGE_SUFFIX = ON : Use version suffix for packaging
LYX_SUFFIX_VALUE = : Use this string as suffix
LYX_PCH = OFF : Use precompiled headers
LYX_MERGE_FILES = OFF : Merge source files into one compilation unit
LYX_MERGE_REBUILD = OFF : Rebuild generated files from merged files build
LYX_QUIET = ON : Don't generate verbose makefiles
LYX_INSTALL_PREFIX = OFF : Install path for LyX
LYX_BUNDLE = ON : Build bundle (experimental)
LYX_ENABLE_URLTESTS = OFF : Enable for URL tests
LYX_ENABLE_EXPORT_TESTS = OFF : Enable for export tests
LYX_ENABLE_KEYTESTS = OFF : Enable for keytests
LYX_ASAN = OFF : Use address sanitizer
LYX_USE_FILEDIALOG = QT : Use native or QT file dialog (QT NATIVE)
LYX_USE_QT = QT5 : Use Qt version as frontend (AUTO QT4 QT5)
LYX_DISABLE_CALLSTACK_PRINTING = OFF : do not print a callstack when crashing
LYX_EXTERNAL_Z = ON : OFF := Build 3rdparty lib zlib
LYX_EXTERNAL_ICONV = ON : OFF := Build 3rdparty lib iconvlib
LYX_EXTERNAL_HUNSPELL = OFF : OFF := Build 3rdparty lib hunspelllib
LYX_EXTERNAL_MYTHES = OFF : OFF := Build 3rdparty lib mytheslib (AUTO OFF ON)
LYX_DMG = ON : Build as Mac bundle, needed for .dmg (experimental)
LYX_COCOA = ON : Use Cocoa on Mac

In the source files (ConverterCache.cpp, Application.cpp, FileName.cpp and 
GuiClipboard.cpp) I don’t see macro’s which could optionally include the 
relevant code which is probably in the boost::crc module. I suppose boost::crc 
uses boost::array where the BOOST_ASSERT_MSG macro is activated, triggering the 
error.

LyX includes a 3thparty boost-version (1.68), but I don’t find any references 
to it in my XCode project and I think I’m actually using my macports boost 
(which is 1.71).
This might explain it: I’ve upgraded my macports boost and this breaks my 
lyx-build.



> On 8 Sep 2019, at 10:14, Stephan Witt  wrote:
> 
> Am 08.09.2019 um 10:02 schrieb Patrick De Visschere :
>> 
>> Sorry, mistyped the last “f”: it should have been 01ee3bf1e5, the master 
>> branch on 5 sept.
> 
> I see. Yes, this is HEAD for me too. This is what works for me.
> 
> Perhaps you have different cmake flags?
> 
> I have:
> -- LYX_CPACK  = OFF   : Use the CPack management 
> (Implies LYX_INSTALL option)
> -- LYX_LOCALVERSIONING= ON: Add version info to created 
> package name (only used if LYX_CPACK option set)
> -- LYX_INSTALL= OFF   : Build install projects/rules 
> (implies a bunch of other options)
> -- LYX_NLS= ON: Enable Native Language 
> Support (NLS)
> -- LYX_REQUIRE_SPELLCHECK = OFF   : Abort if no spellchecker 
> available
> -- LYX_ASPELL = ON: Require aspell
> -- LYX_ENCHANT= OFF   : Require Enchant
> -- LYX_HUNSPELL   = ON: Require Hunspell
> -- LYX_RELEASE= OFF   : Build release version, build 
> debug when disabled
> -- LYX_DEBUG  = ON: Enforce debug build
> -- LYX_NO_OPTIMIZE= OFF   : Don't use any 
> optimization/debug flags
> -- LYX_PACKAGE_SUFFIX = OFF   : Use version suffix for 
> packaging
> -- LYX_SUFFIX_VALUE   =   : Use this string as suffix
> -- LYX_PCH= OFF   : Use precompiled headers
> -- LYX_MERGE_FILES= OFF   : Merge source files into one 
> compilation unit
> -- LYX_MERGE_REBUILD  = OFF   : Rebuild generated files from 
> merged files build
> -- LYX_QUIET  = OFF   : Don't generate verbose 
> makefiles
> -- LYX_INSTALL_PREFIX = OFF   : Install path for LyX
> -- LYX_BUNDLE = OFF   : Build bundle  (experimental) 
> -- LYX_ENABLE_URLTESTS= OFF   : Enable for URL tests
> -- LYX_ENABLE_EXPORT_TESTS= ON: Enable for export tests
> -- LYX_ENABLE_KEYTESTS= OFF   : Enable for keytests
> -- LYX_ASAN 

Re: linking error due to missing boost::assertion_failed_msg()

[Patrick De Visschere]

Sorry, mistyped the last “f”: it should have been 01ee3bf1e5, the master branch 
on 5 sept.

> On 8 Sep 2019, at 09:34, Stephan Witt  wrote:
> 
> Am 07.09.2019 um 10:14 schrieb pdv :
>> 
>> LyX fails to build on macos (Mojave, CMake, XCode) with the latest commit 
>> (01ee3bf1f5) with message:
>> 
>> Undefined symbols for architecture x86_64:
>> "boost::assertion_failed_msg(char const*, char const*, char const*, char 
>> const*, long)", referenced from:
>> boost::array::operator[](unsigned long) in 
>> ConverterCache.o
>> boost::array::operator[](unsigned long) in 
>> libfrontend_qt.a(GuiApplication.o)
>> boost::array::operator[](unsigned long) in 
>> libsupport.a(FileName.o)
>> boost::array::operator[](unsigned long) in 
>> libfrontend_qt.a(GuiClipboard.o)
>> 
>> From the boost docs 
>> (https://www.boost.org/doc/libs/1_68_0/libs/assert/doc/html/assert.html) 
>> it's clear that boost::assertion_failed_msg() must be defined, ...
>> 
>> If the macro BOOST_ENABLE_ASSERT_HANDLER is defined when  
>> is included, BOOST_ASSERT_MSG(expr,msg) expands to
>> 
>> (BOOST_LIKELY(!!(expr))? ((void)0): ::boost::assertion_failed_msg(#expr,
>>   msg, BOOST_CURRENT_FUNCTION, __FILE__, __LINE__))
>> This is true regardless of whether NDEBUG is defined.
>> 
>> boost::assertion_failed_msg is declared in  as
>> 
>> namespace boost
>> {
>>   void assertion_failed_msg(char const * expr, char const * msg,
>>   char const * function, char const * file, long line);
>> }
>> but it is never defined. The user is expected to supply an appropriate 
>> definition.
>> 
>> ... which is not the case now, and BOOST_ASSERT_MSG is defined in 
>> boost::array.hpp.
>> 
>> I've defined the additional function assertion_failed_msg()in boost.cpp 
>> (patch attached) and this resolves the problem.
>> 
>> Two more remarks:
>> 
>> 1) I don't understand why this problem surfaces now and not earlier;
>> 
>> 2) There are additional definitions of assertion_failed() in 
>> client/boost.cpp and in tex2lyx/boost.cpp;
> 
> I cannot find the commit 01ee3bf1f5. Is it a local one in your git checkout?
> 
> I don’t have this problem with neither with automake nor with cmake.
> 
> Stephan


Patrick De Visschere
051/46 70 25
Pensionaatstraat 25 
8755 Ruiselede







smime.p7s
Description: S/MIME cryptographic signature

Re: Document Settings dialog partially broken on macos

[Patrick De Visschere]

With “not highlighted” I meant that they are greyed out.
When e.g. I select “Vertical space” in “Text Layout” instead of the default 
“Indentation” the OK, Apply and Reset buttons remain greyed out.
Apparently the problem is that the screen is not updated immediately: when I 
subsequently resize the window (or switch to another app), then the display is 
shown properly.

Since you have no problem with Qt-5.9, I then checked with Qt-5.10.1 and there 
is no problem with that.

So, it seems a problem which occurs with Qt-5.11 only.


> On 4 Oct 2018, at 19:17, Stephan Witt  wrote:
> 
> Am 04.10.2018 um 14:36 schrieb pdv :
>> 
>> Jean-Marc,
>> 
>> I noticed that the Document Settings dialog is partially broken in macos 
>> (build with Qt-5.11.2).
>> 
>> When making a change to the settings (with the default document class) the 
>> buttons (OK, apply, reset) are not highlighted. They seem still active 
>> though, so you can click on them.
>> When choosing another document class they become highlighted.
>> 
>> The problem is absent in commit azf... (8/7/2018) and present in commit 
>> b21... (10/7/2018) and I suppose it's related to the changes in 
>> QDialogButtonBox.
> 
> If I run current master (as of change 7cb0284a3f) on Mac build with Qt 5.9.4 
> I cannot see what you describe. With highlighted you mean enabled? The 
> buttons get enabled on changing something to the settings.
> 
> Stephan

commit ca4426e broke macos-build

[Patrick De Visschere]

Commit ca4426e (bugfix #10888) broke (at least my) macos-build (qt5.10 and 
macos 10.12);
A change from menu to menuptr in Menus.cpp escaped attention.

patch included.

pdv



menutomenuptr.diff
Description: Binary data

Re: LyX-Workarea: Background not shown correctly

[Patrick De Visschere]

> 
> Can you try to set/unset documentMode in DragTabBar::DragTabBar and see what 
> it does?
> 
> JMarc

I’ve inserted setDocumentMode(true/false); and it doesn’t make any difference.

I’ve then set breakpoints in :

QCocoaNativeInterface::setContentBorderEnabled(QWindow *window, bool enable)
and QMainWindow::setUnifiedTitleAndToolBarOnMac(bool set)

but these are never triggered ...

… because the format() you’ve been following is not from QCocoaBackingStore, 
but from QRasterBackingStore, as shown in this stack ...



… and that’s because the code for the QCocoaBackingStore::format() has changed 
between Qt-5.9 and Qt-5.10;
This is the code for Qt-5.10:

QImage::Format QCocoaBackingStore::format() const
{
if (windowHasUnifiedToolbar())
return QImage::Format_ARGB32_Premultiplied;

return QRasterBackingStore::format();
}

===
The top routine in the stack QSurfaceFormat::hasAlpha() returns:

return d->alphaBufferSize > 0; (with alphaBufferSize=8)

The latter is set in :

QSurfaceFormat QCocoaWindow::format() const
{
QSurfaceFormat format = window()->requestedFormat();

// Upgrade the default surface format to include an alpha channel. The 
default RGB format
// causes Cocoa to spend an unreasonable amount of time converting it to 
RGBA internally.
if (format == QSurfaceFormat())
format.setAlphaBufferSize(8);
return format;
}

===

Re: LyX-Workarea: Background not shown correctly

[Patrick De Visschere]

> On 25 Oct 2017, at 12:21, Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote:
> 
> Le 23/10/2017 à 23:34, Patrick De Visschere a écrit :
>> With the patch in place, SingleParUpdate in bufferView::draw is never 
>> reached.
> 
> So finally you mean that an UpdateRequest is really fired for each update 
> event (which makes sense :), right?

The patch turns every update into a FullScreenUpdate and SingleParUpdate is 
then obsolete.
Every call to viewport()->update() leads to a QEvent::updateRequest I guess.

> 
>>> It would be interesting to set a break on QWindow::requestUpdate and see 
>>> whether to is something we do that triggers this effect.
>> I did and it’s never triggered.
> 
> OK.

btw this was about the function requestUpdate(), not the QEvent.

> 
>>>> If I pass the coordinates of the paragraph, I notice that
>>>> “SingleParUpdate" actually means “SingleRowUpdate". Since only the
>>>> current paragraph is painted black now, except for the current row.
> 
> What happens is that the painting code (in TextMetrics::drawParagraph) only 
> paints the rows of the paragraph that have changed. This is why you see that 
> only the row cursor is repainted. If you do a change that changes the cursor 
> row and the next one (by inserting a character), you should see several rows 
> repainted.

Yes I found the crcCheck on a row.
But when forcing a FullScreenUpdate this code becomes useless, since with 
pi.full_repaint=true every line is redrawn.

> 
> I do not like much the idea of just restricting the update area, since it 
> seems very fragile. But we can return to it if needed. There are ways to get 
> all the coordinates that we need.

I agree. The dimensions passed via update(x,y,w,h) and the actual area painted 
must match exactly. I cannot judge the penalty of the screen redraws. I doesn’t 
seem to hurt very much.
Nevertheless I have now something which works mostly. There are still problems 
when dragging a selection but I believe these can be solved by fine tuning. The 
other problem is that when opening a document the screen stil turns black.

> 
> There is a point that I would like to clear though: is the screen turned to 
> black at each event (insertion of a character...), or only when certain 
> things happen, like the example of doing a PDF preview like Stephan described 
> at the beginning of this thread?

When typing, the whole screen stays black, except for the current line, which 
looks normal. You don’t have to do anything special to get this.
That’s what I expect: when typing a single character in a row, only that row 
will be repainted but the update() triggers a full screen erase.

With a big document it’s sufficient to scroll a little bit to trigger a 
FullScreenUpdate. So maybe when not typing and moving the mouse around it might 
not always be obvious.
And within a table there is no problem, meaning that the cells do not turn 
black. Moving the mouse over a table seems to trigger a FullScreenUpdate.

> 
>> I’m still having problems with the basics. I thought there existed a 
>> document describing the basics of textMetrics, paragraphMetrics … .
>> I found something on the wiki but not so much.
> 
> Did you take a look at development/PAINTING_ANALYSIS? I try to maintain it 
> while doing changes, but it is incomplete, and probably wrong in some places.

Yes I found that and it helped.

> 
> JMarc




smime.p7s
Description: S/MIME cryptographic signature

Re: LyX-Workarea: Background not shown correctly

[Patrick De Visschere]

> On 25 Oct 2017, at 16:28, Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote:
> 
> Le 25/10/2017 à 16:15, Patrick De Visschere a écrit :
>>> So finally you mean that an UpdateRequest is really fired for each update 
>>> event (which makes sense :), right?
>> The patch turns every update into a FullScreenUpdate and SingleParUpdate is 
>> then obsolete.
>> Every call to viewport()->update() leads to a QEvent::updateRequest I guess.
> 
> Yes, I meant without the patch that does a full repaint on each full paint 
> event.
> 
>> btw this was about the function requestUpdate(), not the QEvent.
> 
> I suspect they are the same, but the Qt source is really too big for me. I 
> tried to understand what happens, but it is hard to grasp.
> 
>> Yes I found the crcCheck on a row.
>> But when forcing a FullScreenUpdate this code becomes useless, since with 
>> pi.full_repaint=true every line is redrawn.
> 
> Of course, if we force, we force.
> 
>>> I do not like much the idea of just restricting the update area, since it 
>>> seems very fragile. But we can return to it if needed. There are ways to 
>>> get all the coordinates that we need.
>> I agree. The dimensions passed via update(x,y,w,h) and the actual area 
>> painted must match exactly. I cannot judge the penalty of the screen 
>> redraws. I doesn’t seem to hurt very much.
>> Nevertheless I have now something which works mostly. There are still 
>> problems when dragging a selection but I believe these can be solved by fine 
>> tuning. The other problem is that when opening a document the screen stil 
>> turns black.
> 
> And the other problem is that we do a lot of useless painting (that is 
> ignored by the clipping but probably still costs us).
> 
>>> There is a point that I would like to clear though: is the screen turned to 
>>> black at each event (insertion of a character...), or only when certain 
>>> things happen, like the example of doing a PDF preview like Stephan 
>>> described at the beginning of this thread?
>> When typing, the whole screen stays black, except for the current line, 
>> which looks normal. You don’t have to do anything special to get this.
>> That’s what I expect: when typing a single character in a row, only that row 
>> will be repainted but the update() triggers a full screen erase.
>> With a big document it’s sufficient to scroll a little bit to trigger a 
>> FullScreenUpdate. So maybe when not typing and moving the mouse around it 
>> might not always be obvious.
>> And within a table there is no problem, meaning that the cells do not turn 
>> black. Moving the mouse over a table seems to trigger a FullScreenUpdate.
> 
> OK, assume that you managed to get afull repaint (with some scrolling for 
> example). Now, if you type a character, does it turn the whole work area to 
> black?
> 

Yes (except for some insets, as always) and when in a table the whole table 
remains normal.

> JMarc




smime.p7s
Description: S/MIME cryptographic signature

Re: LyX-Workarea: Background not shown correctly

[Patrick De Visschere]

> On 22 Oct 2017, at 23:11, Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote:
> 
> Le 21 octobre 2017 14:56:36 GMT+02:00, Patrick De Visschere 
> <pdvissch...@edpnet.be> a écrit :
>> Jean-Marc,
>> 
>> This works because every update is turned into a FullScreenUpdate.
>> Right?
> 
> If I understand correctly, it turns every update related to an UpdateRequest 
> event (something internal to qt) into a full screen update (in the LyX 
> sense). But I think that these updates (those which create the black screen) 
> are not the norm.
> You can check that by adding some debug information along with the new code 
> in my patch to see how often it triggers.

With the patch in place, SingleParUpdate in bufferView::draw is never reached.

> 
> It would be interesting to set a break on QWindow::requestUpdate and see 
> whether to is something we do that triggers this effect.

I did and it’s never triggered.

>> Isn’t this a waste of work?
>> 
>> Do you consider this as a permanent solution?
> 
> Yes maybe, along with other improvement on our draw code. But I might not 
> understand exactly what is happening.
> 
>> I’ve tried to solve the problem by using: viewport()->update(0,y,w,h)
>> and thus specifying the proper coordinates.
> 
> Which one?

The following gives me the correct coordinates for a simple paragraph (for 
tables using top_pit looks better).

void BufferView::rectToUpdate(int *y, int *w, int *h)
{
if(d->update_strategy_ == SingleParUpdate) {
Text & buftext = buffer_.text();
pit_type const bottom_pit = d->cursor_.bottom().pit();
TextMetrics & tm = textMetrics();
*h = tm.parMetrics(bottom_pit).height();
*y = tm.parMetrics(bottom_pit).position() - 
tm.parMetrics(bottom_pit).ascent();
} else {
*y = 0;
*h = height_;
}
*w = width_;
}


> 
>> If I pass the coordinates of the paragraph, I notice that
>> “SingleParUpdate" actually means “SingleRowUpdate". Since only the
>> current paragraph is painted black now, except for the current row.
> 
> Interesting. Does this mean that we could somehow disable completely these 
> black screen paintings ?

Actually I need the coordinates of the current Row instead of those of the 
Paragraph, but sofar I couldn’t find this information. I’m afraid that the 
currrent Row of a paragraph is not cached somewhere.
And this does not work yet when making a selection or moving the cursor around.

It will only work if for every update we can pass via viewport()->update(x, y, 
w,h) the exact area to be painted later. If it’s too large it will be partially 
black and if too small updates will be missed.

> 
> The whole situation is not clear to me as you can see.

I’m still having problems with the basics. I thought there existed a document 
describing the basics of textMetrics, paragraphMetrics … .
I found something on the wiki but not so much.

> 
> JMarc
> 




smime.p7s
Description: S/MIME cryptographic signature

Re: LyX-Workarea: Background not shown correctly

[Patrick De Visschere]

Jean-Marc,

This works because every update is turned into a FullScreenUpdate. Right?

Isn’t this a waste of work?

Do you consider this as a permanent solution?

I’ve tried to solve the problem by using: viewport()->update(0,y,w,h) and thus 
specifying the proper coordinates.
If I pass the coordinates of the paragraph, I notice that “SingleParUpdate" 
actually means “SingleRowUpdate". Since only the current paragraph is painted 
black now, except for the current row. There is also still a problem when 
making a selection and when moving the cursor around.
Therefore I should pass the coordinates of the current row instead, to begin 
with. The selection/cursor problems might be more difficult to solve.

What’s your opinion on this?

pdv 


> On 19 Oct 2017, at 23:24, Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote:
> 
> Le 19 octobre 2017 22:34:07 GMT+02:00, Patrick De Visschere 
> <pdvissch...@edpnet.be> a écrit :
>> This works as far as I can see.
> 
> This is very very good news. I'll commit that as soon as the rest is in a 
> good enough shape, since the two are related. Thanks a lot for the detective 
> work.
> 
> JMarc




smime.p7s
Description: S/MIME cryptographic signature

Re: LyX-Workarea: Background not shown correctly

[Patrick De Visschere]

This works as far as I can see.


> On 19 Oct 2017, at 17:34, Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote:
> 
> Le 16/10/2017 à 14:48, Patrick De Visschere a écrit :
>> I’ve defined a watchpoint on what I believe is the backingstore image and 
>> this is the complete call stack:
> 
> This callstack is very interesting. It tells us that syncBackingStore is 
> invoked from QWidget::event for the event UpdateRequest (14). In turn at (16) 
> we have an occasion of cathcing this event and ask for a full redraw.
> 
> Could you try the following pair of patches? The first one is the one I am 
> working on in another thread (but which is not ready yet) and the second is 
> the one of interest here (but it depends of the first one).
> 
> JMarc
> <0001-Allow-multiple-calls-to-processUpdateFlags-before-re.patch><0001-Tentative-patch-fix-black-screen-on-Mac.patch>




smime.p7s
Description: S/MIME cryptographic signature

Re: LyX-Workarea: Background not shown correctly

[Patrick De Visschere]

> On 16 Oct 2017, at 11:41, Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote:
> 
> Le 13/10/2017 à 11:00, Patrick De Visschere a écrit :
>> But I see your point;
>> When I remove the line setting WA_OpaquePaintEvent the problem remains but 
>> (most of) the view turns white instead of black;
>> When I set WA_NoSystemBackground instead the problem remains the same.
>> When I insert viewport()->update(0,0,500,500) then everything outside this 
>> square remains untouched but the problem persists within that square.
> 
> Did you try setting both WA_OpaquePaintEvent and WA_NoSystemBackground?

It doesn’t make a difference.

> 
> Does it make a difference to set them on GuiWorkarea too (additionally to the 
> viewport)?

No. I didn’t try all combinations but adding WA_OpaquePaintEvent and then also 
WA_NoSystemBackground does not make a difference.

pdv

> 
> JMarc




smime.p7s
Description: S/MIME cryptographic signature

Re: LyX-Workarea: Background not shown correctly

[Patrick De Visschere]

I’ve done some more debugging and I believe I’ve found the Qt code that turns 
the background black or white.
Om macos (and probably also on windows) Qt uses a QBackingStore for painting. I 
couldn’t find a QPlatformBackingStore for linux so I assume the implementation 
is different on linux, which would explain the different behaviour.

When issuing an viewport()->update() the region (the complete viewport if no 
smaller area is specified) is marked as dirty and at paint time is then 
repainted, via QWidgetBackingStore::doSync().
In QRasterBackingStore::beginPaint() the region is initially filled with a 
color Qt::transparent which has alpha=r=g=b=0 which will leave the screen black 
if not overwritten.

When WA_OpaquePaintEvent is not set this is followed by a paintBackground() 
call which fills the region with the autoFillBrush-color which has all ones. 
This will leave the screen white if not overwritten.

Depending on the update_strategy_ only a part of the screen is overwritten by 
lyx, leaving the rest black or white.
I assume that in the tests I’ve described previously all actions restoring the 
normal view somehow trigger a FullScreenUpdate.

pdv

> On 12 Oct 2017, at 21:30, Jean-Marc Lasgouttes  wrote:
> 
> Le 08/10/2017 à 18:57, pdv a écrit :
>> The new code contains twice a viewport()->update() without specification of 
>> a rectangle. Since > Qt normally erases the widget's area before the 
>> paintEvent() call
>> I guess that the whole viewport is erased. Subsequently only part of it is 
>> redrawn except for the case FullScreenUpdate and in that case there is no 
>> problem.
> 
> Actually, we use
>   viewport()->setAttribute(Qt::WA_OpaquePaintEvent);
> to ask Qt not to overwrite it. It seems to work on Linux.
> 
> Please feel free to look at the code and docs (QWidget and 
> QAbstractScrollArea) and tell us what I may have missed. I just saw that we 
> should override viewportEvent() instead of event(), but I am not sure that it 
> would make a difference.
> 
> Can you compile master? Do you see the issue?
> 
> JMarc




smime.p7s
Description: S/MIME cryptographic signature

Re: LyX-Workarea: Background not shown correctly

[Patrick De Visschere]

> On 12 Oct 2017, at 21:30, Jean-Marc Lasgouttes  wrote:
> 
> Le 08/10/2017 à 18:57, pdv a écrit :
>> The new code contains twice a viewport()->update() without specification of 
>> a rectangle. Since > Qt normally erases the widget's area before the 
>> paintEvent() call
>> I guess that the whole viewport is erased. Subsequently only part of it is 
>> redrawn except for the case FullScreenUpdate and in that case there is no 
>> problem.
> 
> Actually, we use
>   viewport()->setAttribute(Qt::WA_OpaquePaintEvent);
> to ask Qt not to overwrite it. It seems to work on Linux.

I compared the old and the new code and noticed that in the old code update(x, 
y, w, h) was always used with coordinates.
This explanation seemed to make some sense since often a single line remains 
indeed visible (see tests below).
And when I force a FullScreenUpdate in BufferView::draw then the problem goes 
away.

But I see your point;
When I remove the line setting WA_OpaquePaintEvent the problem remains but 
(most of) the view turns white instead of black;
When I set WA_NoSystemBackground instead the problem remains the same.
When I insert viewport()->update(0,0,500,500) then everything outside this 
square remains untouched but the problem persists within that square.

It seems that update(area) restricts updating to the selected area, but 
apparently (at least on macos) one is then obliged to redraw that area 
completely.

The Qt-docs read as follows:
"Qt::WA_OpaquePaintEventIndicates that the widget paints all its pixels 
when it receives a paint event. Thus, it is not required for operations like 
updating, resizing, scrolling and focus changes to erase the widget before 
generating paint events. …."

I understand this as: since the widget will repaint all its pixels, there is no 
need (for Qt) to erase the widget.

Another fragment, dealing with an example, reads:
"The right widget has the Qt::WA_OpaquePaintEvent widget attribute set. This 
indicates that the widget will paint over its entire area with opaque colors. 
The widget's area will initially be uninitialized, represented in the diagram 
with a red diagonal grid pattern that shines through the overpainted area. The 
Qt::WA_OpaquePaintArea attribute is useful for widgets that need to paint their 
own specialized contents quickly and do not need a default filled background."

Apparently “uninitialized” means “black".

I have no idea why this turns out correctly under linux.

> 
> Please feel free to look at the code and docs (QWidget and 
> QAbstractScrollArea) and tell us what I may have missed. I just saw that we 
> should override viewportEvent() instead of event(), but I am not sure that it 
> would make a difference.
> 
> Can you compile master? Do you see the issue?

Yes and yes;
Here are some observations (I used the Help/Introduction for testing):

- Clicking anywhere in the window (or when scrolling) restores the view.
- Inserting a CR anywhere restores the view.
- Selecting anything by double clicking turns the screen black, except for some 
insets (like LYX, a footnote, Table of Contents) which remain visible.
- Hovering with the mouse over a footnote or Table of Contents restores the 
view.
- When moving the cursor up/down with the up/down keys usually only one line is 
visible (in addition to the elements mentioned higher) but it’s the line 
above/below the one containing the cursor.
- This is also true when starting from a normal view. Moving the cursor up/down 
leaves the line visible where the cursor was positioned. However when a word is 
marked by the spellchecker then one must move the cursor an additional line 
before the view goes black (one can thus move the cursor within 3 lines without 
going black).
- When moving the cursor horizontally with the arrow keys; the screen goes 
black except for the current line (and the insets).
- Moving the cursor horizontally in a word marked by the spellchecker causes no 
problem. The view goes black only when entering an adjacent word.
- Sometimes the view is completely blacked, also the special insets. E.g. when 
bringing the window to the foreground.

Replacing GuiWorkArea::event() by viewportEvent() does not make a difference.

If you have a suggestion for a specific test, let me know.

> 
> JMarc




smime.p7s
Description: S/MIME cryptographic signature

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Patrick De Visschere]

Sent from my iPad

 On 25 Aug 2014, at 07:55, Stephan Witt st.w...@gmx.net wrote:
 
 Am 23.08.2014 um 18:01 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 On 23 Aug, 2014, at 14:50 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 23.08.2014 um 12:01 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 On 20 Aug, 2014, at 23:15 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 20.08.2014 um 22:45 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 On 20 Aug, 2014, at 11:22 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 19.08.2014 um 22:41 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 On 19 Aug, 2014, at 14:12 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 17.08.2014 um 20:13 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 My environment
 
 * Mac OS X 10.9.4
 * Darwin Kernel Version 13.3.0
 * Qt 5.3.1 (stable branch) (default Cocoa)
 ./configure -opensource -silent -shared -release -no-dbus -nomake 
 examples -nomake tools -no-framework
 
 You don't build the libraries as frameworks. I'm not sure if this makes 
 no difference.
 
 I'm using the Qt frameworks I've build myself.
 
 Stephan
 
 Stephan,
 
 I was planning to do that. (the qt-debug build does not make a 
 difference as you expected)
 
 I suppose you use the LyX-Mac-binary-release.sh script.
 
 I have never managed to use this script without making changes to it, 
 perhaps because I’m using it the wrong way.
 
 I build qt as a framework separately and would then use the script like:
 
 sh development/LyX-Mac-binary-release.sh  --with-qt-frameworks=yes  
 --with-qt-dir=/Users/pdv/Developer/public/Trolltech/Qt-5.3.1 
 --qt-deployment=yes --with-macosx-target=10.8 --with-sdkroot=10.8 
 --with-arch=x86_64 --with-libiconv-prefix=/opt/local --enable-debug
 
 I think the --with-qt-frameworks=yes is needed to include qt as a 
 framework;
 
 and --with-qt-dir=/… points to the dir where the  qt-framework has been 
 installed (previously).
 
 I’m not sure about the exact meaning of --qt-deployment=yes  but I think 
  I need it too.
 
 What I don’t understand are the lines 260-262
 if [ ${configure_qt_frameworks} != yes ]; then
QtInstallDir=${QTDIR:-/opt/qt4}
 fi
 
 with --with-qt-frameworks=yes, QtInstallDir is not set.
 
 Therefore I uncomment the if/fi so that
 QtInstallDir=${QTDIR:-/opt/qt4”}
 
 is always executed and QtInstallDir points to my qt-install dir.
 
 In addition I must modify some CPPFLAGS= ...
 
 Any idea what I’m doing wrong?
 
 Patrick De Visschere
 
 Perhaps I should remove the --with-qt-frameworks switch. I don't use it 
 anymore
 and it was meant as with the frameworks by Qt (Nokia). The 
 --qt-deployment=yes
 is default and with it the script copies the frameworks to the package. 
 This is
 needed if you want to use the LyX app on another system.
 
 I'd avoid the --with-libiconv-prefix=/opt/local switch.
 
 This is the shell script I'm using for calling LyX-Mac-binary-release.sh:
 
 #!/bin/sh
 ARCH=x86_64
 QtVersion=5.3.1
 QtAPI=-cocoa
 LyXVersion=lyx
 CC=cc CXX=c++ \
 QtConfigureOptions=-debug-and-release QtAPI=${QtAPI} 
 QtVersion=${QtVersion} \
 sh ${MKFLAGS} ${LyXVersion}/development/LyX-Mac-binary-release.sh \
 --with-sdkroot=10.8 --with-macosx-target=10.6 --with-arch=${ARCH} \
 --with-qt-dir=/Users/Shared/LyX/qt-${QtVersion}-frameworks${QtAPI}-${ARCH}
  \
 $@
 
 Stephan
 
 I’ve build LyX+Qt5 with the LyX-Mac-binary-release.sh script and the 
 menubar appears immediately. Since with XCode I use the macports iconv 
 library that could still theoretically be the culprit. Or maybe it’s just 
 due to Xcode. Anyway this is not very important;
 I tried to build (with Xcode) without aspell and hunspell but somehow 
 cmake doesn’t want that.
 
 This is my script to call cmake for Xcode project generation:
 
 #!/bin/sh
 export PATH=/Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64/bin:${PATH}
 LyxSourceDir=$(pwd)/lyx
 LyxUtilDir=/Users/Shared/LyX/utilities
 CMAKE_GENERATOR=Xcode
 LyXVersion=$(grep AC_INIT ${LyxSourceDir}/configure.ac | cut -d, -f2 | tr 
 -d  ())
 LyxBuildDir=lyx-build/cmake/${LyXVersion}
 if [ -f ${LyxSourceDir}/development/cmake/CMakeLists.txt ]; then
 TOPCMAKE=${LyxSourceDir}/development/cmake
 COPYRESOURCES=yes
 else
 TOPCMAKE=${LyxSourceDir}
 fi
 rm -rf ${LyxBuildDir}
 mkdir -p ${LyxBuildDir}
 
 case $(qmake -version) in
 *Using*5.*)
 LYX_USE_QT=-DLYX_USE_QT=QT5
 esac
 
 SPELLER_OPTIONS=-DASPELL_INCLUDE_DIR=${LyxUtilDir}/include \
 -DASPELL_LIBRARY_RELEASE=${LyxUtilDir}/lib/libaspell.dylib \
 -DHUNSPELL_INCLUDE_DIR=${LyxUtilDir}/include \
 -DHUNSPELL_LIBRARY=${LyxUtilDir}/lib/libhunspell.dylib \
 -DMagic_INCLUDE_DIR=${LyxUtilDir}/include \
 -DMagic_LIBRARY=${LyxUtilDir}/lib/libmagic.dylib \
 -DLYX_ASPELL=ON -DLYX_HUNSPELL=ON
 (
 cd ${LyxBuildDir}  \
 cmake -G ${CMAKE_GENERATOR} ${TOPCMAKE} \
-DLYX_NLS=OFF \
-DLYX_DEVEL_VERSION=ON -DLYX_DEBUG=ON -DLYX_RELEASE=OFF \
-DLYX_DEBUG_GLIBC=OFF -DLYX_DEBUG_GLIBC_PEDANTIC=OFF \
-DLYX_PACKAGE_SUFFIX=OFF -DLYX_PROGRAM_SUFFIX=OFF

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Patrick De Visschere]

Sent from my iPad

> On 25 Aug 2014, at 07:55, Stephan Witt <st.w...@gmx.net> wrote:
> 
>> Am 23.08.2014 um 18:01 schrieb Patrick De Visschere <pdvissch...@edpnet.be>:
>> 
>>> On 23 Aug, 2014, at 14:50 , Stephan Witt <st.w...@gmx.net> wrote:
>>> 
>>>> Am 23.08.2014 um 12:01 schrieb Patrick De Visschere 
>>>> <pdvissch...@edpnet.be>:
>>>> 
>>>>> On 20 Aug, 2014, at 23:15 , Stephan Witt <st.w...@gmx.net> wrote:
>>>>> 
>>>>>> Am 20.08.2014 um 22:45 schrieb Patrick De Visschere 
>>>>>> <pdvissch...@edpnet.be>:
>>>>>> 
>>>>>>> On 20 Aug, 2014, at 11:22 , Stephan Witt <st.w...@gmx.net> wrote:
>>>>>>> 
>>>>>>>> Am 19.08.2014 um 22:41 schrieb Patrick De Visschere 
>>>>>>>> <pdvissch...@edpnet.be>:
>>>>>>>> 
>>>>>>>>> On 19 Aug, 2014, at 14:12 , Stephan Witt <st.w...@gmx.net> wrote:
>>>>>>>>> 
>>>>>>>>> Am 17.08.2014 um 20:13 schrieb Patrick De Visschere 
>>>>>>>>> <pdvissch...@edpnet.be>:
>>>>>>>> 
>>>>>>>> My environment
>>>>>>>> 
>>>>>>>> * Mac OS X 10.9.4
>>>>>>>> * Darwin Kernel Version 13.3.0
>>>>>>>> * Qt 5.3.1 (stable branch) (default Cocoa)
>>>>>>>> ./configure -opensource -silent -shared -release -no-dbus -nomake 
>>>>>>>> examples -nomake tools -no-framework
>>>>>>> 
>>>>>>> You don't build the libraries as frameworks. I'm not sure if this makes 
>>>>>>> no difference.
>>>>>>> 
>>>>>>> I'm using the Qt frameworks I've build myself.
>>>>>>> 
>>>>>>> Stephan
>>>>>> 
>>>>>> Stephan,
>>>>>> 
>>>>>> I was planning to do that. (the qt-debug build does not make a 
>>>>>> difference as you expected)
>>>>>> 
>>>>>> I suppose you use the LyX-Mac-binary-release.sh script.
>>>>>> 
>>>>>> I have never managed to use this script without making changes to it, 
>>>>>> perhaps because I’m using it the wrong way.
>>>>>> 
>>>>>> I build qt as a framework separately and would then use the script like:
>>>>>> 
>>>>>> sh development/LyX-Mac-binary-release.sh  --with-qt-frameworks=yes  
>>>>>> --with-qt-dir=/Users/pdv/Developer/public/Trolltech/Qt-5.3.1 
>>>>>> --qt-deployment=yes --with-macosx-target=10.8 --with-sdkroot=10.8 
>>>>>> --with-arch=x86_64 --with-libiconv-prefix=/opt/local --enable-debug
>>>>>> 
>>>>>> I think the --with-qt-frameworks=yes is needed to include qt as a 
>>>>>> framework;
>>>>>> 
>>>>>> and --with-qt-dir=/… points to the dir where the  qt-framework has been 
>>>>>> installed (previously).
>>>>>> 
>>>>>> I’m not sure about the exact meaning of --qt-deployment=yes  but I think 
>>>>>>  I need it too.
>>>>>> 
>>>>>> What I don’t understand are the lines 260-262
>>>>>> if [ "${configure_qt_frameworks}" != "yes" ]; then
>>>>>>QtInstallDir=${QTDIR:-"/opt/qt4"}
>>>>>> fi
>>>>>> 
>>>>>> with --with-qt-frameworks=yes, QtInstallDir is not set.
>>>>>> 
>>>>>> Therefore I uncomment the if/fi so that
>>>>>> QtInstallDir=${QTDIR:-"/opt/qt4”}
>>>>>> 
>>>>>> is always executed and QtInstallDir points to my qt-install dir.
>>>>>> 
>>>>>> In addition I must modify some CPPFLAGS= ...
>>>>>> 
>>>>>> Any idea what I’m doing wrong?
>>>>>> 
>>>>>> Patrick De Visschere
>>>>> 
>>>>> Perhaps I should remove the --with-qt-frameworks switch. I don't use it 
>>>>> anymore
>>>>> and it was meant as "with the frameworks by Qt (Nokia)". The 
>>>>> --qt-deployment=yes
>>>>> is default and with it the script copies the frameworks to the package

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Patrick De Visschere]

On 20 Aug, 2014, at 23:15 , Stephan Witt st.w...@gmx.net wrote:

 Am 20.08.2014 um 22:45 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 On 20 Aug, 2014, at 11:22 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 19.08.2014 um 22:41 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 On 19 Aug, 2014, at 14:12 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 17.08.2014 um 20:13 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 My environment
 
 * Mac OS X 10.9.4
 * Darwin Kernel Version 13.3.0
 * Qt 5.3.1 (stable branch) (default Cocoa)
 ./configure -opensource -silent -shared -release -no-dbus -nomake examples 
 -nomake tools -no-framework
 
 You don't build the libraries as frameworks. I'm not sure if this makes no 
 difference.
 
 I'm using the Qt frameworks I've build myself.
 
 Stephan
 
 Stephan,
 
 I was planning to do that. (the qt-debug build does not make a difference as 
 you expected)
 
 I suppose you use the LyX-Mac-binary-release.sh script.
 
 I have never managed to use this script without making changes to it, 
 perhaps because I’m using it the wrong way.
 
 I build qt as a framework separately and would then use the script like:
 
 sh development/LyX-Mac-binary-release.sh  --with-qt-frameworks=yes  
 --with-qt-dir=/Users/pdv/Developer/public/Trolltech/Qt-5.3.1 
 --qt-deployment=yes --with-macosx-target=10.8 --with-sdkroot=10.8 
 --with-arch=x86_64 --with-libiconv-prefix=/opt/local --enable-debug
 
 I think the --with-qt-frameworks=yes is needed to include qt as a framework;
 
 and --with-qt-dir=/… points to the dir where the  qt-framework has been 
 installed (previously).
 
 I’m not sure about the exact meaning of --qt-deployment=yes  but I think  I 
 need it too.
 
 What I don’t understand are the lines 260-262
 if [ ${configure_qt_frameworks} != yes ]; then
  QtInstallDir=${QTDIR:-/opt/qt4}
 fi
 
 with --with-qt-frameworks=yes, QtInstallDir is not set.
 
 Therefore I uncomment the if/fi so that
 QtInstallDir=${QTDIR:-/opt/qt4”}
 
 is always executed and QtInstallDir points to my qt-install dir.
 
 In addition I must modify some CPPFLAGS= ...
 
 Any idea what I’m doing wrong?
 
 Patrick De Visschere
 
 Perhaps I should remove the --with-qt-frameworks switch. I don't use it 
 anymore
 and it was meant as with the frameworks by Qt (Nokia). The 
 --qt-deployment=yes
 is default and with it the script copies the frameworks to the package. This 
 is
 needed if you want to use the LyX app on another system.
 
 I'd avoid the --with-libiconv-prefix=/opt/local switch.
 
 This is the shell script I'm using for calling LyX-Mac-binary-release.sh:
 
 #!/bin/sh
 ARCH=x86_64
 QtVersion=5.3.1
 QtAPI=-cocoa
 LyXVersion=lyx
 CC=cc CXX=c++ \
 QtConfigureOptions=-debug-and-release QtAPI=${QtAPI} QtVersion=${QtVersion} 
 \
 sh ${MKFLAGS} ${LyXVersion}/development/LyX-Mac-binary-release.sh \
   --with-sdkroot=10.8 --with-macosx-target=10.6 --with-arch=${ARCH} \
   --with-qt-dir=/Users/Shared/LyX/qt-${QtVersion}-frameworks${QtAPI}-${ARCH} \
   $@
 
 Stephan

I’ve build LyX+Qt5 with the LyX-Mac-binary-release.sh script and the menubar 
appears immediately. Since with XCode I use the macports iconv library that 
could still theoretically be the culprit. Or maybe it’s just due to Xcode. 
Anyway this is not very important;
I tried to build (with Xcode) without aspell and hunspell but somehow cmake 
doesn’t want that.

There were/are still some problems (with the manual build):

1) Aspell as it is fails to build (on 10.9 I assume). This is easily solved by 
applying the small patch used by macports.

2) I don’t understand how the lyx-build is supposed to find the Qt5-frameworks; 
Apparently the switches
--enable-qt5 --with-qt-dir=/Users/pdv/Developer/public/Trolltech/Qt-5.3.1
are not sufficient.
As before I changed the FLAGS in the script as follows (this is around line 610 
of the script)

if [ $configure_qt_frameworks = yes ]; then
export QT_CORE_CFLAGS=-FQtCore
export QT_CORE_LIBS=-framework QtCore
export QT_FRONTEND_CFLAGS=-FQtGui
export QT_FRONTEND_LIBS=-framework QtGui
CPPFLAGS=${CPPFLAGS} 
-I${SDKROOT}/Library/Frameworks/QtCore.framework/Headers
CPPFLAGS=${CPPFLAGS} 
-I${SDKROOT}/Library/Frameworks/QtGui.framework/Headers
else
CPPFLAGS=${CPPFLAGS} 
-I${QtInstallDir}/lib/QtCore.framework/Headers
CPPFLAGS=${CPPFLAGS} 
-I${QtInstallDir}/lib/QtGui.framework/Headers
CPPFLAGS=${CPPFLAGS} 
-I${QtInstallDir}/lib/QtWidgets.framework/Headers
CPPFLAGS=${CPPFLAGS} 
-I${QtInstallDir}/lib/QtMacExtras.framework/Headers
CPPFLAGS=${CPPFLAGS} 
-I${QtInstallDir}/lib/QtConcurrent.framework/Headers
CPPFLAGS=${CPPFLAGS} -F${QtInstallDir}/lib
LDFLAGS=-L/usr/lib ${LDFLAGS} -F${QtInstallDir}/lib

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Patrick De Visschere]

On 23 Aug, 2014, at 14:50 , Stephan Witt st.w...@gmx.net wrote:

 Am 23.08.2014 um 12:01 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 On 20 Aug, 2014, at 23:15 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 20.08.2014 um 22:45 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 On 20 Aug, 2014, at 11:22 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 19.08.2014 um 22:41 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 On 19 Aug, 2014, at 14:12 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 17.08.2014 um 20:13 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 My environment
 
 * Mac OS X 10.9.4
 * Darwin Kernel Version 13.3.0
 * Qt 5.3.1 (stable branch) (default Cocoa)
 ./configure -opensource -silent -shared -release -no-dbus -nomake 
 examples -nomake tools -no-framework
 
 You don't build the libraries as frameworks. I'm not sure if this makes 
 no difference.
 
 I'm using the Qt frameworks I've build myself.
 
 Stephan
 
 Stephan,
 
 I was planning to do that. (the qt-debug build does not make a difference 
 as you expected)
 
 I suppose you use the LyX-Mac-binary-release.sh script.
 
 I have never managed to use this script without making changes to it, 
 perhaps because I’m using it the wrong way.
 
 I build qt as a framework separately and would then use the script like:
 
 sh development/LyX-Mac-binary-release.sh  --with-qt-frameworks=yes  
 --with-qt-dir=/Users/pdv/Developer/public/Trolltech/Qt-5.3.1 
 --qt-deployment=yes --with-macosx-target=10.8 --with-sdkroot=10.8 
 --with-arch=x86_64 --with-libiconv-prefix=/opt/local --enable-debug
 
 I think the --with-qt-frameworks=yes is needed to include qt as a 
 framework;
 
 and --with-qt-dir=/… points to the dir where the  qt-framework has been 
 installed (previously).
 
 I’m not sure about the exact meaning of --qt-deployment=yes  but I think  
 I need it too.
 
 What I don’t understand are the lines 260-262
 if [ ${configure_qt_frameworks} != yes ]; then
QtInstallDir=${QTDIR:-/opt/qt4}
 fi
 
 with --with-qt-frameworks=yes, QtInstallDir is not set.
 
 Therefore I uncomment the if/fi so that
 QtInstallDir=${QTDIR:-/opt/qt4”}
 
 is always executed and QtInstallDir points to my qt-install dir.
 
 In addition I must modify some CPPFLAGS= ...
 
 Any idea what I’m doing wrong?
 
 Patrick De Visschere
 
 Perhaps I should remove the --with-qt-frameworks switch. I don't use it 
 anymore
 and it was meant as with the frameworks by Qt (Nokia). The 
 --qt-deployment=yes
 is default and with it the script copies the frameworks to the package. 
 This is
 needed if you want to use the LyX app on another system.
 
 I'd avoid the --with-libiconv-prefix=/opt/local switch.
 
 This is the shell script I'm using for calling LyX-Mac-binary-release.sh:
 
 #!/bin/sh
 ARCH=x86_64
 QtVersion=5.3.1
 QtAPI=-cocoa
 LyXVersion=lyx
 CC=cc CXX=c++ \
 QtConfigureOptions=-debug-and-release QtAPI=${QtAPI} 
 QtVersion=${QtVersion} \
 sh ${MKFLAGS} ${LyXVersion}/development/LyX-Mac-binary-release.sh \
  --with-sdkroot=10.8 --with-macosx-target=10.6 --with-arch=${ARCH} \
  --with-qt-dir=/Users/Shared/LyX/qt-${QtVersion}-frameworks${QtAPI}-${ARCH} 
 \
  $@
 
 Stephan
 
 I’ve build LyX+Qt5 with the LyX-Mac-binary-release.sh script and the menubar 
 appears immediately. Since with XCode I use the macports iconv library that 
 could still theoretically be the culprit. Or maybe it’s just due to Xcode. 
 Anyway this is not very important;
 I tried to build (with Xcode) without aspell and hunspell but somehow cmake 
 doesn’t want that.
 
 This is my script to call cmake for Xcode project generation:
 
 #!/bin/sh
 export PATH=/Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64/bin:${PATH}
 LyxSourceDir=$(pwd)/lyx
 LyxUtilDir=/Users/Shared/LyX/utilities
 CMAKE_GENERATOR=Xcode
 LyXVersion=$(grep AC_INIT ${LyxSourceDir}/configure.ac | cut -d, -f2 | tr 
 -d  ())
 LyxBuildDir=lyx-build/cmake/${LyXVersion}
 if [ -f ${LyxSourceDir}/development/cmake/CMakeLists.txt ]; then
   TOPCMAKE=${LyxSourceDir}/development/cmake
   COPYRESOURCES=yes
 else
   TOPCMAKE=${LyxSourceDir}
 fi
 rm -rf ${LyxBuildDir}
 mkdir -p ${LyxBuildDir}
 
 case $(qmake -version) in
 *Using*5.*)
   LYX_USE_QT=-DLYX_USE_QT=QT5
 esac
 
 SPELLER_OPTIONS=-DASPELL_INCLUDE_DIR=${LyxUtilDir}/include \
   -DASPELL_LIBRARY_RELEASE=${LyxUtilDir}/lib/libaspell.dylib \
   -DHUNSPELL_INCLUDE_DIR=${LyxUtilDir}/include \
   -DHUNSPELL_LIBRARY=${LyxUtilDir}/lib/libhunspell.dylib \
   -DMagic_INCLUDE_DIR=${LyxUtilDir}/include \
   -DMagic_LIBRARY=${LyxUtilDir}/lib/libmagic.dylib \
   -DLYX_ASPELL=ON -DLYX_HUNSPELL=ON
 (
   cd ${LyxBuildDir}  \
   cmake -G ${CMAKE_GENERATOR} ${TOPCMAKE} \
  -DLYX_NLS=OFF \
  -DLYX_DEVEL_VERSION=ON -DLYX_DEBUG=ON -DLYX_RELEASE=OFF \
  -DLYX_DEBUG_GLIBC=OFF -DLYX_DEBUG_GLIBC_PEDANTIC=OFF \
  -DLYX_PACKAGE_SUFFIX=OFF -DLYX_PROGRAM_SUFFIX=OFF \
  ${LYX_USE_QT} \
  ${SPELLER_OPTIONS} \
  $@
 )
 # end of script
 
 I'm using only self made libraries with Xcode too. Therefore I

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Patrick De Visschere]

On 20 Aug, 2014, at 23:15 , Stephan Witt <st.w...@gmx.net> wrote:

> Am 20.08.2014 um 22:45 schrieb Patrick De Visschere <pdvissch...@edpnet.be>:
> 
>> On 20 Aug, 2014, at 11:22 , Stephan Witt <st.w...@gmx.net> wrote:
>> 
>>> Am 19.08.2014 um 22:41 schrieb Patrick De Visschere <pdvissch...@edpnet.be>:
>>> 
>>>> On 19 Aug, 2014, at 14:12 , Stephan Witt <st.w...@gmx.net> wrote:
>>>> 
>>>>> Am 17.08.2014 um 20:13 schrieb Patrick De Visschere 
>>>>> <pdvissch...@edpnet.be>:
>>>> 
>>>> My environment
>>>> 
>>>> * Mac OS X 10.9.4
>>>> * Darwin Kernel Version 13.3.0
>>>> * Qt 5.3.1 (stable branch) (default Cocoa)
>>>> ./configure -opensource -silent -shared -release -no-dbus -nomake examples 
>>>> -nomake tools -no-framework
>>> 
>>> You don't build the libraries as frameworks. I'm not sure if this makes no 
>>> difference.
>>> 
>>> I'm using the Qt frameworks I've build myself.
>>> 
>>> Stephan
>> 
>> Stephan,
>> 
>> I was planning to do that. (the qt-debug build does not make a difference as 
>> you expected)
>> 
>> I suppose you use the LyX-Mac-binary-release.sh script.
>> 
>> I have never managed to use this script without making changes to it, 
>> perhaps because I’m using it the wrong way.
>> 
>> I build qt as a framework separately and would then use the script like:
>> 
>> sh development/LyX-Mac-binary-release.sh  --with-qt-frameworks=yes  
>> --with-qt-dir=/Users/pdv/Developer/public/Trolltech/Qt-5.3.1 
>> --qt-deployment=yes --with-macosx-target=10.8 --with-sdkroot=10.8 
>> --with-arch=x86_64 --with-libiconv-prefix=/opt/local --enable-debug
>> 
>> I think the --with-qt-frameworks=yes is needed to include qt as a framework;
>> 
>> and --with-qt-dir=/… points to the dir where the  qt-framework has been 
>> installed (previously).
>> 
>> I’m not sure about the exact meaning of --qt-deployment=yes  but I think  I 
>> need it too.
>> 
>> What I don’t understand are the lines 260-262
>> if [ "${configure_qt_frameworks}" != "yes" ]; then
>>  QtInstallDir=${QTDIR:-"/opt/qt4"}
>> fi
>> 
>> with --with-qt-frameworks=yes, QtInstallDir is not set.
>> 
>> Therefore I uncomment the if/fi so that
>> QtInstallDir=${QTDIR:-"/opt/qt4”}
>> 
>> is always executed and QtInstallDir points to my qt-install dir.
>> 
>> In addition I must modify some CPPFLAGS= ...
>> 
>> Any idea what I’m doing wrong?
>> 
>> Patrick De Visschere
> 
> Perhaps I should remove the --with-qt-frameworks switch. I don't use it 
> anymore
> and it was meant as "with the frameworks by Qt (Nokia)". The 
> --qt-deployment=yes
> is default and with it the script copies the frameworks to the package. This 
> is
> needed if you want to use the LyX app on another system.
> 
> I'd avoid the --with-libiconv-prefix=/opt/local switch.
> 
> This is the shell script I'm using for calling LyX-Mac-binary-release.sh:
> 
> #!/bin/sh
> ARCH=x86_64
> QtVersion=5.3.1
> QtAPI=-cocoa
> LyXVersion=lyx
> CC=cc CXX=c++ \
> QtConfigureOptions="-debug-and-release" QtAPI=${QtAPI} QtVersion=${QtVersion} 
> \
> sh ${MKFLAGS} ${LyXVersion}/development/LyX-Mac-binary-release.sh \
>   --with-sdkroot=10.8 --with-macosx-target=10.6 --with-arch=${ARCH} \
>   --with-qt-dir=/Users/Shared/LyX/qt-${QtVersion}-frameworks${QtAPI}-${ARCH} \
>   "$@"
> 
> Stephan

I’ve build LyX+Qt5 with the LyX-Mac-binary-release.sh script and the menubar 
appears immediately. Since with XCode I use the macports iconv library that 
could still theoretically be the culprit. Or maybe it’s just due to Xcode. 
Anyway this is not very important;
I tried to build (with Xcode) without aspell and hunspell but somehow cmake 
doesn’t want that.

There were/are still some problems (with the manual build):

1) Aspell as it is fails to build (on 10.9 I assume). This is easily solved by 
applying the small patch used by macports.

2) I don’t understand how the lyx-build is supposed to find the Qt5-frameworks; 
Apparently the switches
--enable-qt5 --with-qt-dir=/Users/pdv/Developer/public/Trolltech/Qt-5.3.1
are not sufficient.
As before I changed the FLAGS in the script as follows (this is around line 610 
of the script)

if [ "$configure_qt_frameworks" = "yes" ]; then
export QT_CORE_CFLAGS="-FQtCore"
export QT_CORE_LIBS="-framework QtCore"
 

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Patrick De Visschere]

On 23 Aug, 2014, at 14:50 , Stephan Witt <st.w...@gmx.net> wrote:

> Am 23.08.2014 um 12:01 schrieb Patrick De Visschere <pdvissch...@edpnet.be>:
> 
>> On 20 Aug, 2014, at 23:15 , Stephan Witt <st.w...@gmx.net> wrote:
>> 
>>> Am 20.08.2014 um 22:45 schrieb Patrick De Visschere <pdvissch...@edpnet.be>:
>>> 
>>>> On 20 Aug, 2014, at 11:22 , Stephan Witt <st.w...@gmx.net> wrote:
>>>> 
>>>>> Am 19.08.2014 um 22:41 schrieb Patrick De Visschere 
>>>>> <pdvissch...@edpnet.be>:
>>>>> 
>>>>>> On 19 Aug, 2014, at 14:12 , Stephan Witt <st.w...@gmx.net> wrote:
>>>>>> 
>>>>>>> Am 17.08.2014 um 20:13 schrieb Patrick De Visschere 
>>>>>>> <pdvissch...@edpnet.be>:
>>>>>> 
>>>>>> My environment
>>>>>> 
>>>>>> * Mac OS X 10.9.4
>>>>>> * Darwin Kernel Version 13.3.0
>>>>>> * Qt 5.3.1 (stable branch) (default Cocoa)
>>>>>> ./configure -opensource -silent -shared -release -no-dbus -nomake 
>>>>>> examples -nomake tools -no-framework
>>>>> 
>>>>> You don't build the libraries as frameworks. I'm not sure if this makes 
>>>>> no difference.
>>>>> 
>>>>> I'm using the Qt frameworks I've build myself.
>>>>> 
>>>>> Stephan
>>>> 
>>>> Stephan,
>>>> 
>>>> I was planning to do that. (the qt-debug build does not make a difference 
>>>> as you expected)
>>>> 
>>>> I suppose you use the LyX-Mac-binary-release.sh script.
>>>> 
>>>> I have never managed to use this script without making changes to it, 
>>>> perhaps because I’m using it the wrong way.
>>>> 
>>>> I build qt as a framework separately and would then use the script like:
>>>> 
>>>> sh development/LyX-Mac-binary-release.sh  --with-qt-frameworks=yes  
>>>> --with-qt-dir=/Users/pdv/Developer/public/Trolltech/Qt-5.3.1 
>>>> --qt-deployment=yes --with-macosx-target=10.8 --with-sdkroot=10.8 
>>>> --with-arch=x86_64 --with-libiconv-prefix=/opt/local --enable-debug
>>>> 
>>>> I think the --with-qt-frameworks=yes is needed to include qt as a 
>>>> framework;
>>>> 
>>>> and --with-qt-dir=/… points to the dir where the  qt-framework has been 
>>>> installed (previously).
>>>> 
>>>> I’m not sure about the exact meaning of --qt-deployment=yes  but I think  
>>>> I need it too.
>>>> 
>>>> What I don’t understand are the lines 260-262
>>>> if [ "${configure_qt_frameworks}" != "yes" ]; then
>>>>QtInstallDir=${QTDIR:-"/opt/qt4"}
>>>> fi
>>>> 
>>>> with --with-qt-frameworks=yes, QtInstallDir is not set.
>>>> 
>>>> Therefore I uncomment the if/fi so that
>>>> QtInstallDir=${QTDIR:-"/opt/qt4”}
>>>> 
>>>> is always executed and QtInstallDir points to my qt-install dir.
>>>> 
>>>> In addition I must modify some CPPFLAGS= ...
>>>> 
>>>> Any idea what I’m doing wrong?
>>>> 
>>>> Patrick De Visschere
>>> 
>>> Perhaps I should remove the --with-qt-frameworks switch. I don't use it 
>>> anymore
>>> and it was meant as "with the frameworks by Qt (Nokia)". The 
>>> --qt-deployment=yes
>>> is default and with it the script copies the frameworks to the package. 
>>> This is
>>> needed if you want to use the LyX app on another system.
>>> 
>>> I'd avoid the --with-libiconv-prefix=/opt/local switch.
>>> 
>>> This is the shell script I'm using for calling LyX-Mac-binary-release.sh:
>>> 
>>> #!/bin/sh
>>> ARCH=x86_64
>>> QtVersion=5.3.1
>>> QtAPI=-cocoa
>>> LyXVersion=lyx
>>> CC=cc CXX=c++ \
>>> QtConfigureOptions="-debug-and-release" QtAPI=${QtAPI} 
>>> QtVersion=${QtVersion} \
>>> sh ${MKFLAGS} ${LyXVersion}/development/LyX-Mac-binary-release.sh \
>>>  --with-sdkroot=10.8 --with-macosx-target=10.6 --with-arch=${ARCH} \
>>>  --with-qt-dir=/Users/Shared/LyX/qt-${QtVersion}-frameworks${QtAPI}-${ARCH} 
>>> \
>>>  "$@"
>>> 
>>> Stephan
>> 
>> I’ve build LyX+Qt5 with the LyX-Mac-binary-release.

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Patrick De Visschere]

On 20 Aug, 2014, at 08:40 , Stephan Witt st.w...@gmx.net wrote:

 Am 19.08.2014 um 22:41 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 
 On 19 Aug, 2014, at 14:12 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 17.08.2014 um 20:13 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 On 15 Aug, 2014, at 13:57 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 12.08.2014 um 22:07 schrieb pdv pdvissch...@edpnet.be:
 
 As a follow-up on reports in the thread LyX on OS X 10.9 from some 
 months ago, I build LyX(master) + Qt5(stable) (CMake + XCode).
 
 I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by QProxyStyle 
 and observed then (at least) 2 issues:
 
 1) When starting up the menu bar is not visible; One must switch to 
 another app and then bring lyx to the foreground to make the menu bar 
 appear.
 2) When closing the (last) window the menu bar disappears mostly, except 
 for the LyX menu. This was also reported by Stephan Witt, but I did 
 observe no crash.
 
 When closing the last window Qt5 should switch to the default menu bar 
 but apparently it doesn't find one and creates it's own minimal default 
 menu bar.
 The default menu bar is created by GlobalMenuBar() (in 
 GuiApplication.cpp) which has a constructor GlobalMenuBar() : new 
 QMenuBar(0); according to the Qt docs the first parent-less QMenuBar 
 created will be used as the default menu bar. Apparently Qt5 does not 
 detect the QMenuBar(0) created via a subclass;
 
 When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) is 
 solved.
 
 GlobalMenuBar() was introduced to override the event() function to 
 handle QEvent::ShortcutOverride events but shortcuts seem to work 
 without using the GlobalMenuBar (Cmd-Q and Cmd-, work as expected; Cmd-N 
 and Cmd-O only work after first activating one of them via the menu, but 
 the latter also happens in LyX211 and may not be related to Qt5). 
 Building LyX + Qt4.8.6 confirms that GlobalMenuBar's event() is not 
 called when issuing a shortcut with no window present. I assume that 
 these standard mac-shortcuts are handled automatically by Qt.
 
 If someone wants to check this, see the attached patch, which includes 
 all changes (but does not solve issue 1)).
 
 Patrick De Visschere
 Qt5-fix-Q_WS_MACX+GlobalMenuBar.diff
 
 Hi Patrick,
 
 the GlobalMenuBar() thing is a wonderful idea! I'm struggling since a 
 while with the Qt5 build and failed to solve this issue 2. This I did 
 while being on vacation, so I couldn't answer earlier.
 
 The issue 1 was solved by Benjamin Piwowar already, IMHO. It's caused by 
 Qt5 not showing a menu top item without any action attached. The latest 
 change is the dummy action has to be attached to the sub menu after the 
 addMenu(subMenu) method call.
 
 I’ve used commit 453ce611919ff66d8b00bda9a9dcc32f4d38a843, which does 
 include this dummy action, if I’m not mistaken.
 
 Yes, me too. But this dummy action is added before the addMenu(menu) method 
 call. I've had to move it the addAction call after the addMenu call.
 
 Both issues are regressions of Qt5, IMO.
 
 The QMacStyle doesn't need to be replaced if LyX is linked with the 
 QMacExtras framework.
 
 Regarding the Q_WS_MACX macro replacement I'm not sure what should be 
 done. 
 
 1. I'd prefer to simply replace Q_WS_MACX with Q_OS_MAC which is 
 available since 4.6.x at least.
 2. I'd prefer to replace Q_WS_X11 and Q_WS_WIN with Q_OS_X11 and Q_OS_WIN 
 at the same time but cannot test all platforms.
 
 This results in the attached patch. It contains some additional changes 
 in Menu.cpp I introduced while attacking the issue 2. Furthermore I 
 changed CMakeLists.txt because of some warnings from newer cmake.
 
 This patch should not be commit as is but in some separate steps. Please, 
 if someone can try it or comment on it, I'd like to hear other opinions.
 
 
 With this patch I get basically the same behaviour as I described in my 
 initial message. Without a window being present, Cmd-O and Cmd-N don’t 
 work right away. And the application still starts without the menubar 
 being visible (issue 1), but the shortcuts do work.
 
 Ok, that's not good. 
 
 But on my system the menu bar is visible on startup.
 
 So, I'll give more details regarding my build environment:
 * Mac OS X 10.8.5
 * Darwin Kernel Version 12.5.0
 * Qt 5.3.1 Cocoa built with:
 $ configure -debug-and-release -opensource -silent -shared -confirm-license 
 -no-strip -no-kms -no-pkg-config -nomake examples -nomake tools -skip 
 qtquick1 -skip qtwebkit -skip qtconnectivity -skip qtquickcontrols -skip 
 qtdeclarative -skip qtscript -arch x86_64 -prefix 
 /Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64
 
 With autotools I build with
 * gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
 
 With cmake I build with 
 * AppleClang 5.1.0.5030040 (Apple LLVM 5.1)
 
 The LyX package I made on a Mac 10.6.8 works like the package build on 
 10.8.5.
 
 My environment
 
 * Mac OS X 10.9.4
 * Darwin Kernel

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Patrick De Visschere]

On 20 Aug, 2014, at 11:22 , Stephan Witt st.w...@gmx.net wrote:

 Am 19.08.2014 um 22:41 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 On 19 Aug, 2014, at 14:12 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 17.08.2014 um 20:13 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 My environment
 
 * Mac OS X 10.9.4
 * Darwin Kernel Version 13.3.0
 * Qt 5.3.1 (stable branch) (default Cocoa)
 ./configure -opensource -silent -shared -release -no-dbus -nomake examples 
 -nomake tools -no-framework
 
 You don't build the libraries as frameworks. I'm not sure if this makes no 
 difference.
 
 I'm using the Qt frameworks I've build myself.
 
 Stephan

Stephan,

I was planning to do that. (the qt-debug build does not make a difference as 
you expected)

I suppose you use the LyX-Mac-binary-release.sh script.

I have never managed to use this script without making changes to it, perhaps 
because I’m using it the wrong way.

I build qt as a framework separately and would then use the script like:

sh development/LyX-Mac-binary-release.sh  --with-qt-frameworks=yes  
--with-qt-dir=/Users/pdv/Developer/public/Trolltech/Qt-5.3.1 
--qt-deployment=yes --with-macosx-target=10.8 --with-sdkroot=10.8 
--with-arch=x86_64 --with-libiconv-prefix=/opt/local --enable-debug

I think the --with-qt-frameworks=yes is needed to include qt as a framework;

and --with-qt-dir=/… points to the dir where the  qt-framework has been 
installed (previously).

I’m not sure about the exact meaning of --qt-deployment=yes  but I think  I 
need it too.

What I don’t understand are the lines 260-262
if [ ${configure_qt_frameworks} != yes ]; then
QtInstallDir=${QTDIR:-/opt/qt4}
fi

with --with-qt-frameworks=yes, QtInstallDir is not set.
 
Therefore I uncomment the if/fi so that
QtInstallDir=${QTDIR:-/opt/qt4”}

is always executed and QtInstallDir points to my qt-install dir.

In addition I must modify some CPPFLAGS= ...

Any idea what I’m doing wrong?

Patrick De Visschere

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Patrick De Visschere]

On 20 Aug, 2014, at 22:40 , Stephan Witt st.w...@gmx.net wrote:

 Am 20.08.2014 um 20:46 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 On 20 Aug, 2014, at 08:40 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 19.08.2014 um 22:41 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 On 19 Aug, 2014, at 14:12 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 17.08.2014 um 20:13 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 On 15 Aug, 2014, at 13:57 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 12.08.2014 um 22:07 schrieb pdv pdvissch...@edpnet.be:
 
 As a follow-up on reports in the thread LyX on OS X 10.9 from some 
 months ago, I build LyX(master) + Qt5(stable) (CMake + XCode).
 
 I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by 
 QProxyStyle and observed then (at least) 2 issues:
 
 1) When starting up the menu bar is not visible; One must switch to 
 another app and then bring lyx to the foreground to make the menu bar 
 appear.
 2) When closing the (last) window the menu bar disappears mostly, 
 except for the LyX menu. This was also reported by Stephan Witt, but I 
 did observe no crash.
 
 When closing the last window Qt5 should switch to the default menu 
 bar but apparently it doesn't find one and creates it's own minimal 
 default menu bar.
 The default menu bar is created by GlobalMenuBar() (in 
 GuiApplication.cpp) which has a constructor GlobalMenuBar() : new 
 QMenuBar(0); according to the Qt docs the first parent-less QMenuBar 
 created will be used as the default menu bar. Apparently Qt5 does not 
 detect the QMenuBar(0) created via a subclass;
 
 When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) is 
 solved.
 
 GlobalMenuBar() was introduced to override the event() function to 
 handle QEvent::ShortcutOverride events but shortcuts seem to work 
 without using the GlobalMenuBar (Cmd-Q and Cmd-, work as expected; 
 Cmd-N and Cmd-O only work after first activating one of them via the 
 menu, but the latter also happens in LyX211 and may not be related to 
 Qt5). Building LyX + Qt4.8.6 confirms that GlobalMenuBar's event() is 
 not called when issuing a shortcut with no window present. I assume 
 that these standard mac-shortcuts are handled automatically by Qt.
 
 If someone wants to check this, see the attached patch, which includes 
 all changes (but does not solve issue 1)).
 
 Patrick De Visschere
 Qt5-fix-Q_WS_MACX+GlobalMenuBar.diff
 
 Hi Patrick,
 
 the GlobalMenuBar() thing is a wonderful idea! I'm struggling since a 
 while with the Qt5 build and failed to solve this issue 2. This I did 
 while being on vacation, so I couldn't answer earlier.
 
 The issue 1 was solved by Benjamin Piwowar already, IMHO. It's caused 
 by Qt5 not showing a menu top item without any action attached. The 
 latest change is the dummy action has to be attached to the sub menu 
 after the addMenu(subMenu) method call.
 
 I’ve used commit 453ce611919ff66d8b00bda9a9dcc32f4d38a843, which does 
 include this dummy action, if I’m not mistaken.
 
 Yes, me too. But this dummy action is added before the addMenu(menu) 
 method call. I've had to move it the addAction call after the addMenu 
 call.
 
 Both issues are regressions of Qt5, IMO.
 
 The QMacStyle doesn't need to be replaced if LyX is linked with the 
 QMacExtras framework.
 
 Regarding the Q_WS_MACX macro replacement I'm not sure what should be 
 done. 
 
 1. I'd prefer to simply replace Q_WS_MACX with Q_OS_MAC which is 
 available since 4.6.x at least.
 2. I'd prefer to replace Q_WS_X11 and Q_WS_WIN with Q_OS_X11 and 
 Q_OS_WIN at the same time but cannot test all platforms.
 
 This results in the attached patch. It contains some additional changes 
 in Menu.cpp I introduced while attacking the issue 2. Furthermore I 
 changed CMakeLists.txt because of some warnings from newer cmake.
 
 This patch should not be commit as is but in some separate steps. 
 Please, if someone can try it or comment on it, I'd like to hear other 
 opinions.
 
 
 With this patch I get basically the same behaviour as I described in my 
 initial message. Without a window being present, Cmd-O and Cmd-N don’t 
 work right away. And the application still starts without the menubar 
 being visible (issue 1), but the shortcuts do work.
 
 Ok, that's not good. 
 
 But on my system the menu bar is visible on startup.
 
 So, I'll give more details regarding my build environment:
 * Mac OS X 10.8.5
 * Darwin Kernel Version 12.5.0
 * Qt 5.3.1 Cocoa built with:
 $ configure -debug-and-release -opensource -silent -shared 
 -confirm-license -no-strip -no-kms -no-pkg-config -nomake examples 
 -nomake tools -skip qtquick1 -skip qtwebkit -skip qtconnectivity -skip 
 qtquickcontrols -skip qtdeclarative -skip qtscript -arch x86_64 -prefix 
 /Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64
 
 With autotools I build with
 * gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 
 2336.11.00)
 
 With cmake I build with 
 * AppleClang 5.1.0.5030040 (Apple

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Patrick De Visschere]

On 20 Aug, 2014, at 08:40 , Stephan Witt <st.w...@gmx.net> wrote:

> Am 19.08.2014 um 22:41 schrieb Patrick De Visschere <pdvissch...@edpnet.be>:
> 
>> 
>> On 19 Aug, 2014, at 14:12 , Stephan Witt <st.w...@gmx.net> wrote:
>> 
>>> Am 17.08.2014 um 20:13 schrieb Patrick De Visschere <pdvissch...@edpnet.be>:
>>> 
>>>> On 15 Aug, 2014, at 13:57 , Stephan Witt <st.w...@gmx.net> wrote:
>>>> 
>>>>> Am 12.08.2014 um 22:07 schrieb pdv <pdvissch...@edpnet.be>:
>>>>> 
>>>>>> As a follow-up on reports in the thread "LyX on OS X 10.9" from some 
>>>>>> months ago, I build LyX(master) + Qt5(stable) (CMake + XCode).
>>>>>> 
>>>>>> I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by QProxyStyle 
>>>>>> and observed then (at least) 2 issues:
>>>>>> 
>>>>>> 1) When starting up the menu bar is not visible; One must switch to 
>>>>>> another app and then bring lyx to the foreground to make the menu bar 
>>>>>> appear.
>>>>>> 2) When closing the (last) window the menu bar disappears mostly, except 
>>>>>> for the LyX menu. This was also reported by Stephan Witt, but I did 
>>>>>> observe no crash.
>>>>>> 
>>>>>> When closing the last window Qt5 should switch to the "default menu bar" 
>>>>>> but apparently it doesn't find one and creates it's own minimal default 
>>>>>> menu bar.
>>>>>> The default menu bar is created by GlobalMenuBar() (in 
>>>>>> GuiApplication.cpp) which has a constructor GlobalMenuBar() : new 
>>>>>> QMenuBar(0); according to the Qt docs the first parent-less QMenuBar 
>>>>>> created will be used as the default menu bar. Apparently Qt5 does not 
>>>>>> detect the QMenuBar(0) created via a subclass;
>>>>>> 
>>>>>> When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) is 
>>>>>> solved.
>>>>>> 
>>>>>> GlobalMenuBar() was introduced to override the event() function to 
>>>>>> handle QEvent::ShortcutOverride events but shortcuts seem to work 
>>>>>> without using the GlobalMenuBar (Cmd-Q and Cmd-, work as expected; Cmd-N 
>>>>>> and Cmd-O only work after first activating one of them via the menu, but 
>>>>>> the latter also happens in LyX211 and may not be related to Qt5). 
>>>>>> Building LyX + Qt4.8.6 confirms that GlobalMenuBar's event() is not 
>>>>>> called when issuing a shortcut with no window present. I assume that 
>>>>>> these standard mac-shortcuts are handled automatically by Qt.
>>>>>> 
>>>>>> If someone wants to check this, see the attached patch, which includes 
>>>>>> all changes (but does not solve issue 1)).
>>>>>> 
>>>>>> Patrick De Visschere
>>>>>> <Qt5-fix-Q_WS_MACX+GlobalMenuBar.diff>
>>>>> 
>>>>> Hi Patrick,
>>>>> 
>>>>> the GlobalMenuBar() thing is a wonderful idea! I'm struggling since a 
>>>>> while with the Qt5 build and failed to solve this issue 2. This I did 
>>>>> while being on vacation, so I couldn't answer earlier.
>>>>> 
>>>>> The issue 1 was solved by Benjamin Piwowar already, IMHO. It's caused by 
>>>>> Qt5 not showing a menu top item without any action attached. The latest 
>>>>> change is the dummy action has to be attached to the sub menu after the 
>>>>> addMenu(subMenu) method call.
>>>> 
>>>> I’ve used commit 453ce611919ff66d8b00bda9a9dcc32f4d38a843, which does 
>>>> include this dummy action, if I’m not mistaken.
>>> 
>>> Yes, me too. But this dummy action is added before the addMenu(menu) method 
>>> call. I've had to move it the addAction call after the addMenu call.
>>> 
>>>>> Both issues are regressions of Qt5, IMO.
>>>>> 
>>>>> The QMacStyle doesn't need to be replaced if LyX is linked with the 
>>>>> QMacExtras framework.
>>>>> 
>>>>> Regarding the Q_WS_MACX macro replacement I'm not sure what should be 
>>>>> done. 
>>>>> 
>>>>> 1. I'd prefer to simply replace Q_WS_MACX with Q_OS_MAC which is 
>>>>> availa

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Patrick De Visschere]

On 20 Aug, 2014, at 11:22 , Stephan Witt <st.w...@gmx.net> wrote:

> Am 19.08.2014 um 22:41 schrieb Patrick De Visschere <pdvissch...@edpnet.be>:
> 
>> On 19 Aug, 2014, at 14:12 , Stephan Witt <st.w...@gmx.net> wrote:
>> 
>>> Am 17.08.2014 um 20:13 schrieb Patrick De Visschere <pdvissch...@edpnet.be>:
>> 
>> My environment
>> 
>> * Mac OS X 10.9.4
>> * Darwin Kernel Version 13.3.0
>> * Qt 5.3.1 (stable branch) (default Cocoa)
>> ./configure -opensource -silent -shared -release -no-dbus -nomake examples 
>> -nomake tools -no-framework
> 
> You don't build the libraries as frameworks. I'm not sure if this makes no 
> difference.
> 
> I'm using the Qt frameworks I've build myself.
> 
> Stephan

Stephan,

I was planning to do that. (the qt-debug build does not make a difference as 
you expected)

I suppose you use the LyX-Mac-binary-release.sh script.

I have never managed to use this script without making changes to it, perhaps 
because I’m using it the wrong way.

I build qt as a framework separately and would then use the script like:

sh development/LyX-Mac-binary-release.sh  --with-qt-frameworks=yes  
--with-qt-dir=/Users/pdv/Developer/public/Trolltech/Qt-5.3.1 
--qt-deployment=yes --with-macosx-target=10.8 --with-sdkroot=10.8 
--with-arch=x86_64 --with-libiconv-prefix=/opt/local --enable-debug

I think the --with-qt-frameworks=yes is needed to include qt as a framework;

and --with-qt-dir=/… points to the dir where the  qt-framework has been 
installed (previously).

I’m not sure about the exact meaning of --qt-deployment=yes  but I think  I 
need it too.

What I don’t understand are the lines 260-262
if [ "${configure_qt_frameworks}" != "yes" ]; then
QtInstallDir=${QTDIR:-"/opt/qt4"}
fi

with --with-qt-frameworks=yes, QtInstallDir is not set.
 
Therefore I uncomment the if/fi so that
QtInstallDir=${QTDIR:-"/opt/qt4”}

is always executed and QtInstallDir points to my qt-install dir.

In addition I must modify some CPPFLAGS= ...

Any idea what I’m doing wrong?

Patrick De Visschere

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Patrick De Visschere]

On 20 Aug, 2014, at 22:40 , Stephan Witt <st.w...@gmx.net> wrote:

> Am 20.08.2014 um 20:46 schrieb Patrick De Visschere <pdvissch...@edpnet.be>:
> 
>> On 20 Aug, 2014, at 08:40 , Stephan Witt <st.w...@gmx.net> wrote:
>> 
>>> Am 19.08.2014 um 22:41 schrieb Patrick De Visschere <pdvissch...@edpnet.be>:
>>> 
>>>> On 19 Aug, 2014, at 14:12 , Stephan Witt <st.w...@gmx.net> wrote:
>>>> 
>>>>> Am 17.08.2014 um 20:13 schrieb Patrick De Visschere 
>>>>> <pdvissch...@edpnet.be>:
>>>>> 
>>>>>> On 15 Aug, 2014, at 13:57 , Stephan Witt <st.w...@gmx.net> wrote:
>>>>>> 
>>>>>>> Am 12.08.2014 um 22:07 schrieb pdv <pdvissch...@edpnet.be>:
>>>>>>> 
>>>>>>>> As a follow-up on reports in the thread "LyX on OS X 10.9" from some 
>>>>>>>> months ago, I build LyX(master) + Qt5(stable) (CMake + XCode).
>>>>>>>> 
>>>>>>>> I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by 
>>>>>>>> QProxyStyle and observed then (at least) 2 issues:
>>>>>>>> 
>>>>>>>> 1) When starting up the menu bar is not visible; One must switch to 
>>>>>>>> another app and then bring lyx to the foreground to make the menu bar 
>>>>>>>> appear.
>>>>>>>> 2) When closing the (last) window the menu bar disappears mostly, 
>>>>>>>> except for the LyX menu. This was also reported by Stephan Witt, but I 
>>>>>>>> did observe no crash.
>>>>>>>> 
>>>>>>>> When closing the last window Qt5 should switch to the "default menu 
>>>>>>>> bar" but apparently it doesn't find one and creates it's own minimal 
>>>>>>>> default menu bar.
>>>>>>>> The default menu bar is created by GlobalMenuBar() (in 
>>>>>>>> GuiApplication.cpp) which has a constructor GlobalMenuBar() : new 
>>>>>>>> QMenuBar(0); according to the Qt docs the first parent-less QMenuBar 
>>>>>>>> created will be used as the default menu bar. Apparently Qt5 does not 
>>>>>>>> detect the QMenuBar(0) created via a subclass;
>>>>>>>> 
>>>>>>>> When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) is 
>>>>>>>> solved.
>>>>>>>> 
>>>>>>>> GlobalMenuBar() was introduced to override the event() function to 
>>>>>>>> handle QEvent::ShortcutOverride events but shortcuts seem to work 
>>>>>>>> without using the GlobalMenuBar (Cmd-Q and Cmd-, work as expected; 
>>>>>>>> Cmd-N and Cmd-O only work after first activating one of them via the 
>>>>>>>> menu, but the latter also happens in LyX211 and may not be related to 
>>>>>>>> Qt5). Building LyX + Qt4.8.6 confirms that GlobalMenuBar's event() is 
>>>>>>>> not called when issuing a shortcut with no window present. I assume 
>>>>>>>> that these standard mac-shortcuts are handled automatically by Qt.
>>>>>>>> 
>>>>>>>> If someone wants to check this, see the attached patch, which includes 
>>>>>>>> all changes (but does not solve issue 1)).
>>>>>>>> 
>>>>>>>> Patrick De Visschere
>>>>>>>> <Qt5-fix-Q_WS_MACX+GlobalMenuBar.diff>
>>>>>>> 
>>>>>>> Hi Patrick,
>>>>>>> 
>>>>>>> the GlobalMenuBar() thing is a wonderful idea! I'm struggling since a 
>>>>>>> while with the Qt5 build and failed to solve this issue 2. This I did 
>>>>>>> while being on vacation, so I couldn't answer earlier.
>>>>>>> 
>>>>>>> The issue 1 was solved by Benjamin Piwowar already, IMHO. It's caused 
>>>>>>> by Qt5 not showing a menu top item without any action attached. The 
>>>>>>> latest change is the dummy action has to be attached to the sub menu 
>>>>>>> after the addMenu(subMenu) method call.
>>>>>> 
>>>>>> I’ve used commit 453ce611919ff66d8b00bda9a9dcc32f4d38a843, which does 
>>>>>> include this dummy action, if I’m not mistaken.

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Patrick De Visschere]

On 19 Aug, 2014, at 14:12 , Stephan Witt st.w...@gmx.net wrote:

 Am 17.08.2014 um 20:13 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 On 15 Aug, 2014, at 13:57 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 12.08.2014 um 22:07 schrieb pdv pdvissch...@edpnet.be:
 
 As a follow-up on reports in the thread LyX on OS X 10.9 from some 
 months ago, I build LyX(master) + Qt5(stable) (CMake + XCode).
 
 I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by QProxyStyle 
 and observed then (at least) 2 issues:
 
 1) When starting up the menu bar is not visible; One must switch to 
 another app and then bring lyx to the foreground to make the menu bar 
 appear.
 2) When closing the (last) window the menu bar disappears mostly, except 
 for the LyX menu. This was also reported by Stephan Witt, but I did 
 observe no crash.
 
 When closing the last window Qt5 should switch to the default menu bar 
 but apparently it doesn't find one and creates it's own minimal default 
 menu bar.
 The default menu bar is created by GlobalMenuBar() (in GuiApplication.cpp) 
 which has a constructor GlobalMenuBar() : new QMenuBar(0); according to 
 the Qt docs the first parent-less QMenuBar created will be used as the 
 default menu bar. Apparently Qt5 does not detect the QMenuBar(0) created 
 via a subclass;
 
 When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) is 
 solved.
 
 GlobalMenuBar() was introduced to override the event() function to handle 
 QEvent::ShortcutOverride events but shortcuts seem to work without using 
 the GlobalMenuBar (Cmd-Q and Cmd-, work as expected; Cmd-N and Cmd-O only 
 work after first activating one of them via the menu, but the latter also 
 happens in LyX211 and may not be related to Qt5). Building LyX + Qt4.8.6 
 confirms that GlobalMenuBar's event() is not called when issuing a 
 shortcut with no window present. I assume that these standard 
 mac-shortcuts are handled automatically by Qt.
 
 If someone wants to check this, see the attached patch, which includes all 
 changes (but does not solve issue 1)).
 
 Patrick De Visschere
 Qt5-fix-Q_WS_MACX+GlobalMenuBar.diff
 
 Hi Patrick,
 
 the GlobalMenuBar() thing is a wonderful idea! I'm struggling since a while 
 with the Qt5 build and failed to solve this issue 2. This I did while being 
 on vacation, so I couldn't answer earlier.
 
 The issue 1 was solved by Benjamin Piwowar already, IMHO. It's caused by 
 Qt5 not showing a menu top item without any action attached. The latest 
 change is the dummy action has to be attached to the sub menu after the 
 addMenu(subMenu) method call.
 
 I’ve used commit 453ce611919ff66d8b00bda9a9dcc32f4d38a843, which does 
 include this dummy action, if I’m not mistaken.
 
 Yes, me too. But this dummy action is added before the addMenu(menu) method 
 call. I've had to move it the addAction call after the addMenu call.
 
 Both issues are regressions of Qt5, IMO.
 
 The QMacStyle doesn't need to be replaced if LyX is linked with the 
 QMacExtras framework.
 
 Regarding the Q_WS_MACX macro replacement I'm not sure what should be done. 
 
 1. I'd prefer to simply replace Q_WS_MACX with Q_OS_MAC which is available 
 since 4.6.x at least.
 2. I'd prefer to replace Q_WS_X11 and Q_WS_WIN with Q_OS_X11 and Q_OS_WIN 
 at the same time but cannot test all platforms.
 
 This results in the attached patch. It contains some additional changes in 
 Menu.cpp I introduced while attacking the issue 2. Furthermore I changed 
 CMakeLists.txt because of some warnings from newer cmake.
 
 This patch should not be commit as is but in some separate steps. Please, 
 if someone can try it or comment on it, I'd like to hear other opinions.
 
 
 With this patch I get basically the same behaviour as I described in my 
 initial message. Without a window being present, Cmd-O and Cmd-N don’t work 
 right away. And the application still starts without the menubar being 
 visible (issue 1), but the shortcuts do work.
 
 Ok, that's not good. 
 
 But on my system the menu bar is visible on startup.
 
 So, I'll give more details regarding my build environment:
 * Mac OS X 10.8.5
 * Darwin Kernel Version 12.5.0
 * Qt 5.3.1 Cocoa built with:
 $ configure -debug-and-release -opensource -silent -shared -confirm-license 
 -no-strip -no-kms -no-pkg-config -nomake examples -nomake tools -skip 
 qtquick1 -skip qtwebkit -skip qtconnectivity -skip qtquickcontrols -skip 
 qtdeclarative -skip qtscript -arch x86_64 -prefix 
 /Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64
 
 With autotools I build with
 * gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
 
 With cmake I build with 
 * AppleClang 5.1.0.5030040 (Apple LLVM 5.1)
 
 The LyX package I made on a Mac 10.6.8 works like the package build on 10.8.5.

My environment

* Mac OS X 10.9.4
* Darwin Kernel Version 13.3.0
* Qt 5.3.1 (stable branch) (default Cocoa)
./configure -opensource -silent -shared -release -no-dbus -nomake examples 
-nomake tools

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Patrick De Visschere]

On 19 Aug, 2014, at 14:12 , Stephan Witt <st.w...@gmx.net> wrote:

> Am 17.08.2014 um 20:13 schrieb Patrick De Visschere <pdvissch...@edpnet.be>:
> 
>> On 15 Aug, 2014, at 13:57 , Stephan Witt <st.w...@gmx.net> wrote:
>> 
>>> Am 12.08.2014 um 22:07 schrieb pdv <pdvissch...@edpnet.be>:
>>> 
>>>> As a follow-up on reports in the thread "LyX on OS X 10.9" from some 
>>>> months ago, I build LyX(master) + Qt5(stable) (CMake + XCode).
>>>> 
>>>> I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by QProxyStyle 
>>>> and observed then (at least) 2 issues:
>>>> 
>>>> 1) When starting up the menu bar is not visible; One must switch to 
>>>> another app and then bring lyx to the foreground to make the menu bar 
>>>> appear.
>>>> 2) When closing the (last) window the menu bar disappears mostly, except 
>>>> for the LyX menu. This was also reported by Stephan Witt, but I did 
>>>> observe no crash.
>>>> 
>>>> When closing the last window Qt5 should switch to the "default menu bar" 
>>>> but apparently it doesn't find one and creates it's own minimal default 
>>>> menu bar.
>>>> The default menu bar is created by GlobalMenuBar() (in GuiApplication.cpp) 
>>>> which has a constructor GlobalMenuBar() : new QMenuBar(0); according to 
>>>> the Qt docs the first parent-less QMenuBar created will be used as the 
>>>> default menu bar. Apparently Qt5 does not detect the QMenuBar(0) created 
>>>> via a subclass;
>>>> 
>>>> When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) is 
>>>> solved.
>>>> 
>>>> GlobalMenuBar() was introduced to override the event() function to handle 
>>>> QEvent::ShortcutOverride events but shortcuts seem to work without using 
>>>> the GlobalMenuBar (Cmd-Q and Cmd-, work as expected; Cmd-N and Cmd-O only 
>>>> work after first activating one of them via the menu, but the latter also 
>>>> happens in LyX211 and may not be related to Qt5). Building LyX + Qt4.8.6 
>>>> confirms that GlobalMenuBar's event() is not called when issuing a 
>>>> shortcut with no window present. I assume that these standard 
>>>> mac-shortcuts are handled automatically by Qt.
>>>> 
>>>> If someone wants to check this, see the attached patch, which includes all 
>>>> changes (but does not solve issue 1)).
>>>> 
>>>> Patrick De Visschere
>>>> <Qt5-fix-Q_WS_MACX+GlobalMenuBar.diff>
>>> 
>>> Hi Patrick,
>>> 
>>> the GlobalMenuBar() thing is a wonderful idea! I'm struggling since a while 
>>> with the Qt5 build and failed to solve this issue 2. This I did while being 
>>> on vacation, so I couldn't answer earlier.
>>> 
>>> The issue 1 was solved by Benjamin Piwowar already, IMHO. It's caused by 
>>> Qt5 not showing a menu top item without any action attached. The latest 
>>> change is the dummy action has to be attached to the sub menu after the 
>>> addMenu(subMenu) method call.
>> 
>> I’ve used commit 453ce611919ff66d8b00bda9a9dcc32f4d38a843, which does 
>> include this dummy action, if I’m not mistaken.
> 
> Yes, me too. But this dummy action is added before the addMenu(menu) method 
> call. I've had to move it the addAction call after the addMenu call.
> 
>>> Both issues are regressions of Qt5, IMO.
>>> 
>>> The QMacStyle doesn't need to be replaced if LyX is linked with the 
>>> QMacExtras framework.
>>> 
>>> Regarding the Q_WS_MACX macro replacement I'm not sure what should be done. 
>>> 
>>> 1. I'd prefer to simply replace Q_WS_MACX with Q_OS_MAC which is available 
>>> since 4.6.x at least.
>>> 2. I'd prefer to replace Q_WS_X11 and Q_WS_WIN with Q_OS_X11 and Q_OS_WIN 
>>> at the same time but cannot test all platforms.
>>> 
>>> This results in the attached patch. It contains some additional changes in 
>>> Menu.cpp I introduced while attacking the issue 2. Furthermore I changed 
>>> CMakeLists.txt because of some warnings from newer cmake.
>>> 
>>> This patch should not be commit as is but in some separate steps. Please, 
>>> if someone can try it or comment on it, I'd like to hear other opinions.
>>> 
>> 
>> With this patch I get basically the same behaviour as I described in my 
>> initial message. Without a window being present, Cmd

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Patrick De Visschere]

On 15 Aug, 2014, at 13:57 , Stephan Witt st.w...@gmx.net wrote:

 Am 12.08.2014 um 22:07 schrieb pdv pdvissch...@edpnet.be:
 
 As a follow-up on reports in the thread LyX on OS X 10.9 from some months 
 ago, I build LyX(master) + Qt5(stable) (CMake + XCode).
 
 I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by QProxyStyle and 
 observed then (at least) 2 issues:
 
 1) When starting up the menu bar is not visible; One must switch to another 
 app and then bring lyx to the foreground to make the menu bar appear.
 2) When closing the (last) window the menu bar disappears mostly, except for 
 the LyX menu. This was also reported by Stephan Witt, but I did observe no 
 crash.
 
 When closing the last window Qt5 should switch to the default menu bar but 
 apparently it doesn't find one and creates it's own minimal default menu bar.
 The default menu bar is created by GlobalMenuBar() (in GuiApplication.cpp) 
 which has a constructor GlobalMenuBar() : new QMenuBar(0); according to the 
 Qt docs the first parent-less QMenuBar created will be used as the default 
 menu bar. Apparently Qt5 does not detect the QMenuBar(0) created via a 
 subclass;
 
 When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) is 
 solved.
 
 GlobalMenuBar() was introduced to override the event() function to handle 
 QEvent::ShortcutOverride events but shortcuts seem to work without using the 
 GlobalMenuBar (Cmd-Q and Cmd-, work as expected; Cmd-N and Cmd-O only work 
 after first activating one of them via the menu, but the latter also happens 
 in LyX211 and may not be related to Qt5). Building LyX + Qt4.8.6 confirms 
 that GlobalMenuBar's event() is not called when issuing a shortcut with no 
 window present. I assume that these standard mac-shortcuts are handled 
 automatically by Qt.
 
 If someone wants to check this, see the attached patch, which includes all 
 changes (but does not solve issue 1)).
 
 Patrick De Visschere
 Qt5-fix-Q_WS_MACX+GlobalMenuBar.diff
 
 Hi Patrick,
 
 the GlobalMenuBar() thing is a wonderful idea! I'm struggling since a while 
 with the Qt5 build and failed to solve this issue 2. This I did while being 
 on vacation, so I couldn't answer earlier.
 
 The issue 1 was solved by Benjamin Piwowar already, IMHO. It's caused by Qt5 
 not showing a menu top item without any action attached. The latest change is 
 the dummy action has to be attached to the sub menu after the 
 addMenu(subMenu) method call.

I’ve used commit 453ce611919ff66d8b00bda9a9dcc32f4d38a843, which does include 
this dummy action, if I’m not mistaken.

 
 Both issues are regressions of Qt5, IMO.
 
 The QMacStyle doesn't need to be replaced if LyX is linked with the 
 QMacExtras framework.
 
 Regarding the Q_WS_MACX macro replacement I'm not sure what should be done. 
 
 1. I'd prefer to simply replace Q_WS_MACX with Q_OS_MAC which is available 
 since 4.6.x at least.
 2. I'd prefer to replace Q_WS_X11 and Q_WS_WIN with Q_OS_X11 and Q_OS_WIN at 
 the same time but cannot test all platforms.
 
 This results in the attached patch. It contains some additional changes in 
 Menu.cpp I introduced while attacking the issue 2. Furthermore I changed 
 CMakeLists.txt because of some warnings from newer cmake.
 
 This patch should not be commit as is but in some separate steps. Please, if 
 someone can try it or comment on it, I'd like to hear other opinions.
 

With this patch I get basically the same behaviour as I described in my initial 
message. Without a window being present, Cmd-O and Cmd-N don’t work right away. 
And the application still starts without the menubar being visible (issue 1), 
but the shortcuts do work.

Patrick De Visschere

 Stephan
 
 2014-08-15-Qt5.patch

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Patrick De Visschere]

On 15 Aug, 2014, at 13:57 , Stephan Witt <st.w...@gmx.net> wrote:

> Am 12.08.2014 um 22:07 schrieb pdv <pdvissch...@edpnet.be>:
> 
>> As a follow-up on reports in the thread "LyX on OS X 10.9" from some months 
>> ago, I build LyX(master) + Qt5(stable) (CMake + XCode).
>> 
>> I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by QProxyStyle and 
>> observed then (at least) 2 issues:
>> 
>> 1) When starting up the menu bar is not visible; One must switch to another 
>> app and then bring lyx to the foreground to make the menu bar appear.
>> 2) When closing the (last) window the menu bar disappears mostly, except for 
>> the LyX menu. This was also reported by Stephan Witt, but I did observe no 
>> crash.
>> 
>> When closing the last window Qt5 should switch to the "default menu bar" but 
>> apparently it doesn't find one and creates it's own minimal default menu bar.
>> The default menu bar is created by GlobalMenuBar() (in GuiApplication.cpp) 
>> which has a constructor GlobalMenuBar() : new QMenuBar(0); according to the 
>> Qt docs the first parent-less QMenuBar created will be used as the default 
>> menu bar. Apparently Qt5 does not detect the QMenuBar(0) created via a 
>> subclass;
>> 
>> When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) is 
>> solved.
>> 
>> GlobalMenuBar() was introduced to override the event() function to handle 
>> QEvent::ShortcutOverride events but shortcuts seem to work without using the 
>> GlobalMenuBar (Cmd-Q and Cmd-, work as expected; Cmd-N and Cmd-O only work 
>> after first activating one of them via the menu, but the latter also happens 
>> in LyX211 and may not be related to Qt5). Building LyX + Qt4.8.6 confirms 
>> that GlobalMenuBar's event() is not called when issuing a shortcut with no 
>> window present. I assume that these standard mac-shortcuts are handled 
>> automatically by Qt.
>> 
>> If someone wants to check this, see the attached patch, which includes all 
>> changes (but does not solve issue 1)).
>> 
>> Patrick De Visschere
>> <Qt5-fix-Q_WS_MACX+GlobalMenuBar.diff>
> 
> Hi Patrick,
> 
> the GlobalMenuBar() thing is a wonderful idea! I'm struggling since a while 
> with the Qt5 build and failed to solve this issue 2. This I did while being 
> on vacation, so I couldn't answer earlier.
> 
> The issue 1 was solved by Benjamin Piwowar already, IMHO. It's caused by Qt5 
> not showing a menu top item without any action attached. The latest change is 
> the dummy action has to be attached to the sub menu after the 
> addMenu(subMenu) method call.

I’ve used commit 453ce611919ff66d8b00bda9a9dcc32f4d38a843, which does include 
this dummy action, if I’m not mistaken.

> 
> Both issues are regressions of Qt5, IMO.
> 
> The QMacStyle doesn't need to be replaced if LyX is linked with the 
> QMacExtras framework.
> 
> Regarding the Q_WS_MACX macro replacement I'm not sure what should be done. 
> 
> 1. I'd prefer to simply replace Q_WS_MACX with Q_OS_MAC which is available 
> since 4.6.x at least.
> 2. I'd prefer to replace Q_WS_X11 and Q_WS_WIN with Q_OS_X11 and Q_OS_WIN at 
> the same time but cannot test all platforms.
> 
> This results in the attached patch. It contains some additional changes in 
> Menu.cpp I introduced while attacking the issue 2. Furthermore I changed 
> CMakeLists.txt because of some warnings from newer cmake.
> 
> This patch should not be commit as is but in some separate steps. Please, if 
> someone can try it or comment on it, I'd like to hear other opinions.
> 

With this patch I get basically the same behaviour as I described in my initial 
message. Without a window being present, Cmd-O and Cmd-N don’t work right away. 
And the application still starts without the menubar being visible (issue 1), 
but the shortcuts do work.

Patrick De Visschere

> Stephan
> 
> <2014-08-15-Qt5.patch>