Re: Qt and debugstream.h

2004-05-24 Thread John Levon
On Wed, May 19, 2004 at 11:27:03PM +0100, Angus Leeming wrote: Would it be Ok if I added these blocks around struct debug_trait? Maybe I'll make the macro name more polite ;-) I'm fairly sure one of the first changes I had rejected by the LyX team was trying to fix up Qt namespace pollution by

Re: Qt and debugstream.h

2004-05-24 Thread Lars Gullik Bjønnes
Angus Leeming [EMAIL PROTECTED] writes: | Pretty well every single Qt dialog file has to #include debug.h | before any of the Qt system headers or the compiler gets confused. | Why? Because Qt in its wisdom defines a macro DEBUG that clashes with | the DEBUG defined in support/debugstream.h that

Re: Qt and debugstream.h

2004-05-24 Thread Angus Leeming
Lars Gullik Bjønnes wrote: | Would it be Ok if I added these blocks around struct debug_trait? | Maybe I'll make the macro name more polite ;-) I am with john... make two small .h files in the qt three and use them in other files to workaround qt stuff. Ah, well. It appears that Mate's

Re: Qt and debugstream.h

2004-05-24 Thread Lars Gullik Bjønnes
Angus Leeming [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: | Would it be Ok if I added these blocks around struct debug_trait? | Maybe I'll make the macro name more polite ;-) I am with john... make two small .h files in the qt three and use them in other files to workaround qt

Re: Qt and debugstream.h

2004-05-24 Thread John Levon
On Mon, May 24, 2004 at 12:46:15PM +0100, Angus Leeming wrote: Qt has a similar problem with its 'signals' macro and namespace boost::signals. Actually, that one is a bit more insidious because we #include boost/signals[1-9]*.hpp in lots of other header files, so the pollution can pop up

Re: Qt and debugstream.h

2004-05-24 Thread Angus Leeming
Lars Gullik Bjønnes wrote: | #ifdef TEMPORARY_DEBUG_MACRO | # define DEBUG TEMPORARY_DEBUG_MACRO | # undef TEMPORARY_DEBUG_MACRO | #endif | I can see that this is nasty, but it does have the advantage of | just working. | The alternative, defining qt_debug.h, as a wrapper for debug.h is

Re: Qt and debugstream.h

2004-05-24 Thread Angus Leeming
John Levon wrote: On Mon, May 24, 2004 at 12:46:15PM +0100, Angus Leeming wrote: Qt has a similar problem with its 'signals' macro and namespace boost::signals. Actually, that one is a bit more insidious because we #include boost/signals[1-9]*.hpp in lots of other header files, so the

Re: Qt and debugstream.h

2004-05-24 Thread John Levon
On Mon, May 24, 2004 at 01:18:44PM +0100, Angus Leeming wrote: Because I was trying to wrap the Qt code inside namespace lyx::frontend and got offended by it all. That's not too hard to do... It wasn't me that added this comment: // Dear Lord, deliver us from Evil, // aka the Qt headers

Re: Qt and debugstream.h

2004-05-24 Thread John Levon
On Wed, May 19, 2004 at 11:27:03PM +0100, Angus Leeming wrote: > Would it be Ok if I added these blocks around struct debug_trait? > Maybe I'll make the macro name more polite ;-) I'm fairly sure one of the first changes I had rejected by the LyX team was trying to fix up Qt namespace pollution

Re: Qt and debugstream.h

2004-05-24 Thread Lars Gullik Bjønnes
Angus Leeming <[EMAIL PROTECTED]> writes: | Pretty well every single Qt dialog file has to #include "debug.h" | before any of the Qt system headers or the compiler gets confused. | Why? Because Qt in its wisdom defines a macro DEBUG that clashes with | the DEBUG defined in support/debugstream.h

Re: Qt and debugstream.h

2004-05-24 Thread Angus Leeming
Lars Gullik Bjønnes wrote: > | Would it be Ok if I added these blocks around struct debug_trait? > | Maybe I'll make the macro name more polite ;-) > > I am with john... make two small .h files in the qt three and use > them in other files to workaround qt stuff. Ah, well. It appears that Mate's

Re: Qt and debugstream.h

2004-05-24 Thread Lars Gullik Bjønnes
Angus Leeming <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: >> | Would it be Ok if I added these blocks around struct debug_trait? >> | Maybe I'll make the macro name more polite ;-) >> >> I am with john... make two small .h files in the qt three and use >> them in other files to

Re: Qt and debugstream.h

2004-05-24 Thread John Levon
On Mon, May 24, 2004 at 12:46:15PM +0100, Angus Leeming wrote: > Qt has a similar problem with its 'signals' macro and namespace > boost::signals. Actually, that one is a bit more insidious because we > #include boost/signals[1-9]*.hpp in lots of other header files, so > the pollution can pop

Re: Qt and debugstream.h

2004-05-24 Thread Angus Leeming
Lars Gullik Bjønnes wrote: > | #ifdef TEMPORARY_DEBUG_MACRO > | # define DEBUG TEMPORARY_DEBUG_MACRO > | # undef TEMPORARY_DEBUG_MACRO > | #endif >> > | I can see that this is nasty, but it does have the advantage of > | just working. >> > | The alternative, defining qt_debug.h, as a wrapper for

Re: Qt and debugstream.h

2004-05-24 Thread Angus Leeming
John Levon wrote: > On Mon, May 24, 2004 at 12:46:15PM +0100, Angus Leeming wrote: > >> Qt has a similar problem with its 'signals' macro and namespace >> boost::signals. Actually, that one is a bit more insidious because >> we >> #include boost/signals[1-9]*.hpp in lots of other header files,

Re: Qt and debugstream.h

2004-05-24 Thread John Levon
On Mon, May 24, 2004 at 01:18:44PM +0100, Angus Leeming wrote: > Because I was trying to wrap the Qt code inside namespace > lyx::frontend and got offended by it all. That's not too hard to do... > It wasn't me that added this comment: > > // Dear Lord, deliver us from Evil, > // aka the Qt

Qt and debugstream.h

2004-05-23 Thread Angus Leeming
Pretty well every single Qt dialog file has to #include debug.h before any of the Qt system headers or the compiler gets confused. Why? Because Qt in its wisdom defines a macro DEBUG that clashes with the DEBUG defined in support/debugstream.h that is #included through the Qt button controller.

Qt and debugstream.h

2004-05-23 Thread Angus Leeming
Pretty well every single Qt dialog file has to #include "debug.h" before any of the Qt system headers or the compiler gets confused. Why? Because Qt in its wisdom defines a macro DEBUG that clashes with the DEBUG defined in support/debugstream.h that is #included through the Qt button controller.