Am 28.02.2014 um 23:23 schrieb Benjamin Piwowarski <benjamin.piwowar...@lip6.fr>:
> > On 28 Feb 2014, at 23:01 , Georg Baum <georg.b...@post.rwth-aachen.de> wrote: > >>>> 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? > > It seems that it would be better to have LyX macros handling the following > cases: > - QT + OS X => LYX_QT_OSX > - QT5 + OS X => LYX_QT5_OSX > - QT4 + OS X => LYX_QT4_OSX > - QT4 + OS X + COCOA => LYX_QT_OSX_COCOA > - QT4 + OS X + X11 => LYX_QT_OSX_X11 > > this would make the code more readable and easier to maintain IMHO. I'm not sure if this is really helpful. Most of the time if it's not avoidable to guard code by ifdefs one has a dedicated reason to make separate code fragments. Either its some os issue or its some window system difference or a version issue of any kind. I wouldn't make a define for any possible combination. Stephan
