Georg Baum wrote:
Am Montag, 12. Juni 2006 18:09 schrieb Abdelrazak Younes:
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
One of the tricks used earlier was to make sure that
<boost/signals.hpp> was included before the qt headers.
But it is! <boost/signals.hpp> is included in LyXView.h which is the
second include in QtView.h (after config.h), which is the second include
in QCommandBuffer.C (after config.h).
I dunno...
Me neither
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 ;-)
I see that you corrected that, thanks.
Some other things I noticed:
- (at least) src/frontends/qt3/Gui.h has wrong line endings
Ah, I forgot eol-stlyle on that one, thanks.
- order the files alphabetically in Makefile.ams, please
OK.
- 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 ;-)). 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.
- 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.
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?
to use lyx::WorkArea or lyx::frontend::WorkArea if only WorkArea is given
in the lyx::frontend namespace, so I think it would be best for now not
to have files and classes with the same name in frontends and
frontends/qt4 etc.
>
- The existence of both src/frontends/foo.h and src/frontends/bar/foo.h is
confusing with the current includepaths. If you want to do something like
that you should remove src/frontends from the includepath so that all
included files in frontends need the extra "frontend" directory.
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.
- Please try hard not to include too many files in headers (see the
patch). More includes could be saved if you created a
src/frontends/*/Gui.C and put some methods there.
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.
The attached patch fixes the compile problems for all frontends. Since I
am not sure whether this is what you had in mind please apply yourself.
OK, thanks a lot.
Please don't complain that you need to include Clipboard.h and WorkArea.h
in more places.
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".
If you don't like that you should rethink your decision
to have the contens of these classes not in class Gui.
No, no, all your changes seem very reasonable. Please apply. So with the
patch, qt3, xforms and gtk performs like usual?
Thanks,
Abdel.
