Re: [Nautilus-list] bin_window vs. window coords.

[Alex Larsson <alexl redhat com>]

On Fri, 22 Feb 2002, Darin Adler wrote:

> On 2/21/02 10:38 PM, "Alex Larsson" <alexl redhat com> wrote:
> 
> > Darin. Can you describe this:
> > 
> > 2002-01-30  Darin Adler  <darin bentspoon com>
> > 
> > * configure.in: Bump eel version required.
> > 
> > * libnautilus-private/nautilus-icon-container.c:
> > (rubberband_timeout_callback), (start_rubberbanding),
> > (update_stretch_at_idle), (motion_notify_event):
> > * libnautilus-private/nautilus-icon-dnd.c: (icon_get_data_binder),
> > (nautilus_icon_container_position_shadow),
> > (receive_dropped_keyword),
> > (nautilus_icon_container_find_drop_target),
> > (nautilus_icon_container_receive_dropped_icons),
> > (nautilus_icon_container_get_drop_action),
> > (nautilus_icon_dnd_update_drop_target), (nautilus_icon_dnd_init),
> > (nautilus_icon_dnd_begin_drag):
> > Use new eel functions that eliminate the funky interaction between
> > the new GtkLayout and GnomeCanvas. Basically, all the functions
> > that deal with window coordinates are getting bin_window
> > coordinates instead. This should really be fixed in GnomeCanvas.
> > 
> > change a bit?
> 
> Here's the explanation: When I made this change I was under the impression
> that events for a widget contain X and Y coordinates relative to the
> widget's window. So that events for a canvas would be relative to the
> GtkLayout window, not the bin_window that's used for the scrolling.

Let me describe how this works in general. 
All X Windows have an EventMask that decides which events get sent to that 
window. When an event such as buttonpress is being generated X looks at 
the innermost window the pointer is in (unless grabs are in effect), then 
it searches outward until it finds the first XWindow that has the event 
mask for button press set and sends the Event to that XWindow.

When Gdk recieves this it looks up the GdkWindow for the XWindow, and then 
Gtk looks at the user data of the GdkWindow to see which GtkWidget this 
window belongs to and emits the event and/or button_press_event on that 
widget.

In the case of the canvas, the button press even mask is set on the 
bin_window, so when button_press arrives event->window is gonna be 
bin_window and coordinates are relative to that.
 
> Since the rubberbanding got broken when I made this change, it means two
> things:
> 
>     1) I blew it because I didn't test my changes
>     2) Something's wrong about my mental model
> 
> I guess I really don't know when coordinates are relative to the window and
> when relative to the bin_window. I had assumed the bin_window would never
> really enter into it. And if that's so, the entire concept behind the eel
> functions could be wrong.

Unfortunately i think they are.
 
> I do know that whenever NautilusIconContainer wants to save window
> coordinates rather than canvas coordinates, we want those to be window, not
> bin_window, because the whole point is to be unaffected by scrolling. So
> that part of what I was thinking was right. I also am pretty sure that the
> rubberband_timeout_callback code that uses gdk_window_get_pointer is
> correct, because it explicitly uses widget->window.

Hmm? Why do you want them to be unnaffected by scrolling? I guess this is 
the part i don't understand.
 
> The part I probably got wrong was assuming I knew which window incoming
> event coordinates were relative to. I'm thinking that what I really need to
> do to get this right is to actually look at the window field from the event,
> because that's going to accurately reflect which GdkWindow the X and Y
> coordinates are relative to. So maybe the Eel functions should take a
> GdkWindow parameter, or maybe even a GekEventButton parameter.

This is one solution. But i still don't see why you can't use bin_window 
relative coords.
 
/ Alex