Am 02.03.2014 um 09:16 schrieb Benjamin Piwowarski <benjamin.piwowar...@gmail.com>:
> Stephan, > > The qt4 build is working fine on OS X 10.9 (did some basic checks). No > problems with menus, no crash.The qt5 has still troubles with menus (when > closing the main window, they completely disappear) but otherwise seems to > work fine - but it does not crash. Stephan, could you try to disable the > special menu handling to check if it still crashes? This is a really good message. We have the opportunity to stick with 4.8.5 then. Regarding the crashes with menus I'd review the latest changes from branch. These should improve the situation. I'm talking of the following commits: 5a5d6a524ca8335149f394824bcdc307f70ebfc7 535c9ea0783864ae9f0c5593b39b37764bd59821 00a7f002dbef8cefdeda07aa92761887024d6ed3 I'll attach my current diff improving your patches to make LyX ready for using Qt5 frameworks. I had to take care for missing QPA modules in Qt-5.0 and Qt-5.1 and added to auto tools support. If no one objects I'll commit this as it works with 4.8.5. The menu issues can be solved in a next step. Another step is the review of the patch1 and patch2 from the first mail of this thread. Stephan > > Benjamin > > On 01 Mar 2014, at 22:06 , Stephan Witt <st.w...@gmx.net> wrote: > >> Am 01.03.2014 um 20:34 schrieb Stephan Witt <st.w...@gmx.net>: >> >>> Am 28.02.2014 um 23:01 schrieb Georg Baum <georg.b...@post.rwth-aachen.de>: >>> >>>> Benjamin Piwowarski wrote: >>>> >>>>> Hi Georg, >>>>> >>>>> here are some comments/answers on your questions: >>>>> >>>>> On 27 Feb 2014, at 22:36 , Georg Baum <georg.b...@post.rwth-aachen.de> >>>>> wrote: >>>>> >>>>>> >>>>>> We do not use C-style casts. Could you please rewrite this, e.g. like >>>>>> >>>>>> bool const success = (os << contents) ? true : false; >>>>>> >>>>>> and add comments why it is needed? I could do that, but I can't test >>>>>> whether it still fixes your problem, and the chance is extremely high >>>>>> that I would break something. >>>>> I am unsure the above solution would work, since in libc++ the conversion >>>>> to bool() is marked as explicit - you have to either use the constuct >>>>> bool(x) or (bool)x. Alternatively, we could also use bool const success = >>>>> !(os << contents).failed() >>>> >>>> Thanks for the updated patch (I got it privately). Before applying, I just >>>> want to reassure myself that this is always 100% equivalent. >>>> >>>>>> I can't comment on the cmake part, but the C++ changes look good. To our >>>>>> Mac expperts: Is there any reason why they are not already in? >>>>> I guess this is because since QT_WS_MACX was not defined anymore in QT5, >>>>> the mac specific parts were not compiled anymore and hence did not trigger >>>>> any problem. >>>> >>>> I researched a bit, and there are indeed subtle differences: Q_OS_MACX is >>>> also provided on the oldest qt release supported by LyX (4.5.0). However, >>>> with qt 4.x, Q_OS_MACX is not equivalent to Q_WS_MACX: If you build for >>>> X11 >>>> you get Q_WS_X11 and Q_OS_MACX. >>>> >>>> BTW, the other macros we use (Q_WS_WIN and Q_WS_X11) have no direct Q_OS >>>> equivalent either, but they need to be changed as well in qt5. I don't >>>> know >>>> where to go from here. AFAIK Vincent did compile already for windows with >>>> qt5. Why did that work without the changed macros? Also, the qt sources >>>> themselves still use the Q_WS macros, although I could not find any place >>>> where they are defined. Is that simply broken code? I can't believe. >>>> Should >>>> we define our own and not use the QT ones? >>>> >>>>> Yes, it sets and unsets environment variables. I cannot judge for the >>>>> fallback on the old code since I coded the tests for graceful error >>>>> handling and in the same time the workaround. The bug is reported over >>>>> there (for mac): https://trac.macports.org/ticket/38771 (see comment 9 >>>>> about the locale fix) and there (it is related to the error code of the >>>>> regex library) >>>>> http://osdir.com/ml/package-management.rpm.devel/2008-02/msg00121.html >>>>> >>>>> it seems to affect only mac os though. I can modify the patch if needed to >>>>> remove the workaround, since otherwise LyX crashes. >>>> >>>> Thanks for the additional info. I submitted a slightly different version >>>> without the locale stuff. I am a bit reluctant to put this in, since it is >>>> a >>>> platform specific workaround, and I want to avoid side effects on other >>>> platforms. What do others think? >>>> >>>> Concerning the fallback I can assure you that it is fine for most formats >>>> (and always used on windows). Using libmagic is more a long term project >>>> to >>>> get rid of it. >>>> >>>>>>> With all this, I was able to have a "working" LyX application (that is, >>>>>>> everything seems to work but the menu - known OS X bug) >>>>>> >>>>>> Is it this one: http://www.lyx.org/trac/ticket/8925 >>>>>> >>>>> yes >>>>> >>>>>> Do you have any pointers to documentation about this bug? >>>>> no idea - I am quite unfamiliar with QT so it would take some time. I >>>>> started though to debug the menu generation in LyX to understand how it is >>>>> expected to work, but did not get far yet. >>>> >>>> Many thanks for the patch in trac. I hope Stephan can test it and comment. >>> >>> I'm at it now. Many thanks for the investigation Benjamin. >>> >>> I've applied these patches: >>> >>> 0003-Qt5-support-for-Mac.patch >>> 0001-Fix-bug-8925-menubar-not-displayed-in-Mac-OS-10.9.2.patch >>> >>> First I tried these patches with cmake + Xcode - this worked with 4.8.5. >>> Then I tried auto tools build with 4.8.5 and it works. >>> The build with 5.1 failed because of missing QMacPasteboardMime header. >>> The build with 5.2 succeeded after modifying config/qt4.m4. I had to >>> add the QtMacExtras framework. >>> >>> Thanks to Benjamin's patches the menu bar is shown completely now. >>> But when closing the main window it disappears and I get a crash on exit. >>> >>> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread >>> 0 libsystem_kernel.dylib 0x00007fff91be1212 __pthread_kill + 10 >>> 1 libsystem_c.dylib 0x00007fff903c0b24 pthread_kill + 90 >>> 2 libsystem_c.dylib 0x00007fff90404f61 abort + 143 >>> 3 org.lyx.lyx 0x00000001000eb469 0x100000000 + 963689 >>> 4 libsystem_c.dylib 0x00007fff903ad90a _sigtramp + 26 >>> 5 libobjc.A.dylib 0x00007fff8e8b8510 objc_msgSend_vtable5 >>> + 16 >>> 6 com.apple.AppKit 0x00007fff8ef3519d -[NSMenu >>> _enableItem:] + 650 >>> 7 com.apple.AppKit 0x00007fff8ef92e92 -[NSCarbonMenuImpl >>> _carbonUpdateStatusEvent:handlerCallRef:] + 512 >>> 8 com.apple.AppKit 0x00007fff8ef8f165 >>> NSSLMMenuEventHandler + 342 >>> 9 com.apple.HIToolbox 0x00007fff90de3d1a >>> DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) >>> + 1206 >>> 10 com.apple.HIToolbox 0x00007fff90de31e9 >>> SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, >>> HandlerCallRec*) + 410 >>> 11 com.apple.HIToolbox 0x00007fff90df8fc9 >>> SendEventToEventTarget + 40 >>> 12 com.apple.HIToolbox 0x00007fff90e2fca9 >>> SendHICommandEvent(unsigned int, HICommand const*, unsigned int, unsigned >>> int, unsigned char, void const*, OpaqueEventTargetRef*, >>> OpaqueEventTargetRef*, OpaqueEventRef**) + 443 >>> 13 com.apple.HIToolbox 0x00007fff90e2fae8 >>> UpdateHICommandStatus + 62 >>> 14 com.apple.HIToolbox 0x00007fff90e2f999 >>> EnableMenu(MenuData*, OpaqueEventTargetRef*, unsigned short, unsigned char, >>> CheckMenuData*, unsigned int, double) + 86 >>> 15 com.apple.HIToolbox 0x00007fff90e2c76e >>> Check1MenuForKeyEvent(MenuData*, CheckMenuData*) + 2049 >>> 16 com.apple.HIToolbox 0x00007fff90e2b937 >>> CheckMenusForKeyEvent(MenuData*, CheckMenuData*) + 904 >>> 17 com.apple.HIToolbox 0x00007fff90e2b523 >>> _IsMenuKeyEvent(MenuData*, OpaqueEventRef*, unsigned int, MenuData**, >>> unsigned short*) + 697 >>> 18 com.apple.HIToolbox 0x00007fff90e2b239 IsMenuKeyEvent + 120 >>> 19 com.apple.AppKit 0x00007fff8ef8ef2c -[NSCarbonMenuImpl >>> _menuItemWithKeyEquivalentMatchingEventRef:] + 295 >>> 20 com.apple.AppKit 0x00007fff8ef8ece8 >>> _NSFindMenuItemMatchingCommandKeyEvent + 336 >>> 21 com.apple.AppKit 0x00007fff8ee4e978 >>> _NSHandleCarbonMenuEvent + 423 >>> 22 com.apple.AppKit 0x00007fff8ed70a9f _DPSNextEvent + 2073 >>> 23 com.apple.AppKit 0x00007fff8ed6fdf2 -[NSApplication >>> nextEventMatchingMask:untilDate:inMode:dequeue:] + 128 >>> 24 com.apple.AppKit 0x00007fff8ed671a3 -[NSApplication run] >>> + 517 >>> 25 libqcocoa.dylib 0x0000000103f19ab4 >>> QCocoaEventDispatcher::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) >>> + 2404 >>> 26 QtCore 0x000000010115da7e >>> QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 398 >>> 27 QtCore 0x0000000101160922 >>> QCoreApplication::exec() + 354 >>> 28 org.lyx.lyx 0x00000001000ef6f8 0x100000000 + 980728 >>> 29 org.lyx.lyx 0x00000001000019a2 0x100000000 + 6562 >>> 30 org.lyx.lyx 0x0000000100001954 0x100000000 + 6484 >>> >>> The crash doesn't happen with Qt4.8.5. >>> >>> To summarize it: >>> - Qt people did a major change with platform support when going to 5.0 >>> - The first usable release on Mac is 5.2 >>> - LyX is not ready for using it ATM. Some work is needed. >>> >>> I'd prefer to get LyX 2.1 running on 10.9 with Qt4.8.5. >>> >>> So, I've build the two variations of the LyX-2.1.0dev packages. >>> Now I'm uploading them… >> >> >> I've put them here: >> >> https://dl.dropboxusercontent.com/u/27842660/LyX-2.1.0dev%2Bqt4-cocoa.dmg >> https://dl.dropboxusercontent.com/u/27842660/LyX-2.1.0dev%2Bqt4-cocoa.dmg.sig >> >> https://dl.dropboxusercontent.com/u/27842660/LyX-2.1.0dev%2Bqt5-cocoa.dmg >> https://dl.dropboxusercontent.com/u/27842660/LyX-2.1.0dev%2Bqt5-cocoa.dmg.sig >> >> @Benjamin: At most I'm interested if the 4.8.5 build is working on 10.9.
Qt5-support-for-Mac-improved.patch
Description: Binary data
