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… Attached is the mentioned change to make Qt5 builds with auto tools possible. Stephan
qt5-bundle.diff
Description: Binary data
