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. Stephan
