Abdelrazak Younes wrote: > Georg Baum wrote: >> Why don't you simply grep for 'emit'? You would find several places where >> emit is #undefined, and a README that tells you not to do so. > > You know, sometimes you miss the most obvious thing to do because you > look for something else :-(. I was looking for a boost/Qt clash so I > couldn't imagine that lyx was the guilty lot her ;-)
Yes, it seems to be a bit too popular lately to bash qt. I think we should be fair and don't blame qt for every problem :-) >> - It is confusing that src/frontends/Gui.h defines lyx::Gui, and >> src/frontends/qt3/Gui.h defines lyx::frontend::Gui. > > But I asked multiple time if anyone had any objection (you also said > that it was fine with you ;-)). At that time I did not see the practical implications, I only thought that we had different namespaces (both in C++ and directory-wise), and that is still OK with me. What I also overlooked was the fact that src/frontends/Gui.h puts something in lyx namespace, and src/frontends/qt3/Gui.h puts the same thing in lyx::frontend namespace. IMO, if Gui.h puts something in lyx namespace, it should go to src and not to src/frontends. If it is wrong there then the namespace is wrong. > I followed Angus advice here I am > reluctant to go back again. I was thinking also to remove src/frontends > from the include patch in order to avoid problems. > Now that it is implemented I find it very clean: the kernel knows about > the interface classes. The frontend knows about the derived classes. In > principle (minus the include path problem) it should all be very clean. That is clean indeed, but does not take into account the namespaces. >> - The existence of lyx::WorkArea and lyx::frontend::WorkArea does seems >> to confuse compilers. I get a compile error in qt4/Application.C because >> the wrong WorkArea.h is included. > > I will check that. I think it would help to always fully qualify the classes (at least in header) files: lyx::WorkArea or lyx::frontend::WorkArea, not WorkArea. To me it was not clear which one was meant to be used. >> It seems that MSvC and gcc disagree whether > > I still use gcc here. I think the include path order is not the same > with scons and autotools. I thought that gcc would always give priority > to '.', wouldn't it? > If not, how can I modify the default include options for the frontend > compilation? Relying on the include path order is fragile. I never do that in my own projects, because I have been bitten by it too often already. The only option IMHO is to remove src/frontends from the includepath everywhere. > Yes. I think that's a good solution. The idea is that the core should > not know about the frontend, only about the interfaces. So we the only > potential problem could be in compiling the frontend. Why should tgere be a problem? > I know that. These header were just a stop gap measure in order to adapt > other frontends to the new API. The idea is that, for example, code > from qt3/QWorkArea qt3/qscreen is moved to qt3/WorkArea and qt3/Clipboard. OK. > Hey man, I won't complain. I am really happy that you give me a hand > here. It's weird though that I don't need the additional includes in > "BufferView_pimpl.C". They are needed because I removed them from Gui.h. > No, no, all your changes seem very reasonable. Please apply. So with the > patch, qt3, xforms and gtk performs like usual? I don't know, I only compiled and did not test. BTW I won't be able to apply during the next two days. Georg
