[Patch] two patches to compile kdelibs/khtml on windows

[Lubos Lunak]

On Wednesday 07 December 2005 14:55, Christian Ehrlicher wrote:
> > On Tuesday 06 December 2005 06:56, Christian Ehrlicher wrote:
> > > Here the fixwinh.h and a patch to include it in the three headers where
> > > I get compile errors. It should not affect compilation on linux.
> >
> >  So it really needs to be used in the headers?
>
> What else should I do? The headers redefine those values and I can't
> include fixwinh.h everywhere the headers are included. And if they are
> public headers nobody knows that they have to include fixwinh.h first...

 You got the rule backwards. You have to include fixwinh.h after you include 
the windows.h header (which should be only a handful of .cpp anyway), that's 
why the file is called so. You fix what breaks things, not where it breaks.

> Is fixx11h.h actually installed so it can be use outside kdelibs?

 Yes.

> > To give you a slightly
> > better
> > idea why I have written in the instructions to include it in .cpp files,
> > consider this:
> > a.cpp:
> > #define RELATIVE // for debugging, give me relative times
> > #include "rendering/render_style.h"
> > // no X11 or windows headers here at all
> > ...
> > #ifdef RELATIVE
> > ... some debug code here
>
> Yes, that's clear, but you can also get problems without fixwinh.h because
> render_style.h redefines RELATIVE and (if you don't get a compiler error in
> the header) '#ifdef RELATIVE' is true every time.

 No, it wouldn't be true, because RELATIVE is an enum in the header, the part 
about the compile error is true though. Let's simply say it's better to avoid 
including hackish headers (which fixx11h.h is) everywhere.

> > > // OPTIONAL is defined '#define OPTIONAL' - so what to do here?
> >
> >  If you don't expect this empty #define will be used anywhere just #undef
> > it,
> > otherwise remap it to #define WOPTIONAL (note that even though your
> > comments
> > say to use W* the code uses X*).
>
> thx - will fix this
>
> I wonder if the first idea simply undefine the four defines in the
> respective headers isn't the better one...

 But you may sometimes want to use them. E.g. kdeui/kkeydialog.cpp has
#ifdef KeyPress
const int XFocusOut = FocusOut;
const int XFocusIn = FocusIn;
const int XKeyPress = KeyPress;
const int XKeyRelease = KeyRelease;
#undef KeyRelease
#undef KeyPress
#undef FocusOut
#undef FocusIn
#endif // KEYPRESS

(quite strangely there's not the usual "I hate X" comment :) ). And I've seen 
even more scary cases of various remappings, changing compilation file order 
and similar tricks that must have taken some effort to get so ugly ;). Now 
all (I hope) people have learnt to simply do #include <fixx11h.h> after 
#include <X11/Xlib.h> to fix the problem and that's it.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/