Re: cleaned up WM state patch

[Havoc Pennington <hp redhat com>]

Tim Janik <timj gtk org> writes: 
> <sigh> what's wrong with GDK_WINDOW_OBJECT() ?
> 

<sigh> It isn't used a single time in gdkwindow-x11.c. I do my best to
be consistent with existing code since I assume that indicates the
proper convention in a given situation, and consistency is a good
thing anyhow.

<sigh> All public entry points in gdkwindow-x11.c are already guarded
or should be guarded by GDK_IS_WINDOW(), this is private internal
stuff, where we frequently omit checks last I heard.

<sigh> If some people documented their preferred conventions it would
be easier to follow them.

<sigh> Maybe there is no point in expressing exasperation via <sigh>
for trivial typo-level mistakes, you could e.g. just check in a fix,
or just point out the problem, especially when the point in question
is some obscure principle not even Owen is aware of.

<sigh> I guess I'll have to flame you for all uses of the word "sigh"
from now on. ;-)

> >  						 gint        width,
> >  						 gint        height);
> > +
> > +#define GDK_WINDOW_IS_MAPPED(window) ((((GdkWindowObject*)window)->state & GDK_WINDOW_STATE_WITHDRAWN) == 0)
> 
> especially here, if developers pass in NULL, with GDK_WINDOW_OBJECT()
> they will first get a warning about NULL pointer dereference, with your
> direct cast they will just crash. usage of the casting macros has been
> convention for a very long time, please adjust your code.

This macro replaced a bunch of "private->mapped", so it's hardly
introducing a new problem.

The public entry points have checks; this stuff is all private cruft.
In many cases we do not do typechecks for private stuff.
 
> this should still be gdk_wmspec_supports(), see my reply to owen
> in the previous thread on this.

I don't remember a reply on this issue. I'll look for it. I'm not
going to change it until I get agreement from both of you though.  I
do not want to change for you, change back for Owen, change back for
you, etc. - you two work it out, then jointly tell me the answer.

Havoc