Re: Some questions regarding _gdk_window_impl_new() (csw, win32, patch)

[Alexander Larsson <alexl redhat com>]

On Sat, 2010-08-21 at 14:09 +0200, Hans Breuer wrote: 
> while trying to fix _gdk_window_impl_new() for win32 some more,
> quite some questions arose around that (apparently undocumented;)) API:
> 
>   - if the information given to _gdk_window_impl_new() is redundant,
>     as with GDK_WA_VISUAL set and visual given by parameter, which one
>     has precedence?

Use the visual parameter, it is based on GDK_WA_VISUAL if set already.
>From attributes the only things used is: colormap, title, wmclass and
type_hint.


> - when turning a csw into a native window, shouldn't the new window
>     position be calculated against the native parent? If so: should
>     the caller do it and give GDK_WA_(X|Y)?

Ignore the passed in position and size in attributes. The window
position is already calculated for the csw window, and all you need to
do is offset it to reach the nearest native window, so the position
should be:
  private->x + private->parent->abs_x, 
  private->y + private->parent->abs_y

To explain this, private->x/y is the offset from the parent GdkWindow to
this window, whereas private->abs_x/y is the offset from the "nearest"
native window to the window. We can't use private->abs_x/y here, because
it is zero for a native window.

And the size is always private->width x private->height.

None of this is very obvious, nor documented. Just look at how the x
backend does it, as that is the canonical implementation.

> - how to get back default OS/window-manager placment of toplevel
>     windows? (The old implementation used to place toplevel windows
>     with CW_USEDEFAULT, my new implementation is doing similar)

Not sure what you mean here. Can't you just pass CW_USEDEFAULT for toplevels?

>   - what's the (visual) depth of a GDK_INPUT_ONLY window?
>     ( Dia(win32) with gtk>=2.18 is crashing on it's Navigation popup,
>      which can be fixed by setting the visual depth to something
>      reasonable, but it used to be 0 before csw. Maybe this is hiding
>      a bug elsewhere, e.g. returning the wrong window when forced to
>      be native? )
> 

The visual for input-only windows is 0, but this is set by the common
code in gdk_window_new, so its not something the backend should have to
care about.

> Another question is regarding "GDK_NATIVE_WINDOWS". With my current
> patch at least the drawing seems to work reasonable again, but the
> (ENTER|LEAVE)_NOTIFY handling is not, so the mouse pointer is almost
> useless. Is it necessary to ressurect most of the original code (pre-csw)
> to make it work again, or should there be an easier way?

I'm not sure exactly how enter/leave notification works on win32, but
yeah, GDK_NATIVE_WINDOWS more or less passes on events as they arrived
from the windowing system, rather than doing the csw rewriting magic.
GDL_NATIVE_WINDOWS is really more of a hack for apps like eclipse and
lotus notes that need compatibility with old gdk behaviour when they do
really weird x stuff. 

I don't think supporting it on win32 is very useful. I mean, what is the
expected behaviour? The natural thing would be to be backwards
compatible with the exact old pre-csw mouse pointer code, but are any
apps really depending on that exact behaviour?

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's a notorious native American cat burglar with nothing left to lose. She's 
a violent hip-hop politician who believes she is the reincarnation of an 
ancient Egyptian queen. They fight crime!